idnits 2.17.1 draft-wing-tsvwg-happy-eyeballs-sctp-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2010) is 4931 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) == Outdated reference: A later version (-07) exists of draft-tuexen-sctp-udp-encaps-05 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG D. Wing 3 Internet-Draft P. Natarajan 4 Intended status: Standards Track Cisco 5 Expires: April 28, 2011 October 25, 2010 7 Happy Eyeballs: Trending Towards Success with SCTP 8 draft-wing-tsvwg-happy-eyeballs-sctp-02 10 Abstract 12 This document describes how to seamlessly migrate HTTP from running 13 over TCP to running over SCTP, without negative impact to the user 14 experience. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. HTTP Client Recommendations . . . . . . . . . . . . . . . . . . 4 60 5. Additional Considerations . . . . . . . . . . . . . . . . . . . 6 61 5.1. Additional Network and Host Traffic . . . . . . . . . . . . 6 62 5.2. Abandon Non-Winning Connections . . . . . . . . . . . . . . 6 63 5.3. Flush or Expire Cache . . . . . . . . . . . . . . . . . . . 6 64 5.4. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 9.2. Informational References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 HTTP ("The Web") is one of the most visible and time-critical 76 applications that is used by nearly every Internet user. Research 77 shows that web downloads over TCP suffer from head-of-line (HOL) 78 blocking and poor response times on lossy networks. A multistreamed 79 transport such as SCTP reduces HOL blocking and improves user 80 response times as compared to TCP [Natarajan]. SCTP provides further 81 improvements on networks with high latency, low bandwidth, or high 82 loss -- typical of today's wireless and wide-area networks. For 83 these reasons there is interest in running HTTP over SCTP 84 [I-D.natarajan-http-over-sctp]. 86 In order to successfully transition to SCTP, it is necessary that the 87 SCTP connection establishment time is nearly identical (or lower) as 88 compared to TCP. Due to IPv4 NAT and firewalls, lack of SCTP running 89 on servers, and lack of a DNS-based mechanism indicating SCTP server 90 support, SCTP cannot be tried, allowed to timeout, and then TCP tried 91 -- because such a delay will be unacceptable to users. 93 This document suggests a mechanism for applications to quickly 94 determine if SCTP or TCP is the most optimal transport protocol to 95 use with a particular server. 97 Once SCTP (or TCP) is successful, the application trends towards 98 preferring that transport protocol for subsequent connections to that 99 server. Thus, repeated use of the application does not cause 100 repeated SCTP (or TCP) probes. 102 The application recommendations in this document are primarily for 103 HTTP clients ("web browsers") and may also be helpful for other time- 104 sensitive applications. 106 2. Notational Conventions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Problem Statement 114 It is important that the same URI and hostname be used for SCTP and 115 TCP. That is, "sctp.example.com" or "www.sctp.example.com" is not 116 viable for successful deployment of SCTP. Using separate namespaces 117 causes namespace fragmentation and reduces the ability for users to 118 share URIs and hostnames, and complicates printed material (e.g., 119 advertising) that include the URI or hostname. 121 Unlike IPv6 which has an AAAA record, there is no DNS query that 122 indicates a host supports SCTP [RFC4960], and the HTTP URI scheme is 123 not extensible to support an SRV query that could provide such 124 support. Even if there was, it isn't possible to determine if a 125 middlebox, such as a firewall or a NAT, would block the SCTP 126 connection. 128 Thus, the same URI as used for TCP must be accessible via SCTP. The 129 only way to accomplish that is to try connecting using SCTP. 131 4. HTTP Client Recommendations 133 To provide fast connections for users, HTTP clients should make 134 connections quickly over various technologies, automatically tune 135 itself to avoid flooding the network with unnecessary connections 136 (i.e., for technologies that have not made successful connections), 137 and occasionally flush its self-tuning. 139 Due to the proliferation of NATs on the IPv4 Internet the best 140 success for SCTP can be achieved by attempting both native SCTP 141 connections and SCTP-over-UDP [I-D.tuexen-sctp-udp-encaps] 142 connections. 144 For SCTP the following parameters are used: 146 SWAIT: Application-wide wait time for an SCTP association attempt to 147 complete. Default value of 50ms is RECOMMENDED. 149 PREF: This denotes per-destination transport preference. Possible 150 values are "TCP", "SCTP", and "BOTH". Default value of 151 "BOTH" is RECOMMENDED. 153 Client Server 154 | | 155 1. |----TCP SYN----------->| 156 2. |====SCTP INIT=========>| 157 3. | | 158 4. |<---TCP SYN+ACK--------| 159 5. |----TCP ACK----------->| 160 6. | | 161 7. |<===SCTP INIT+ACK======| 162 8. | | 163 9. |----TCP RST----------->| 164 10. | | 165 11. |====SCTP COOKIE-ECHO==>| 166 12. |<===SCTP COOKIE-ACK====| 168 Figure 1: Message flow 170 In the above diagram, the client sends a TCP SYN and SCTP INIT at the 171 same time (1). The client receives TCP SYN+ACK (4) before receiving 172 SCTP INIT+ACK (7) which of course could arrive in the opposite order. 173 Upon receiving the SCTP INIT+ACK (7), the client knows that SCTP is 174 working and abandons the TCP connection before sending TCP user data 175 (9). User data can be sent with the SCTP COOKIE-ECHO (11). 177 The HTTP client starts several threads in order to minimize the user- 178 noticeable delay ("dead time") during the connection attempts. The 179 client starts one or more threads based on the following logic: 181 If ((PREF == BOTH) or (PREF == SCTP)) start thread 1. If making a 182 connection using IPv4 start thread 2. 184 If ((PREF == BOTH) or (PREF == TCP)) start thread 3. 186 thread 1 (SCTP): 188 * Attempt to connect using SCTP (i.e., send SCTP INIT) 190 thread 2 (SCTP over UDP): 192 * Attempt to connect using SCTP over UDP (i.e., send SCTP INIT 193 over UDP) 195 thread 3 (TCP): 197 * Attempt to connect using TCP 199 If an SCTP association attempt was made by a thread, the HTTP client 200 waits for at least K ms; K = max(SWAIT, time taken for the TCP 201 connection to complete). If the TCP connection finishes during this 202 wait period, the HTTP client MAY choose TCP for the current HTTP 203 transfer but MUST wait until K ms to figure if the SCTP association 204 can be completed. 206 If the HTTP client did not choose TCP during the wait period and the 207 SCTP association completes successfully, the HTTP client prefers SCTP 208 over TCP connections and abandons the TCP connection. 210 After a connection is successful, we want to adjust the per- 211 destination preference for this destination. It is not recommended 212 to dynamically adjust the application-wide default value for SWAIT. 213 If the SCTP association was successful, set destination's 214 PREF="SCTP", else set PREF="TCP". 216 5. Additional Considerations 218 This section discusses considerations and requirements that are 219 common to new technology deployment. 221 5.1. Additional Network and Host Traffic 223 Additional network traffic and additional server load is created due 224 to these recommendations and mitigated by application-wide and per- 225 destination timer adjustments. The procedures described in this 226 document retain a quality user experience while transitioning from 227 TCP to SCTP. The quality user experience benefits the user but to 228 the detriment of the network and server that are serving the user. 230 5.2. Abandon Non-Winning Connections 232 It is RECOMMENDED that the non-winning connections be abandoned, even 233 though they could be used to download content. 235 5.3. Flush or Expire Cache 237 Because every network has different characteristics (e.g., a 238 middlebox that permits or blocks SCTP) the SCTP parameters (SWAIT and 239 PREF) SHOULD be reset to their default whenever the host is connected 240 to a new network ([cx-osx], [cx-win]). However, in some instances 241 the application and the host are unaware the network connectivity has 242 changed (e.g., when behind a NAT) so it is RECOMMENDED that per- 243 destination values expire after 10 minutes of inactivity. 245 5.4. Multiple Interfaces 247 Interaction of the suggestions in this document with multiple 248 interfaces is for further study. 250 6. Security Considerations 252 [[Placeholder.]] 254 7. Acknowledgements 256 The mechanism described in this paper was inspired by Stuart 257 Cheshire's discussion at the IAB Plenary at IETF72, and how ICE 258 [RFC5245] tests connectivity to different transports. 260 Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van 261 Beijnum for fostering the creation of this document. 263 Thanks to Scott Brim, Stig Venaas, and Andrew Yourtchenko for 264 providing feedback on the document. 266 8. IANA Considerations 268 This document has no IANA actions. 270 9. References 272 9.1. Normative References 274 [I-D.tuexen-sctp-udp-encaps] 275 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 276 Packets", draft-tuexen-sctp-udp-encaps-05 (work in 277 progress), July 2010. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 283 RFC 4960, September 2007. 285 9.2. Informational References 287 [I-D.natarajan-http-over-sctp] 288 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 289 "Using SCTP as a Transport Layer Protocol for HTTP", 290 draft-natarajan-http-over-sctp-02 (work in progress), 291 July 2009. 293 [Natarajan] 294 Natarajan, P., "Leveraging Innovative Transport Layer 295 Services for Improved Application Performance", 296 February 2009, . 299 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 300 (ICE): A Protocol for Network Address Translator (NAT) 301 Traversal for Offer/Answer Protocols", RFC 5245, 302 April 2010. 304 [cx-osx] Adium, "AIHostReachabilityMonitor", June 2009, 305 . 307 [cx-win] Microsoft, "NetworkChange.NetworkAvailabilityChanged 308 Event", June 2009, . 313 Authors' Addresses 315 Dan Wing 316 Cisco Systems, Inc. 317 170 West Tasman Drive 318 San Jose, CA 95134 319 USA 321 Email: dwing@cisco.com 323 Preethi Natarajan 324 Cisco Systems, Inc. 325 170 West Tasman Drive 326 San Jose, CA 95134 327 USA 329 Email: prenatar@cisco.com