TSVWG D. Wing
Internet-Draft P. Natarajan
Intended status: Standards Track Cisco
Expires: April 28, 2011 October 25, 2010
Happy Eyeballs: Trending Towards Success with SCTP
draft-wing-tsvwg-happy-eyeballs-sctp-02
Abstract
This document describes how to seamlessly migrate HTTP from running
over TCP to running over SCTP, without negative impact to the user
experience.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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
Wing & Natarajan Expires April 28, 2011 [Page 1]
Internet-Draft Happy Eyeballs SCTP October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
4. HTTP Client Recommendations . . . . . . . . . . . . . . . . . . 4
5. Additional Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. Additional Network and Host Traffic . . . . . . . . . . . . 6
5.2. Abandon Non-Winning Connections . . . . . . . . . . . . . . 6
5.3. Flush or Expire Cache . . . . . . . . . . . . . . . . . . . 6
5.4. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informational References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Wing & Natarajan Expires April 28, 2011 [Page 2]
Internet-Draft Happy Eyeballs SCTP October 2010
1. Introduction
HTTP ("The Web") is one of the most visible and time-critical
applications that is used by nearly every Internet user. Research
shows that web downloads over TCP suffer from head-of-line (HOL)
blocking and poor response times on lossy networks. A multistreamed
transport such as SCTP reduces HOL blocking and improves user
response times as compared to TCP [Natarajan]. SCTP provides further
improvements on networks with high latency, low bandwidth, or high
loss -- typical of today's wireless and wide-area networks. For
these reasons there is interest in running HTTP over SCTP
[I-D.natarajan-http-over-sctp].
In order to successfully transition to SCTP, it is necessary that the
SCTP connection establishment time is nearly identical (or lower) as
compared to TCP. Due to IPv4 NAT and firewalls, lack of SCTP running
on servers, and lack of a DNS-based mechanism indicating SCTP server
support, SCTP cannot be tried, allowed to timeout, and then TCP tried
-- because such a delay will be unacceptable to users.
This document suggests a mechanism for applications to quickly
determine if SCTP or TCP is the most optimal transport protocol to
use with a particular server.
Once SCTP (or TCP) is successful, the application trends towards
preferring that transport protocol for subsequent connections to that
server. Thus, repeated use of the application does not cause
repeated SCTP (or TCP) probes.
The application recommendations in this document are primarily for
HTTP clients ("web browsers") and may also be helpful for other time-
sensitive applications.
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Problem Statement
It is important that the same URI and hostname be used for SCTP and
TCP. That is, "sctp.example.com" or "www.sctp.example.com" is not
viable for successful deployment of SCTP. Using separate namespaces
causes namespace fragmentation and reduces the ability for users to
share URIs and hostnames, and complicates printed material (e.g.,
Wing & Natarajan Expires April 28, 2011 [Page 3]
Internet-Draft Happy Eyeballs SCTP October 2010
advertising) that include the URI or hostname.
Unlike IPv6 which has an AAAA record, there is no DNS query that
indicates a host supports SCTP [RFC4960], and the HTTP URI scheme is
not extensible to support an SRV query that could provide such
support. Even if there was, it isn't possible to determine if a
middlebox, such as a firewall or a NAT, would block the SCTP
connection.
Thus, the same URI as used for TCP must be accessible via SCTP. The
only way to accomplish that is to try connecting using SCTP.
4. HTTP Client Recommendations
To provide fast connections for users, HTTP clients should make
connections quickly over various technologies, automatically tune
itself to avoid flooding the network with unnecessary connections
(i.e., for technologies that have not made successful connections),
and occasionally flush its self-tuning.
Due to the proliferation of NATs on the IPv4 Internet the best
success for SCTP can be achieved by attempting both native SCTP
connections and SCTP-over-UDP [I-D.tuexen-sctp-udp-encaps]
connections.
For SCTP the following parameters are used:
SWAIT: Application-wide wait time for an SCTP association attempt to
complete. Default value of 50ms is RECOMMENDED.
PREF: This denotes per-destination transport preference. Possible
values are "TCP", "SCTP", and "BOTH". Default value of
"BOTH" is RECOMMENDED.
Wing & Natarajan Expires April 28, 2011 [Page 4]
Internet-Draft Happy Eyeballs SCTP October 2010
Client Server
| |
1. |----TCP SYN----------->|
2. |====SCTP INIT=========>|
3. | |
4. |<---TCP SYN+ACK--------|
5. |----TCP ACK----------->|
6. | |
7. |<===SCTP INIT+ACK======|
8. | |
9. |----TCP RST----------->|
10. | |
11. |====SCTP COOKIE-ECHO==>|
12. |<===SCTP COOKIE-ACK====|
Figure 1: Message flow
In the above diagram, the client sends a TCP SYN and SCTP INIT at the
same time (1). The client receives TCP SYN+ACK (4) before receiving
SCTP INIT+ACK (7) which of course could arrive in the opposite order.
Upon receiving the SCTP INIT+ACK (7), the client knows that SCTP is
working and abandons the TCP connection before sending TCP user data
(9). User data can be sent with the SCTP COOKIE-ECHO (11).
The HTTP client starts several threads in order to minimize the user-
noticeable delay ("dead time") during the connection attempts. The
client starts one or more threads based on the following logic:
If ((PREF == BOTH) or (PREF == SCTP)) start thread 1. If making a
connection using IPv4 start thread 2.
If ((PREF == BOTH) or (PREF == TCP)) start thread 3.
thread 1 (SCTP):
* Attempt to connect using SCTP (i.e., send SCTP INIT)
thread 2 (SCTP over UDP):
* Attempt to connect using SCTP over UDP (i.e., send SCTP INIT
over UDP)
thread 3 (TCP):
* Attempt to connect using TCP
If an SCTP association attempt was made by a thread, the HTTP client
waits for at least K ms; K = max(SWAIT, time taken for the TCP
Wing & Natarajan Expires April 28, 2011 [Page 5]
Internet-Draft Happy Eyeballs SCTP October 2010
connection to complete). If the TCP connection finishes during this
wait period, the HTTP client MAY choose TCP for the current HTTP
transfer but MUST wait until K ms to figure if the SCTP association
can be completed.
If the HTTP client did not choose TCP during the wait period and the
SCTP association completes successfully, the HTTP client prefers SCTP
over TCP connections and abandons the TCP connection.
After a connection is successful, we want to adjust the per-
destination preference for this destination. It is not recommended
to dynamically adjust the application-wide default value for SWAIT.
If the SCTP association was successful, set destination's
PREF="SCTP", else set PREF="TCP".
5. Additional Considerations
This section discusses considerations and requirements that are
common to new technology deployment.
5.1. Additional Network and Host Traffic
Additional network traffic and additional server load is created due
to these recommendations and mitigated by application-wide and per-
destination timer adjustments. The procedures described in this
document retain a quality user experience while transitioning from
TCP to SCTP. The quality user experience benefits the user but to
the detriment of the network and server that are serving the user.
5.2. Abandon Non-Winning Connections
It is RECOMMENDED that the non-winning connections be abandoned, even
though they could be used to download content.
5.3. Flush or Expire Cache
Because every network has different characteristics (e.g., a
middlebox that permits or blocks SCTP) the SCTP parameters (SWAIT and
PREF) SHOULD be reset to their default whenever the host is connected
to a new network ([cx-osx], [cx-win]). However, in some instances
the application and the host are unaware the network connectivity has
changed (e.g., when behind a NAT) so it is RECOMMENDED that per-
destination values expire after 10 minutes of inactivity.
Wing & Natarajan Expires April 28, 2011 [Page 6]
Internet-Draft Happy Eyeballs SCTP October 2010
5.4. Multiple Interfaces
Interaction of the suggestions in this document with multiple
interfaces is for further study.
6. Security Considerations
[[Placeholder.]]
7. Acknowledgements
The mechanism described in this paper was inspired by Stuart
Cheshire's discussion at the IAB Plenary at IETF72, and how ICE
[RFC5245] tests connectivity to different transports.
Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van
Beijnum for fostering the creation of this document.
Thanks to Scott Brim, Stig Venaas, and Andrew Yourtchenko for
providing feedback on the document.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[I-D.tuexen-sctp-udp-encaps]
Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
Packets", draft-tuexen-sctp-udp-encaps-05 (work in
progress), July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
9.2. Informational References
[I-D.natarajan-http-over-sctp]
Natarajan, P., Amer, P., Leighton, J., and F. Baker,
Wing & Natarajan Expires April 28, 2011 [Page 7]
Internet-Draft Happy Eyeballs SCTP October 2010
"Using SCTP as a Transport Layer Protocol for HTTP",
draft-natarajan-http-over-sctp-02 (work in progress),
July 2009.
[Natarajan]
Natarajan, P., "Leveraging Innovative Transport Layer
Services for Improved Application Performance",
February 2009, <http://www.cis.udel.edu/~amer/PEL/poc/pdf/
NatarajanPhDdissertation.pdf>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[cx-osx] Adium, "AIHostReachabilityMonitor", June 2009,
<https://bugzilla.redhat.com/show_bug.cgi?id=505105>.
[cx-win] Microsoft, "NetworkChange.NetworkAvailabilityChanged
Event", June 2009, <http://msdn.microsoft.com/en-us/
library/
system.net.networkinformation.networkchange.networkavailab
ilitychanged.aspx>.
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Preethi Natarajan
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: prenatar@cisco.com
Wing & Natarajan Expires April 28, 2011 [Page 8]