New weighted resource record for traffic scheduling
draft-zhang-dnsop-weighted-address-records-00

Document Type Active Internet-Draft (individual)
Last updated 2018-09-25
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                                 H. Zhang
Internet-Draft                                                    P. Zuo
Intended status: Standards Track                                  J. Yao
Expires: March 29, 2019                                            CNNIC
                                                      September 25, 2018

          New weighted resource record for traffic scheduling
             draft-zhang-dnsop-weighted-address-records-00

Abstract

   Scheduling traffic in proportion to different nodes can optimize
   bandwidth utilization and improve user experience when the Internet
   traffic exceeds the bandwidth limit of a CDN cache node.  This
   document defines AX and AAAAX RR types by adding weight field to
   existing A and AAAA resource records.  A group of weighted records
   will be sorted in the DNS response according to the weight in AX and
   AAAAX records.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 29, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Zhang, et al.            Expires March 29, 2019                 [Page 1]
Internet-DraftNew weighted resource record for traffic schSeptember 2018

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Most of CDNs can bring a client to the closest cache node according
   to the source IP of the client nowadays.  However, the rapid
   development of Internet raises new challenges.  According to public
   information, Global IP traffic will increase nearly threefold over
   the next 5 years and the busy-hour Internet traffic is growing more
   rapidly than average traffic.  For some CDNs, it becomes more
   frequent that peak traffic will exceed the bandwidth limit of their
   nodes and they need new solutions to optimize traffic scheduling.

   For example, if the maximum bandwidth for a CDN node is 10G and the
   busy-hour traffic reaches 12G, it is necessary to schedule 10G
   traffic to this node and the extra 2G traffic to other adjacent
   nodes.  Scheduling traffic in proportion to different nodes can
   optimize bandwidth utilization and improve user experience.

2.  Possible solutions

   In general, there are three ways to solve this problem:

   (1) Get browsers to comply with RFC 2782

   RFC 2782 describes a DNS RR which specifies the location of the
   server for a specific protocol and provides a server selection
   mechanism.  However, getting browsers to move is a long project.  In
   practice, RFC2782 is more suitable for service discovery but not
   widely adopted for dynamic web server selection.

   (2) Serve up multiple copies of the same RR and expect that record
   shuffling will deliver a specific ratio

   The multiple IP address listings is done in practice.  However, it is
   meaningless for two records to ever have label, class, type and data
   all equal - servers should suppress such duplicates if
   encountered.(as described in [RFC2181]) . Therefore, this method is
   not recommended as some servers may remove duplicates.

   (3) Get authoritative servers and resolvers to serve weighted A/AAAA
   records and short TTL

   CDNs are actually using a similar method nowadays.  Weighted A/AAAA
   records and short TTLs brings a dynamic server selection mechanism

Zhang, et al.            Expires March 29, 2019                 [Page 2]
Internet-DraftNew weighted resource record for traffic schSeptember 2018

   that optimizes traffic scheduling.  Compared to RFC2782, this is a
   light-weight solution that can be widely adopted easily.

   This document defines AX/AAAAX resource record to standardize the
   third method.  By adding weight filed in AX/AAAAX, a DNS server can
   serve address records with weighted frequency.  The similar mechanism
Show full document text