idnits 2.17.1 draft-bajpai-happy-01.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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3938 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AS 680' is mentioned on line 287, but not defined == Unused Reference: 'I-D.ietf-6man-addr-select-opt' is defined on line 308, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-10 -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Bajpai 3 Internet-Draft J. Schoenwaelder 4 Intended status: Standards Track Jacobs University Bremen 5 Expires: January 15, 2014 July 14, 2013 7 Measuring the Effects of Happy Eyeballs 8 draft-bajpai-happy-01.txt 10 Abstract 12 The IETF has developed solutions that promote a healthy IPv4 and IPv6 13 co-existence. The happy eyeballs algorithm for instance, provides 14 recommendations to application developers to help prevent bad user 15 experience in situations where IPv6 connectivity is broken. This 16 document describes a metric used to measure the effects of the happy 17 eyeballs algorithm. The insights uncovered by analysing the data 18 from multiple locations is discussed. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 15, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. IPv6 Upgrade Policy . . . . . . . . . . . . . . . . . . . . . 2 56 3. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 4 60 7. Measurement Trials . . . . . . . . . . . . . . . . . . . . . 5 61 8. Data Analysis Insights . . . . . . . . . . . . . . . . . . . 5 62 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Informative References . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 The function getaddrinfo(...) resolves a service name to a list of 69 endpoints in an order that prioritizes an IPv6-upgrade path 70 [RFC6724]. The order can dramatically reduce the application's 71 responsiveness when IPv6 connectivity is broken. The degraded user 72 experience can be subverted by implementing the happy eyeballs 73 algorithm [RFC6555]. The algorithm recommends that a host, after 74 resolving the service name, tries a TCP connect(...) to the first 75 endpoint. However, instead of waiting for a timeout, it waits for 76 300ms, after which it must initiate another TCP connect(...) to an 77 endpoint with a different address family and start a competition to 78 pick the one that completes first. 80 This document describes a metric used to measure the effects of the 81 happy eyeballs algorithm. The insights uncovered by analysing the 82 data from multiple locations is discussed. 84 2. IPv6 Upgrade Policy 86 The happy eyeballs algorithm as defined in [RFC6555] biases its path 87 selection in favor of IPv6 by design. The connection establishment 88 race has been handicapped for the following reasons: 90 o Carrier-grade NATs (CGNs) establish a binding for each connection 91 request. Dual-stack hosts by preferring IPv6 connection routes, 92 reduce their contention towards the critical IPv4 address space. 94 o The IPv4 traffic may be billed by Operation Support Systems (OSS) 95 in some networks. Techniques that help move this traffic to IPv6 96 networks reduce costs. 98 o Middleboxes maintain state for each incoming connection request. 99 If the dual-stacked hosts prefer IPv6 path, the load on load 100 balancers and peering links reduces automatically. This reduces 101 the investment on IPv4, and encourages IPv6 migration. 103 3. Happy Eyeballs 105 The happy eyeballs algorithm defined in [RFC6555] honors the IPv6 106 upgrade policy. It is therefore not designed to encourage aggressive 107 connection requests over IPv4 and IPv6, but instead to satisfy the 108 following goals: 110 o The connection requests must be made in an order that honors the 111 destination-address selection policy as defined in [RFC6724], 112 unless overriden by user or network configuration. The client 113 must prefer IPv6 over IPv4 whenever the policy is not known. 115 o The connection initiation must quickly fallback to IPv4 to reduce 116 the wait times for a dual-stack host in situations where the IPv6 117 path is broken. 119 o The network path and destination servers must not be thrashed by 120 mere doubling of traffic by making simulataneous connection 121 requests over IPv4 and IPv6. The connection requests over IPv6 122 must be given a fair chance to succeed to reduce load on IPv4, 123 before a connection over IPv4 is attempted. 125 However, applications on top of TCP will not be happy eyeballed only 126 in scenarios where IPv6 connectivity is broken, but also in scenarios 127 where the dual-stack host enjoys comparable IPv6 connectivity. We 128 want to measure how much imposition does such a user experience in 129 reality by measuring the effects of the happy eyeballs timer value. 131 The recommended timer value is 150-250ms [RFC6555]. However, Chrome 132 uses 300ms. Firefox appears to be using 250ms while an early open- 133 source implementation of happy eyeballs seems to recommend 100ms 134 [Perreault]. We want to affirm the right value by measuring TCP 135 connection establishment times experienced by dual-stacked hosts in 136 real environments over IPv4 and IPv6. 138 4. Related Work 139 Fred Baker in [RFC6556] describes metrics and testbed configurations 140 to measure how quickly an application can reliably establish 141 connections from a dual-stacked environment. The metrics measure 142 whether the communication establishment time is same regardless of 143 the address family and the routing viability available to a dual- 144 stacked host. The metrics defined in [RFC6556] is different in three 145 ways: 147 o DNS is accounted in connection establishment time. Our metric 148 does not take this into account. Accounting DNS resolution may 149 invite multiple input factors (slow resolvers) that may bias our 150 TCP connection establishment time results. In addition, according 151 to [RFC6555], the 300ms advantage applies to the first address 152 family after the getaddrinfo(...) call. From a programming 153 perspective, an application calls getaddrinfo(...) and that does 154 its job, regardless of which address family is used. 156 o The testbed configuration in [RFC6556] is more passive than 157 active. An external analyser is used to passively observe the 158 client's traffic using tcpdump. There is no active measurement 159 test, instead the routers along the path are configured to control 160 what connectivity route is taken. We on the other hand, have an 161 active measurement test running on the client. The test is 162 agnostic to network path configuration since it independently 163 tries a TCP connection to each connectivity route. It also 164 actively measures the time taken instead of relying on an external 165 analyser program. 167 o The testbed setup in [RFC6556] is designed for a controlled 168 environment. The router in the path is configured to disrupt all 169 but one routes to control the prefix used in the connection. As 170 such, the test is repeated N times with different router 171 configurations to try all possible permutations of route 172 connectivity. Our measurement test is agnostic to the network 173 path and does not require path configuration changes. 175 5. Metric 177 We have defined a metric that uses the TCP connection establishment 178 times as a parameter to measure the algorithm's effects. The 179 methodology also helps examine the impact of tunneling mechanisms 180 employed by early adopters. The input parameter of the metric is a 181 (IP address, port number) tuple and the output is the connection 182 establishment time, typically measured in microseconds. 184 6. Implementation 185 We have developed happy, a simple TCP happy eyeballs probing tool 186 that conforms to the definition of our metric. It uses non-blocking 187 connect(...) calls to concurrently establish connections to all 188 endpoints of a service and measures the elapsed time. The tool 189 enforces a small delay between concurrent connect(...) calls to avoid 190 bursty TCP SYN traffic. The initially performed service name 191 resolution is not accounted in the connection establishment elapsed 192 time. 194 7. Measurement Trials 196 We use Alexa's top 1M service names as input to prepare a top 100 197 dual-stacked service names list. We run happy on our internal test- 198 bed of multiple measurement agents with different flavors of 199 connectivity ranging from native IPv4, native IPv6, IPv6 tunnel 200 broker endpoints, Teredo and tunnelled IPv4. The list of Measurement 201 Agents (MAs) is shown in Table 1. 203 +------+---------+---------+--------------+-------------+-----------+ 204 | MA # | IPv4 AS | IPv6 AS | City | Country | Platform | 205 +------+---------+---------+--------------+-------------+-----------+ 206 | 1 | AS680 | AS680 | Bremen | Germany | Mac OS X | 207 | 2 | AS680 | AS680 | Braunschweig | Germany | GNU/Linux | 208 | 3 | AS13237 | Teredo | Berlin | Germany | GNU/Linux | 209 | 4 | AS31334 | AS6939 | Bremen | Germany | OpenWrt | 210 | 5 | AS680 | AS680 | Bremen | Germany | SamKnows | 211 | 6 | AS31334 | AS6939 | Bremen | Germany | SamKnows | 212 | 7 | AS24956 | AS24956 | Braunschweig | Germany | SamKnows | 213 | 8 | AS3320 | AS3320 | Bremen | Germany | SamKnows | 214 | 9 | AS5607 | AS5607 | London | England | SamKnows | 215 | 10 | AS3269 | AS3269 | Torino | Italy | SamKnows | 216 | 11 | AS8903 | AS8903 | Madrid | Spain | SamKnows | 217 | 12 | AS2614 | AS2614 | Timisoara | Romania | SamKnows | 218 | 13 | AS13030 | AS13030 | Olten | Switzerland | SamKnows | 219 | 14 | AS2856 | AS2856 | Ipswich | England | SamKnows | 220 +------+---------+---------+--------------+-------------+-----------+ 222 Table 1: A List of Measurement Agents (MAs) 224 8. Data Analysis Insights 226 The initial results show higher connection times and variations over 227 IPv6 as shown in Figure 1. The services themselves may not be 228 comparable amongst one another due to the sheer nature of different 229 routing paths traversed by the packets. 231 1e+06 ++-----+-----+------+-----+------+------+-----+------+-----+ 232 +mean (v4) ****** + + + + + + + 233 +mean (v6) ###### : : : : : : : 234 * + * * : : : : : : * * * 235 * : * * : : : : : :** * * 236 |* : * ##*# : : : : : :** * * 237 100000 +*.......*.#.**.......................................****** 238 +* : *##*:* : : : : : #****** 239 +* : **#*:* : : : : : * ***** 240 +* :*****:*# : : : : : * **** 241 +*# :**** : * : # : : : * ** * 242 10000 +*#*******.....**#*#*##**#####*##*####*#########*##*#*...*.. 243 + ** *** : * ****** ********:*******************: * : 244 + * :* : : : : : : *: * : 245 + * :* : : : : : : *: * : 246 + : : : : : : : : : 247 + + + + + + + + + + 248 1000 ++-----+-----+------+-----+------+------+-----+------+-----+ 249 0 10 20 30 40 50 60 70 80 90 250 Service Names 252 Figure 1: service vs {mean_v4, mean_v6}: samsbox1 (30 days, 300ms) 254 Fig. 1. shows the average TCP connection establishment times for both 255 IPv4 and IPv6. The Measurement Agent (MA) is a SamKnows probe 256 connected at Jacobs University Bremen. It receives IPv4 and IPv6 257 connectivity via German Research Network (DFN) [AS 680]. A PDF 258 rendering of the plot is available at [mean]. 260 1e+06 ++-----+-----+------+-----+------+------+-----+------+-----+ 261 +std (v4) ****** + + + + + + + 262 +std (v6) ###### : : : : : : : 263 + + + : : : : : : # : 264 100000 ++.......*...**..........................................#.* 265 + : * ##** : : : : : : * # * 266 * # : * # ** : # : : : :***# * 267 #* # # : * **#*#* * #*# # # #: # : :***##* 268 10000 #*.#.*..**.**..**#..*.#**.#.#..##*...#..##......*...*.***..* 269 # *#** *** * : **** * #**#### *#** #* ### :#* #*** # * * 270 +#*#** **** : * ****#* #**###* *#* # * # # #** #* * # * * 271 +##*#**#*** : * ****** #********#****************** *# **: 272 |# :##* : : : * : : : #* *: 273 1000 ++......#...........................................#.....*. 274 + : : : : : : : : : 275 + : : : : : : : : : 276 + + + + + + + + + + 277 100 ++-----+-----+------+-----+------+------+-----+------+-----+ 278 0 10 20 30 40 50 60 70 80 90 279 Service Names 281 Figure 2: service vs {std_v4, std_v6}: samsbox1 (30 days, 300ms) 283 Figure 2 shows the standard deviation of the TCP connection 284 establishment times for both IPv4 and IPv6. The Measurement Agent 285 (MA) is a SamKnows probe connected at Jacobs University Bremen. It 286 receives IPv4 and IPv6 connectivity via German Research Network (DFN) 287 [AS 680]. A PDF rendering of the plot is available at [std]. 289 It appears that an application never uses IPv6 using Teredo except in 290 situations where IPv4 reachability of the destination service is 291 broken. We noticed, that a 300ms advantage leaves a dual-stacked 292 host only 1% chance to prefer a IPv4 route even though it may be 293 significantly faster than IPv6. We also measured the margin by which 294 happy eyeballs is inhibiting the fastest available route by comparing 295 the slowness of a happy eyeballed winner to that of the loser. 297 9. Conclusions 299 We have performed a preliminary study on measuring the effects of 300 happy eyeballs. We noticed several cases where the algorithm does 301 not select the best route and instead hampers the user experience. 302 We are working towards running this test on a large-scale measurement 303 platform to develop a more comprehensive picture to help improve the 304 algorithm. 306 10. Informative References 308 [I-D.ietf-6man-addr-select-opt] 309 Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 310 Address Selection Policy using DHCPv6", draft-ietf-6man- 311 addr-select-opt-10 (work in progress), April 2013. 313 [Perreault] 314 Perreault, S., "Happy Eyeballs in Erlang", July 2013, 315 . 318 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 319 Dual-Stack Hosts", RFC 6555, April 2012. 321 [RFC6556] Baker, F., "Testing Eyeball Happiness", RFC 6556, April 322 2012. 324 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 325 "Default Address Selection for Internet Protocol Version 6 326 (IPv6)", RFC 6724, September 2012. 328 [mean] Bajpai, V., "IPv4 and IPv6 Average Connection 329 Establishment Times", July 2013, . 333 [std] Bajpai, V., "IPv4 and IPv6 Connection Establishment Times 334 Variations", July 2013, . 338 Authors' Addresses 340 Vaibhav Bajpai 341 Jacobs University Bremen 342 Campus Ring 1 343 28759 Bremen 344 Germany 346 Phone: +49 421 200 3112 347 Email: v.bajpai@jacobs-university.de 348 Juergen Schoenwaelder 349 Jacobs University Bremen 350 Campus Ring 1 351 28759 Bremen 352 Germany 354 Phone: +49 421 200 3587 355 Email: j.schoenwaelder@jacobs-university.de