idnits 2.17.1 draft-baker-bmwg-testing-eyeball-happiness-05.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 abstract seems to contain references ([RFC2119]), 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 (August 15, 2011) is 4637 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-happy-eyeballs-03 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Methodology F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational August 15, 2011 5 Expires: February 16, 2012 7 Testing Eyeball Happiness 8 draft-baker-bmwg-testing-eyeball-happiness-05 10 Abstract 12 The amount of time it takes to establish a session using common 13 transport APIs in dual stack networks and networks with filtering 14 such as proposed in BCP 38 is a barrier to IPv6 deployment. This 15 note describes a test that can be used to determine whether an 16 application can reliably establish sessions quickly in a complex 17 environment such as dual stack (IPv4+IPv6) deployment or IPv6 18 deployment with multiple prefixes and upstream ingress filtering. 19 This test is not a test of a specific algorithm, but of the external 20 behavior of the system as a black box. Any algorithm that has the 21 intended external behavior will be accepted by it. 23 Requirements 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 16, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Measuring Eyeball Happiness . . . . . . . . . . . . . . . . . 4 65 2.1. Happy Eyeballs test bed configuration . . . . . . . . . . 4 66 2.2. Happy Eyeballs test procedure . . . . . . . . . . . . . . 6 67 2.3. Happy Eyeballs metrics . . . . . . . . . . . . . . . . . . 7 68 2.3.1. Metric: Session Setup Interval . . . . . . . . . . . . 7 69 2.3.2. Metric: Maximum Session Setup Interval . . . . . . . . 8 70 2.3.3. Metric: Minimum Session Setup Interval . . . . . . . . 9 71 2.3.4. Descriptive Metric: Attempt pattern . . . . . . . . . 9 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 The Happy Eyeballs [I-D.ietf-v6ops-happy-eyeballs] specification 84 notes an issue in deployed multi-prefix IPv6-only and dual stack 85 networks, and proposes a correction. [RFC5461] similarly looks at 86 TCP's response to so-called "soft errors" (ICMP host and network 87 unreachable messages), pointing out an issue and a set of possible 88 solutions. 90 In a dual stack network (i.e., one that contains both IPv4 [RFC0791] 91 and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network 92 that uses multiple prefixes allocated by upstream providers that 93 implement BCP 38 Ingress Filtering [RFC2827], the fact that two hosts 94 that need to communicate have addresses using the same architecture 95 does not imply that the network has usable routes connecting them, or 96 that those addresses are useful to the applications in question. In 97 addition, the process of establishing a session using the Sockets API 98 [RFC3493] is generally described in terms of obtaining a list of 99 possible addresses for a peer (which will normally include both IPv4 100 and IPv6 addresses) using getaddrinfo() and trying them in sequence 101 until one succeeds or all have failed. This naive algorithm, if 102 implemented as described, has the side-effect of making the worst 103 case delay in establishing a session far longer than human patience 104 normally allows. 106 This has the effect of discouraging users from enabling IPv6 in their 107 equipment, or content providers from offering AAAA records for their 108 services. 110 This note describes a test to determine how quickly an application 111 can reliably open sessions in a complex environment, such as dual 112 stack (IPv4+IPv6) deployment or IPv6 deployment with multiple 113 prefixes and upstream ingress filtering. This is not a test of a 114 specific algorithm, but a measurement of the external behavior of the 115 application and its host system as a black box. The "happy eyeballs" 116 question is this: how long does it take an application to open a 117 session with a server or peer, under best case and worst case 118 conditions? 120 The methods defined here make the assumption that the initial 121 communication set-up of many applications can be summarized by the 122 measuring the DNS query/response and transport layer handshaking, 123 because no application-layer communication takes place without these 124 steps. 126 The methods and metrics defined in this note are ideally suited for 127 Laboratory operation, as this affords the greatest degree of control 128 to modify configurations quickly and produce consistent results. 130 However, if the device under test is operated as a single user with 131 limited query and stream generation, then there's no concern about 132 overloading production network devices with a single "set of 133 eyeballs". Therefore, these procedures and metrics MAY be applicable 134 to production network application, as long as the injected traffic 135 represents a single user's typical traffic load, and the testers 136 adhere to the precautions of the relevant network with respect to re- 137 configuration of devices in production. 139 2. Measuring Eyeball Happiness 141 This measurement determines the amount of time it takes an 142 application to establish a session with a peer in the presence of at 143 least one IPv4 and multiple IPv6 prefixes and a variety of network 144 behaviors. ISPs are reporting that a host (MacOSX, Windows, Linux, 145 FreeBSD, etc) that has more than one address (an IPv4 and an IPv6 146 address, two global IPv6 addresses, etc) may serially try addresses, 147 allowing each TCP setup to expire, taking several seconds for each 148 attempt. There have been reports of lengthy session setup times - in 149 various application and OS combinations anywhere from multi-second to 150 half an hour - as a result. The amount of time necessary to 151 establish communication between two entities should be approximately 152 the same regardless of the type of address chosen or the viability of 153 routing in the specific network; users will expect this time to be 154 consistent with their current experience (else, happiness is at 155 risk). 157 2.1. Happy Eyeballs test bed configuration 159 The configuration of equipment and applications is as shown in 160 Figure 1. 162 +--------+ | |198.51.100.0/24 163 |Protocol| |192.0.2.0/24 |2001:DB8:0:2::/64 164 |Analyzer+-+2001:DB8:1:0::/64 |2001:DB8:1:4::/64 165 +--------+ |2001:DB8:0:1::/64 |2001:DB8:2:4::/64 166 | | 167 +-----+ | | +-----+ 168 |Alice+-+ +-+ Bob | 169 +-----+ | +-------+ +-------+ | +-----+ 170 +-+Router1| |Router2+-+ 171 +-----+ | +-----+-+ +-+-----+ | 172 | DNS +-+ | | | 173 +-----+ | -+------+- | 174 | 203.0.113.0/24 | 175 | 2001:DB8:0:3::/64 | 177 Figure 1: Generic Test Environment 179 Alice is the unit being measured, the computer running the process 180 that will establish a session with Bob for the application in 181 question. DNS is represented in the diagram as a separate system, as 182 is the protocol analyzer that will watch Alice's traffic. This is 183 not absolutely necessary; If one computer can run tcpdump and a DNS 184 server process - and for that matter subsume the routers - that is 185 acceptable. The units are separated in the test for purposes of 186 clarity. 188 On each test run, configuration is performed in Router 1 to permit 189 only one route to work. There are various ways this can be 190 accomplished, including but not limited to installing 192 o a filter that drops datagrams to Bob resulting in an ICMP 193 "administratively prohibited", 195 o a filter that silently drops datagrams to Bob, 197 o a null route or removing the route to one of Bob's prefixes, 198 resulting in an ICMP "destination unreachable", and 200 o a middleware program that responds with a TCP RST. 202 o Path MTU issues 204 The Path MTU Discovery [RFC1191][RFC1981] matter requires some 205 explanation. With IPv6, and with IPv4 when "Do Not Fragment" is set, 206 a router with a message too large for an interface discards it and 207 replies with an ICMPv4 "Destination Unreachable: Datagram Too Big" or 208 ICMPv6 "Packet Too Big". If this packet is lost, the source doesn't 209 know what size to fragment to and has no indication that 210 fragmentation is required. A configuration for this scenario would 211 set the MTU on 203.0.113.0/24 or 2001:DB8:0:3::/64 to the smallest 212 allowed by the address family (576 or 1280) and disable generation of 213 the indicated ICMP message. Note that [RFC4821] is intended to 214 address these issues. 216 The tester should try different methods to determine whether 217 differences in this configuration make a difference in the test. For 218 example, one might find that the application under test responds 219 differently to a TCP RST than to a silent packet loss. Each of these 220 scenarios should be tested; if doing so is too difficult, the most 221 important is the silent packet loss case, as it is the worst case. 223 2.2. Happy Eyeballs test procedure 225 Consider a network as described in Section 2.1. Alice and Bob each 226 have a set of one or more IPv4 and two or more IPv6 addresses. Bob's 227 are in DNS, where Alice can find them; Alice's and others may be 228 there as well, but are not relevant to the test. Routers 1 and 2 are 229 configured to route the relevant prefixes. Different measurement 230 trials revise an access list or null route in Router 1 that would 231 prevent traffic Alice->Bob using each of Bob's addresses. If Bob has 232 a total of N addresses, we run the measurement at least N times, 233 permitting exactly one of the addresses to enjoy end to end 234 communication each time. If the DNS service randomizes the order of 235 the addresses, this may not result in a test requiring establishment 236 of a connection to all of the addresses; in this case, the test will 237 have to be run repeatedly until in at least one instance a TCP SYN or 238 its equivalent is seen for each relevant address. The tester should 239 either flush the resolver cache between iterations, to force repeated 240 DNS resolution, or should wait for at least the DNS RR TTL on each 241 resource record. In the latter case, the tester should also observe 242 DNS re-resolving; if not, the application is not correctly using DNS. 244 This specification assumes common LAN technology with no competing 245 traffic and nominal propagation delays, so that they are not a factor 246 in the measurement. 248 The objective is to measure the amount of time required to establish 249 a session. This includes the time from Alice's initial DNS request 250 through one or more attempts to establish a session to the session 251 being established, as seen in the LAN trace. The simplest way to 252 measure this will be to put a traffic analyzer on Alice's point of 253 attachment and capture the messages exchanged by Alice. 255 DNS Server Alice Bob 256 | | | 257 1. |<--www.example.com A------| | 258 2. |<--www.example.com AAAA---| | 259 3. |---198.51.100.1---------->| | 260 4. |---2001:DB8:0:2::1------->| | 261 5. | | | 262 6. | |--TCP SYN, IPv6--->X |<*********** 263 7. | |--TCP SYN, IPv6--->X | | 264 8. | |--TCP SYN, IPv6--->X | TCP 3wHS 265 9. | | | Time 266 10. | |--TCP SYN, IPv4------->|(any family) 267 11. | |<-TCP SYN+ACK, IPv4----| | 268 12. | |--TCP ACK, IPv4------->|<*********** 270 Figure 2: Message flow using TCP 272 In a TCP-based application (Figure 2), that would be from the DNS 273 request on line 1 through the first completion of a TCP three-way 274 handshake, the transmission on line 12. 276 DNS Server Alice Bob 277 | | | 278 1. |<--www.example.com A------| | 279 2. |<--www.example.com AAAA---| | 280 3. |---198.51.100.1---------->| | 281 4. |---2001:DB8:0:2::1------->| | 282 5. | | | 283 6. | |--UDP Request, IPv6-->X|<--------- 284 7. | |--UDP Request, IPv6-->X| first 285 8. | |--UDP Request, IPv6-->X| request/ 286 9. | | | response 287 10. | |--UDP Request, IPv4--->| success 288 11. | |<-UDP Response, IPv4---|<--------- 290 Figure 3: Message flow using UDP 292 In a UDP-based application (Figure 3), that would be from the DNS 293 request (line 1) through one or more UDP Requests (lines 6-10) until 294 a UDP Response is seen (line 11). 296 When using other transports, the methodology will have to be 297 specified in context; it should measure the same event. 299 2.3. Happy Eyeballs metrics 301 The measurements taken are the duration of the interval from the 302 initial DNS request until the session is seen to have been 303 established, as described in Section 2.2. We are interested in the 304 shortest and longest durations (which will most likely be those that 305 send one SYN and succeed and those that send a SYN to each possible 306 address before succeeding in one of the attempts), and the pattern of 307 attempts sent to different addresses. The pattern may be to simply 308 send an attempt every