Internet Engineering Task Force C. Xie Internet-Draft China Telecom Intended status: Standards Track L. Song Expires: March 24, 2019 Beijing Internet Institute September 20, 2018 Network-side Happy Eyeballs based on accurate IPv6 measurement draft-v6ops-xie-network-happyeyeballs-00 Abstract During the period of IPv6 transition, both ISP and ICP (Internet Content Provider) care about user's experience in dual-stack network. They hesitate to provide IPv6 to their users due to the fear of poor IPv6 performance. Network-based Happy Eyeballs (NHE) is proposed in this memo as a approach to provide better connectivity to end users by doing accurate measurement and comparison on IPv6/IPv4 performance on the network side other than client-side Happy Eyeballs (HE) ([RFC8305]). It works independently with client's adoption of HE. REMOVE BEFORE PUBLICATION: The source of the document with test script is currently placed at GitHub [NHE-GitHub]. Comments and pull request are welcome. 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 24, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Xie & Song Expires March 24, 2019 [Page 1] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview of NHE Mechanism . . . . . . . . . . . . . . . . . . 3 3. NHE DNS Resolver . . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6/IPv4 Performance Measurement . . . . . . . . . . . . . . 5 4.1. Performance metrics . . . . . . . . . . . . . . . . . . . 5 4.2. NHE Location considerations . . . . . . . . . . . . . . . 6 4.3. Less measurement traffic . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction During the period of IPv6 transition, both ISP and ICP (Internet Content Provider) care about user's experience in dual-stack network. They hesitate to provide IPv6 to their users due to the fear of poor IPv6 performance. Happy Eyeballs(HE) [RFC8305] provides an approach to enable clients to attempt multiple connections in parallel. It is helpful to work around the blocked, broken, or sub-optimal network. Taken IPv6 priority consideration in design, HE helps increase IPv6 traffic in network and reduce the delay in client side as well if IPv6 connectivity is poorer. So far, most modern web browser support HE very well, thanks to popular web browser engines, such as WebKit and Trident. However, in practice there are still some bars keeping application developers who develop Apps with APIs and libs which does not implementing HE. Firstly, HE adds additional complexity and uncertainties to both development and operation. For example, according to the section 8 of RC8305 there are 6 Configurable values such as Resolution Delay and Connection Attempt Delay. It raise a bar for small application developers to do a "nuanced implementation" to tune these values according to network dynamics or history RTT data. Secondly, paralleled connections emitted by HE will produce larger volume of Xie & Song Expires March 24, 2019 [Page 2] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 traffic which consume both mobile fees and power. As a result mobile application developers may choose no to adopt HE or even not consider migrating their APPs to IPv6 due to the issues. It is typical case in regions where IPv6 performance is not as good as IPv4 in terms of RTT and failure rate. This draft is intend to proposed an Network-side Happy Eyeballs(NHE), an approach to address the same problem targeted by Client-side Happy eyeballs ([RFC8305]) for IPv4/IPv6 dual-stack users. Instead of requiring the client to race IPv6 and IPv4 connections, NHE intends to do the "race" on the network side in advance and do selective filtering of the DNS AAAA record for specific domains. The rationale of NHE approach is simple that ISPs typically the mobile network provider has more resource, capability and motivation to do accurate IPv6/IPv4 performance measurement for the good of their users. With sufficient and accurate IPv6/IPv4 performance information, ISPs can make confident decision to filter AAAA record or not. It is worth to mention that with NHE approach, the operational issues will not be hidden and ISP will be crystal clear about their IPv6 network performance and spare no effort to improve it. 2. Overview of NHE Mechanism Figure 1 shows the high level diagram of NHE. NHE mechanism involve two key components: NHE DNS Resolver and IPv6/IPv4 measurement. In NHE DNS resolver a special list of domains is maintained. The purpose of this list is to indicate the resolver performing AAAA record filtering (returning NODATA) if AAAA record exists for that domain in the list. This special list is updated via a Push (or Pull) interface from IPv6/IPv4 measurement component. The list is called NHE filtering list in this document. The component of IPv6/IPv4 measurement is designed to feed the NHE filtering list, by performing IPv6/IPv4 RTT measurement on each cached domains. The cached domains under the measurement can start with a well populated cache, then updated in align with the resolver cache via a Push (or Pull) interface from NHE DNS resolver. The criteria of putting a specific domain into that list and how to perform the measurement are introduced in Section 4. Xie & Song Expires March 24, 2019 [Page 3] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 +--------------------------------+ | | | IPv6/IPv4 Measurement | | | +--------------+-----------------+ ^ | Cached domains | | Domains with poor | | IPv6 connections | | | v NODATA +-----------------------+ <-----------+ | | | NHE DNS Resolver | +------------> | | a query for AAAA +-----------------------+ record of a domain Figure 1: High-Level NHE Mechanism When the two component of NHE are ready, then the processing is described as follows: Once NHE DNS Resolver receive a AAAA record query from client, the resolver firstly check if the qname matches a entry or not in the NHE filter list. If the qname matches an entry, then the AAAA record will be filtered and a NODATA response will be replied. If no entry is matched, then NHE DNS resolver will response as a normal resolver. Note that NHE can work independently with the Client's adoption of HE. It can push the clients to fall back faster to IPv4 if they does not support HE. It also can help reduce the unnecessary traffic emitted by HE client. 3. NHE DNS Resolver Before [RFC6555] and [RFC8305] were documented, selective filtering of the DNS AAAA record was proposed as a practice making the IPv6 transition less painful [Less-painful]. The basic idea introduced is that ISP DNS Recursive servers does not return AAAA for users who have broken IPv6 connectivity. There are some working implementations of it such filter AAAA option in BIND 9 [Filtering-AAAA] Note that in the beginning, it was widely considered difficult to accurately measure working users. So ISP resolver only returns AAAA if the AAAA query came over IPv6. However, even ISP resolver can receive queries from stub client via IPv6, The end-to-end IPv6 connectitity from the client to far-end server may be poor as well Xie & Song Expires March 24, 2019 [Page 4] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 due to the issues on either authoritative server (servfail for exmaple), or content provider network, or the path in the midst. NHE DNS resolver adopts selective filtering of the DNS AAAA record as well. However, approach like filter AAAA option does not fit NHE scenarios, because NHE is expected to filter AAAA option based on the qname of the query, not the transport protocol or addresses where the query come from. The difference is that a qname list (referred as to NHE filtering list) is maintained and updated periodically by NHE DNS resolver. It has an interface with IPv6/IPv4 performance measurement which can push the newest list to NHE DNS Resolver. Besides the Push(or Pull) interface from the measurement , NHE DNS resolver can also Push(or Pull) populated cache to the measurement component as shown in figure 1. The cache pushed by resolver can be optionally companied with additional information like RTT of NS for each domain and number of cache hits. The additional information can be used to reduce measuring traffic which is introduced in Section 4.3 4. IPv6/IPv4 Performance Measurement An accurate IPv6 performance measurement is vital to the success of NHE. A accurate measurement depends on what to measure, where and how to measure. 4.1. Performance metrics In client-side HE, a kind of round-trip delay or round-trip time(RTT) metric is used where a race between IPv6 and IPv4 connection is measured, starting from hostname resolution, then TCP setup on both address families. In NHE, the similar approach is adopted in ISP network to simulate a client doing race for a list of domains. o Lookup the hostname. If a positive AAAA response with at least one valid AAAA record is received, it process next. If a negative response with no AAAA record is received, it will break and mark the domain whose AAAA record should be filtered. Note that if a negative response with Servfail is received, no Servfail response should be return to the client, because it is observed that some clients will continue asking AAAA queries after receiving Servfail response. o Make TCP connections via all IPv6 and IPv4 destination addresses returned. Note that in NHE there is no address sorting or connection attempt Delay which are important in the design of client-side HE. NHE measuring server can concurrently make connections on all addresses returned. Xie & Song Expires March 24, 2019 [Page 5] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 o The round-trip delay is measured including the RTT of hostname resolution and RTT of TCP setup (start from sending the SYN and end by ACK is received). If there is more than one IP address in either AAAA or A record response, all distance addresses should be measured for round-trip delay. o Calculate the difference of round-trip delay (Diff-RTT) of different address family. If there are more than one IP address in either AAAA or A record response, the minimum RTT of a destination from one address family will be chosen to do the difference, that is Min(RTT-IPv6)-min(RTT-IPv4) o For each domain, if the difference of round-trip delay of IPv6 and IPv4 is larger than a configurable threshold, the domain will be listed in the NHE filtering list to be synchronized to NHE DNS resolver. Note that the threshold value should be tunable by network provider to gain a better tradeoff between IPv6 performance and IPv6 priority practice. In the measurement process described above, there is a important domain list called Measuring list which contains the targeted domains. The list can be formed from the popular domains in the cache pushed from the resolver or configured by operators from other source. It is not necessary to keep the Measure list and cache pushed by resolver identical. This measurement can be done periodically on a specific domain, for example one hour or two, and make it ready for Push to NHE DNS resolver. Note that no protocol is specified in this memo which is used to synchronized NHE Filtering list and cached domains in resolver. Compared to Client-side HE, NHE operated by ISP operators has more resource to do better performance measurement. The race on the handset measure the round-trip delay on one instantaneous connection which does not fully represent the connectivity performance of one address family in a persistent period. For example erratic variation in delay (caused by network jitter) makes it difficult to support many interactive real-time applications. So the statistics of round- trip delay is helpful for ISP operator to build more sophisticated measurement. Section 4 of [RFC2681] specifies some statistics definitions for round-trip delay which can be utilized for advanced Round-trip delay measurement, such as percentile, median, minimum, inverse percentile etc. 4.2. NHE Location considerations According to the accuracy requirement of user performance simulation, the location where the measurement is done is very important. The intuitive approach is to placed the measuring probes or servers on Xie & Song Expires March 24, 2019 [Page 6] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 the edge, in proximity to the end users. In 4G LTE cellular network as a typical case, the performance measurement server can be located in proximity of base stations (or an aggregation point). There is only at most one hop difference in the end-to-end path between a real end user and a destination. There is one question about the location of NHE deployment. If performance measurement server is located on the edge, is NHE resolver should be located in the same place? In another word: are they deployed in pairs? The simple answer is yes which enhance the efficiency of cache if the resolver is deployed on the edge. NHE DNS resolver can be a cache sever forwarding cache missed query to the ISP normal full functional resolver. The only concern is if the caching resolver is located closely to end users, it may lose good cache hit probability. 4.3. Less measurement traffic Since the IPv6/IPv4 performance varies per domain, there is a fear of having to generate a lot of measuring traffic in NHE. There are two approaches may be helpful to generate less traffic. One is to keep a moderate size of NHE filtering list including, for example, top 1k ~ 5k popular domains in the cache. To achieve that, the NHE resolver should not only Push the cache , but also a popularity value of each domain (the number of cache hits). In addition, the size of the filtering list generated by measurement server can be configurable as well according to ISP local policy. The second approach to reduce the measurement traffic is to use passive measurement. The round-trip delay of DNS lookup of a particular domain is trivial in most of case if cache hit. So passive measurement should focus on monitoring TCP connection of specific destination. Suppose there are 1000 top popular domains in the measurement list which means thousands TCP connections is to be put into passive monitoring to measure the round-trip delay. One optional approach of limiting the size of measuring list is to focus on top Apps other than top domains. ISP can cooperated with CP to maintain a domain list of top Apps for NHE. 5. Security Considerations NHE adopt filtering in the resolver so it will break DNSSEC and omit RRSIG records covering type AAAA as well as AAAA record. The scope of DNSSEC break is limited between client and resolver, which is not the typical scenario of DNSSEC though, in the case clients ask for RRSIG record of AAAA. Xie & Song Expires March 24, 2019 [Page 7] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 Filtering AAAA records cause DNS incoherency in the end users perspective which may causes some risks if end user's application depend on the integrity of DNS data. To reduce this risk, ISP resolver would artificially delay the AAAA answers if positive answer is received. 6. IANA considerations No IANA considerations for this memo 7. Acknowledgments Acknowledgments are given to Geoff Huston, David Schinazi, Marc Blanchet, and Paul Vixie who gave comments and suggestions on this memo. 8. References [Filtering-AAAA] "Filter AAAA option in BIND 9", August 2017, . [Less-painful] Yahoo, "IPv6 and recursive resolvers:How do we make the transition less painful?", March 2010, . [NHE-GitHub] BII, "GitHub Repository of Network-side Happy Eyeballs", . [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . Xie & Song Expires March 24, 2019 [Page 8] Internet-DraftNetwork-side Happy Eyeballs based on accuratSeptember 2018 Authors' Addresses Chongfeng Xie China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P. R. China Email: xiechf.bri@chinatelecom.cn Linjian Song Beijing Internet Institute 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA Beijing 100176 P. R. China Email: songlinjian@gmail.com Xie & Song Expires March 24, 2019 [Page 9]