Happy Eyeballs: Trending Towards Success with SCTP
draft-wing-tsvwg-happy-eyeballs-sctp-02

Versions: 00 01 02                                                      
TSVWG                                                            D. Wing
Internet-Draft                                              P. Natarajan
Intended status:  Standards Track                                  Cisco
Expires:  April 21, 2011                                October 18, 2010


        Happy Eyeballs: Trending Towards Success (IPv6 and SCTP)
                draft-wing-tsvwg-happy-eyeballs-sctp-00

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 21, 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 21, 2011                 [Page 1]


Internet-Draft  Happy Eyeballs: Trending Towards Success    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 . . . . . . . . . . . . . . . . . . . 5
     5.1.  Additional Network and Host Traffic . . . . . . . . . . . . 5
     5.2.  Abandon Non-Winning Connections . . . . . . . . . . . . . . 6
     5.3.  Flush or Expire Cache . . . . . . . . . . . . . . . . . . . 6
     5.4.  Multiple Interfaces . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informational References  . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7



























Wing & Natarajan         Expires April 21, 2011                 [Page 2]


Internet-Draft  Happy Eyeballs: Trending Towards Success    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 21, 2011                 [Page 3]


Internet-Draft  Happy Eyeballs: Trending Towards Success    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.

   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.








Wing & Natarajan         Expires April 21, 2011                 [Page 4]


Internet-Draft  Happy Eyeballs: Trending Towards Success    October 2010


     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
   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.







Wing & Natarajan         Expires April 21, 2011                 [Page 5]


Internet-Draft  Happy Eyeballs: Trending Towards Success    October 2010


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.

5.4.  Multiple Interfaces

   Interaction of the suggestions in this document with multiple
   interfaces is for further study.


6.  Security Considerations

   [[Placeholder.]]

   See Section 5.2.


7.  Acknowledgements

   The mechanism described in this paper was inspired by Stuart
   Cheshire's discussion at the IAB Plenary at IETF72, the author's
   understanding of Safari's operation with SRV records, Interactive
   Connectivity Establishment (ICE [RFC5245]), and the current IPv4/IPv6
   behavior of SMTP mail transfer agents.

   Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van
   Beijnum for fostering the creation of this document.

   Thanks to Scott Brim and Stig Venaas for providing feedback on the
   document.


8.  IANA Considerations

   This document has no IANA actions.





Wing & Natarajan         Expires April 21, 2011                 [Page 6]


Internet-Draft  Happy Eyeballs: Trending Towards Success    October 2010


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,
              "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>.









Wing & Natarajan         Expires April 21, 2011                 [Page 7]


Internet-Draft  Happy Eyeballs: Trending Towards Success    October 2010


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 21, 2011                 [Page 8]