idnits 2.17.1 draft-v6ops-xie-network-happyeyeballs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([NHE-GitHub], [RFC8305]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2018) is 2038 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Filtering-AAAA' -- Possible downref: Non-RFC (?) normative reference: ref. 'Less-painful' -- Possible downref: Non-RFC (?) normative reference: ref. 'NHE-GitHub' ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Xie 3 Internet-Draft China Telecom 4 Intended status: Standards Track L. Song 5 Expires: March 24, 2019 Beijing Internet Institute 6 September 20, 2018 8 Network-side Happy Eyeballs based on accurate IPv6 measurement 9 draft-v6ops-xie-network-happyeyeballs-00 11 Abstract 13 During the period of IPv6 transition, both ISP and ICP (Internet 14 Content Provider) care about user's experience in dual-stack network. 15 They hesitate to provide IPv6 to their users due to the fear of poor 16 IPv6 performance. Network-based Happy Eyeballs (NHE) is proposed in 17 this memo as a approach to provide better connectivity to end users 18 by doing accurate measurement and comparison on IPv6/IPv4 performance 19 on the network side other than client-side Happy Eyeballs (HE) 20 ([RFC8305]). It works independently with client's adoption of HE. 22 REMOVE BEFORE PUBLICATION: The source of the document with test 23 script is currently placed at GitHub [NHE-GitHub]. Comments and pull 24 request are welcome. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 24, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Overview of NHE Mechanism . . . . . . . . . . . . . . . . . . 3 62 3. NHE DNS Resolver . . . . . . . . . . . . . . . . . . . . . . 4 63 4. IPv6/IPv4 Performance Measurement . . . . . . . . . . . . . . 5 64 4.1. Performance metrics . . . . . . . . . . . . . . . . . . . 5 65 4.2. NHE Location considerations . . . . . . . . . . . . . . . 6 66 4.3. Less measurement traffic . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 During the period of IPv6 transition, both ISP and ICP (Internet 76 Content Provider) care about user's experience in dual-stack network. 77 They hesitate to provide IPv6 to their users due to the fear of poor 78 IPv6 performance. Happy Eyeballs(HE) [RFC8305] provides an approach 79 to enable clients to attempt multiple connections in parallel. It is 80 helpful to work around the blocked, broken, or sub-optimal network. 81 Taken IPv6 priority consideration in design, HE helps increase IPv6 82 traffic in network and reduce the delay in client side as well if 83 IPv6 connectivity is poorer. So far, most modern web browser support 84 HE very well, thanks to popular web browser engines, such as WebKit 85 and Trident. However, in practice there are still some bars keeping 86 application developers who develop Apps with APIs and libs which does 87 not implementing HE. 89 Firstly, HE adds additional complexity and uncertainties to both 90 development and operation. For example, according to the section 8 91 of RC8305 there are 6 Configurable values such as Resolution Delay 92 and Connection Attempt Delay. It raise a bar for small application 93 developers to do a "nuanced implementation" to tune these values 94 according to network dynamics or history RTT data. Secondly, 95 paralleled connections emitted by HE will produce larger volume of 96 traffic which consume both mobile fees and power. As a result mobile 97 application developers may choose no to adopt HE or even not consider 98 migrating their APPs to IPv6 due to the issues. It is typical case 99 in regions where IPv6 performance is not as good as IPv4 in terms of 100 RTT and failure rate. 102 This draft is intend to proposed an Network-side Happy Eyeballs(NHE), 103 an approach to address the same problem targeted by Client-side Happy 104 eyeballs ([RFC8305]) for IPv4/IPv6 dual-stack users. Instead of 105 requiring the client to race IPv6 and IPv4 connections, NHE intends 106 to do the "race" on the network side in advance and do selective 107 filtering of the DNS AAAA record for specific domains. The rationale 108 of NHE approach is simple that ISPs typically the mobile network 109 provider has more resource, capability and motivation to do accurate 110 IPv6/IPv4 performance measurement for the good of their users. With 111 sufficient and accurate IPv6/IPv4 performance information, ISPs can 112 make confident decision to filter AAAA record or not. 114 It is worth to mention that with NHE approach, the operational issues 115 will not be hidden and ISP will be crystal clear about their IPv6 116 network performance and spare no effort to improve it. 118 2. Overview of NHE Mechanism 120 Figure 1 shows the high level diagram of NHE. NHE mechanism involve 121 two key components: NHE DNS Resolver and IPv6/IPv4 measurement. In 122 NHE DNS resolver a special list of domains is maintained. The 123 purpose of this list is to indicate the resolver performing AAAA 124 record filtering (returning NODATA) if AAAA record exists for that 125 domain in the list. This special list is updated via a Push (or 126 Pull) interface from IPv6/IPv4 measurement component. The list is 127 called NHE filtering list in this document. 129 The component of IPv6/IPv4 measurement is designed to feed the NHE 130 filtering list, by performing IPv6/IPv4 RTT measurement on each 131 cached domains. The cached domains under the measurement can start 132 with a well populated cache, then updated in align with the resolver 133 cache via a Push (or Pull) interface from NHE DNS resolver. The 134 criteria of putting a specific domain into that list and how to 135 perform the measurement are introduced in Section 4. 137 +--------------------------------+ 138 | | 139 | IPv6/IPv4 Measurement | 140 | | 141 +--------------+-----------------+ 142 ^ | 143 Cached domains | | Domains with poor 144 | | IPv6 connections 145 | | 146 | v 147 NODATA +-----------------------+ 148 <-----------+ | | 149 | NHE DNS Resolver | 150 +------------> | | 151 a query for AAAA +-----------------------+ 152 record of a domain 154 Figure 1: High-Level NHE Mechanism 156 When the two component of NHE are ready, then the processing is 157 described as follows: Once NHE DNS Resolver receive a AAAA record 158 query from client, the resolver firstly check if the qname matches a 159 entry or not in the NHE filter list. If the qname matches an entry, 160 then the AAAA record will be filtered and a NODATA response will be 161 replied. If no entry is matched, then NHE DNS resolver will response 162 as a normal resolver. 164 Note that NHE can work independently with the Client's adoption of 165 HE. It can push the clients to fall back faster to IPv4 if they does 166 not support HE. It also can help reduce the unnecessary traffic 167 emitted by HE client. 169 3. NHE DNS Resolver 171 Before [RFC6555] and [RFC8305] were documented, selective filtering 172 of the DNS AAAA record was proposed as a practice making the IPv6 173 transition less painful [Less-painful]. The basic idea introduced is 174 that ISP DNS Recursive servers does not return AAAA for users who 175 have broken IPv6 connectivity. There are some working 176 implementations of it such filter AAAA option in BIND 9 177 [Filtering-AAAA] 179 Note that in the beginning, it was widely considered difficult to 180 accurately measure working users. So ISP resolver only returns AAAA 181 if the AAAA query came over IPv6. However, even ISP resolver can 182 receive queries from stub client via IPv6, The end-to-end IPv6 183 connectitity from the client to far-end server may be poor as well 184 due to the issues on either authoritative server (servfail for 185 exmaple), or content provider network, or the path in the midst. 187 NHE DNS resolver adopts selective filtering of the DNS AAAA record as 188 well. However, approach like filter AAAA option does not fit NHE 189 scenarios, because NHE is expected to filter AAAA option based on the 190 qname of the query, not the transport protocol or addresses where the 191 query come from. The difference is that a qname list (referred as to 192 NHE filtering list) is maintained and updated periodically by NHE DNS 193 resolver. It has an interface with IPv6/IPv4 performance measurement 194 which can push the newest list to NHE DNS Resolver. 196 Besides the Push(or Pull) interface from the measurement , NHE DNS 197 resolver can also Push(or Pull) populated cache to the measurement 198 component as shown in figure 1. The cache pushed by resolver can be 199 optionally companied with additional information like RTT of NS for 200 each domain and number of cache hits. The additional information can 201 be used to reduce measuring traffic which is introduced in 202 Section 4.3 204 4. IPv6/IPv4 Performance Measurement 206 An accurate IPv6 performance measurement is vital to the success of 207 NHE. A accurate measurement depends on what to measure, where and 208 how to measure. 210 4.1. Performance metrics 212 In client-side HE, a kind of round-trip delay or round-trip time(RTT) 213 metric is used where a race between IPv6 and IPv4 connection is 214 measured, starting from hostname resolution, then TCP setup on both 215 address families. In NHE, the similar approach is adopted in ISP 216 network to simulate a client doing race for a list of domains. 218 o Lookup the hostname. If a positive AAAA response with at least 219 one valid AAAA record is received, it process next. If a negative 220 response with no AAAA record is received, it will break and mark 221 the domain whose AAAA record should be filtered. Note that if a 222 negative response with Servfail is received, no Servfail response 223 should be return to the client, because it is observed that some 224 clients will continue asking AAAA queries after receiving Servfail 225 response. 227 o Make TCP connections via all IPv6 and IPv4 destination addresses 228 returned. Note that in NHE there is no address sorting or 229 connection attempt Delay which are important in the design of 230 client-side HE. NHE measuring server can concurrently make 231 connections on all addresses returned. 233 o The round-trip delay is measured including the RTT of hostname 234 resolution and RTT of TCP setup (start from sending the SYN and 235 end by ACK is received). If there is more than one IP address in 236 either AAAA or A record response, all distance addresses should be 237 measured for round-trip delay. 239 o Calculate the difference of round-trip delay (Diff-RTT) of 240 different address family. If there are more than one IP address 241 in either AAAA or A record response, the minimum RTT of a 242 destination from one address family will be chosen to do the 243 difference, that is Min(RTT-IPv6)-min(RTT-IPv4) 245 o For each domain, if the difference of round-trip delay of IPv6 and 246 IPv4 is larger than a configurable threshold, the domain will be 247 listed in the NHE filtering list to be synchronized to NHE DNS 248 resolver. Note that the threshold value should be tunable by 249 network provider to gain a better tradeoff between IPv6 250 performance and IPv6 priority practice. 252 In the measurement process described above, there is a important 253 domain list called Measuring list which contains the targeted 254 domains. The list can be formed from the popular domains in the 255 cache pushed from the resolver or configured by operators from other 256 source. It is not necessary to keep the Measure list and cache 257 pushed by resolver identical. This measurement can be done 258 periodically on a specific domain, for example one hour or two, and 259 make it ready for Push to NHE DNS resolver. Note that no protocol is 260 specified in this memo which is used to synchronized NHE Filtering 261 list and cached domains in resolver. 263 Compared to Client-side HE, NHE operated by ISP operators has more 264 resource to do better performance measurement. The race on the 265 handset measure the round-trip delay on one instantaneous connection 266 which does not fully represent the connectivity performance of one 267 address family in a persistent period. For example erratic variation 268 in delay (caused by network jitter) makes it difficult to support 269 many interactive real-time applications. So the statistics of round- 270 trip delay is helpful for ISP operator to build more sophisticated 271 measurement. Section 4 of [RFC2681] specifies some statistics 272 definitions for round-trip delay which can be utilized for advanced 273 Round-trip delay measurement, such as percentile, median, minimum, 274 inverse percentile etc. 276 4.2. NHE Location considerations 278 According to the accuracy requirement of user performance simulation, 279 the location where the measurement is done is very important. The 280 intuitive approach is to placed the measuring probes or servers on 281 the edge, in proximity to the end users. In 4G LTE cellular network 282 as a typical case, the performance measurement server can be located 283 in proximity of base stations (or an aggregation point). There is 284 only at most one hop difference in the end-to-end path between a real 285 end user and a destination. 287 There is one question about the location of NHE deployment. If 288 performance measurement server is located on the edge, is NHE 289 resolver should be located in the same place? In another word: are 290 they deployed in pairs? The simple answer is yes which enhance the 291 efficiency of cache if the resolver is deployed on the edge. NHE DNS 292 resolver can be a cache sever forwarding cache missed query to the 293 ISP normal full functional resolver. The only concern is if the 294 caching resolver is located closely to end users, it may lose good 295 cache hit probability. 297 4.3. Less measurement traffic 299 Since the IPv6/IPv4 performance varies per domain, there is a fear of 300 having to generate a lot of measuring traffic in NHE. There are two 301 approaches may be helpful to generate less traffic. One is to keep a 302 moderate size of NHE filtering list including, for example, top 1k ~ 303 5k popular domains in the cache. To achieve that, the NHE resolver 304 should not only Push the cache , but also a popularity value of each 305 domain (the number of cache hits). In addition, the size of the 306 filtering list generated by measurement server can be configurable as 307 well according to ISP local policy. 309 The second approach to reduce the measurement traffic is to use 310 passive measurement. The round-trip delay of DNS lookup of a 311 particular domain is trivial in most of case if cache hit. So 312 passive measurement should focus on monitoring TCP connection of 313 specific destination. Suppose there are 1000 top popular domains in 314 the measurement list which means thousands TCP connections is to be 315 put into passive monitoring to measure the round-trip delay. 317 One optional approach of limiting the size of measuring list is to 318 focus on top Apps other than top domains. ISP can cooperated with CP 319 to maintain a domain list of top Apps for NHE. 321 5. Security Considerations 323 NHE adopt filtering in the resolver so it will break DNSSEC and omit 324 RRSIG records covering type AAAA as well as AAAA record. The scope 325 of DNSSEC break is limited between client and resolver, which is not 326 the typical scenario of DNSSEC though, in the case clients ask for 327 RRSIG record of AAAA. 329 Filtering AAAA records cause DNS incoherency in the end users 330 perspective which may causes some risks if end user's application 331 depend on the integrity of DNS data. To reduce this risk, ISP 332 resolver would artificially delay the AAAA answers if positive answer 333 is received. 335 6. IANA considerations 337 No IANA considerations for this memo 339 7. Acknowledgments 341 Acknowledgments are given to Geoff Huston, David Schinazi, Marc 342 Blanchet, and Paul Vixie who gave comments and suggestions on this 343 memo. 345 8. References 347 [Filtering-AAAA] 348 "Filter AAAA option in BIND 9", August 2017, 349 . 351 [Less-painful] 352 Yahoo, "IPv6 and recursive resolvers:How do we make the 353 transition less painful?", March 2010, 354 . 356 [NHE-GitHub] 357 BII, "GitHub Repository of Network-side Happy Eyeballs", 358 . 361 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 362 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 363 September 1999, . 365 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 366 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 367 2012, . 369 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 370 Better Connectivity Using Concurrency", RFC 8305, 371 DOI 10.17487/RFC8305, December 2017, 372 . 374 Authors' Addresses 376 Chongfeng Xie 377 China Telecom 378 No.118 Xizhimennei street, Xicheng District 379 Beijing 100035 380 P. R. China 382 Email: xiechf.bri@chinatelecom.cn 384 Linjian Song 385 Beijing Internet Institute 386 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA 387 Beijing 100176 388 P. R. China 390 Email: songlinjian@gmail.com