Skip to main content

Happy Eyeballs for Transport Selection
draft-grinnemo-taps-he-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Karl-Johan Grinnemo , Anna Brunstrom , Per Hurtig , Naeem Khademi
Last updated 2016-07-08
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-grinnemo-taps-he-00
TAPS                                                       K-J. Grinnemo
Internet-Draft                                              A. Brunstrom
Intended status: Informational                                 P. Hurtig
Expires: January 9, 2017                             Karlstad University
                                                              N. Khademi
                                                      University of Oslo
                                                            July 8, 2016

                 Happy Eyeballs for Transport Selection
                       draft-grinnemo-taps-he-00

Abstract

   It is widely recognized that it has become very difficult to
   introduce new transport protocols on the Internet.  On reason to this
   is that there are no agreed-upon way for a source end host to find
   out whether there is support for a particular transport protocol
   along the network path from itself to a destination end host or not.
   This document describes a Happy Eyeballs framework that generalizes
   previously proposed Happy Eyeballs mechanisms to include a transport
   protocol, the configuration of this transport protocol, as well as a
   transport address, i.e., to include complete transport solutions.
   The described Happy Eyeballs framework is not only useful in the
   design and implementation of mechanisms that are to determine the
   support of particular transport solutions, but also for the design of
   mechanisms that are to select the transport solution, which,
   according to some criteria, is the most appropriate one to use.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 9, 2017.

Grinnemo, et al.         Expires January 9, 2017                [Page 1]
Internet-Draft   Happy Eyeballs for Transport Selection        July 2016

Copyright Notice

   Copyright (c) 2016 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
   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.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Happy Eyeballs Framework  . . . . . . . . . . . . . . . .   4
   5.  Design and Implementation Considerations  . . . . . . . . . .   5
     5.1.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Non-Winning Transport Solutions . . . . . . . . . . . . .   5
   6.  Example Happy Eyeballs Mechanism  . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Definitions

   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 RFC 2119 [RFC2119].

2.  Introduction

   Concerns have been raised in the past several years that introducing
   new transport protocols on the Internet has become increasingly
   difficult, not least because there is no agreed-upon way for a source
   end host to find out if a transport protocol is supported all the way
   to a destination peer.  Of course, testing a set of candidate
   protocols can be done serially, e.g., try first with the preferred
   choice, X, and, if the connection attempt fails after a suitable

Grinnemo, et al.         Expires January 9, 2017                [Page 2]
Internet-Draft   Happy Eyeballs for Transport Selection        July 2016

   timeout, fall back to a default alternative, Y.  However, since a
   connection timeout can introduce a delay of up to tens of seconds,
   serializing attempts can incur a large delay penalty when the new
   protocol, X, is not supported, stalling the application until the
   subsequent connection attempt succeeds.  A solution to a similar
   problem, finding out support for IPv6, has been proposed and is
   currently being deployed, the Happy Eyeballs (HE) mechanism
   [RFC6555]: The HE mechanism was introduced as a means to facilitate
   IPv6 adoption.  Dual-stack client applications should be encouraged
   to try setting up connections over IPv6 first, and fall back to using
   IPv4 if IPv6 connection attempts fail.  However, serializing tests
   for IPv6 and IPv4 connectivity can result in large connection
   latencies.  HE for IPv6 minimizes the cost in delay by parallelizing
   attempts over IPv6 and IPv4.  HE has also been proposed as an
   efficient way to find out the optimal combination of IPv4/IPv6 and
   TCP/SCTP to use to connect to a server
   [I-D.wing-v6ops-happy-eyeballs-ipv6].  This document suggests a
   further generalization of the transport HE mechanism proposed in Wing
   et al.  [I-D.wing-v6ops-happy-eyeballs-ipv6] which addresses the
   selection of arbitrary transport solutions, i.e., arbitrary
   combinations of transport protocol, transport address, and pertaining
   configurations, and which lend itself to arbitrary transport
   selection criterias, not only support for a particular transport
   solution.  Particularly, this document provides a HE framework from
   which a transport selection mechanism could be realized that selects,
   from supported transport solutions, the one that according to some
   criteria is the most appropriate one.

3.  Problem Statement

   There is, as mentioned in Section 2, no agreed-upon way for a source
   end host to find out if a transport protocol is supported along a
   network path between itself and a destination end host.  As a
   consequence, it has become increasingly difficult to introduce new
   transport protocols.  This is further aggravated by the fact that
   several applications, including many web applications, run over TCP
   although there are other transport solutions that better meet the
   requirements of these applications.  Another, related problem,
   addressed by our proposed HE framework is how to select the transport
   solution that is, according to some critera, the most appropriate one
   for a given application.  In fact, our HE framework provides
   guidelines on how to design and implement a HE transport selection
   mechanism that combines these two problems by selecting, from among
   supported transport solutions, the one that best meets a given
   criteria.

Grinnemo, et al.         Expires January 9, 2017                [Page 3]
Internet-Draft   Happy Eyeballs for Transport Selection        July 2016

4.  The Happy Eyeballs Framework

                     client                    server
                       |     TS1: SYN            |
                       +------------------------>|
                       |     TS2: SYN            |
                       +------------------------>|
                       |     TS3: SYN            |
                       +------------------------>|
                       |                         |
                       |                         |
                       |     TS1: SYN+ACK        |
                       |<------------------------|
                       |     TS2: SYN+ACK        |
                       |   <---------------------+
                       |     TS3: SYN+ACK        |
                       |        <----------------+
                       |                         |
                       |                         |

       Figure 1: Illustration of Happy Eyeballing between three TCP
                           transport solutions.

   The HE framework takes as input a list of candidate transport
   solutions, L, sorted in decreasing priority order.  The exact scale
   used for the priority is beyond the scope of the framework, however,
   since the difference between priorities should be meaningful, it must
   at least be an interval scale.  The HE framework consists of the
   following two steps (cf.  Figure 1):

   1.  Spawn in priority order connection attempts for each candidate
       transport solution in L.  The difference in priority between two
       consecutive candidates, C1 and C2, is translated according to
       some criteria to a delay, D.  D then governs the delay between
       the spawn of C1 and C2.  The way connection attempts are spawned
       is not within the scope of the HE framework, and could, for
       example, be realized through threads or asynchronous I/O.
   2.  Wait for the first connection, W, to be established.  W becomes
       the winning transport solution.  The action taken with the
       remaining, non-winning, transport solutions is beyond the scope
       of the HE framework.

Grinnemo, et al.         Expires January 9, 2017                [Page 4]
Internet-Draft   Happy Eyeballs for Transport Selection        July 2016

5.  Design and Implementation Considerations

   This section discusses implementation issues that should be
   considered when a HE mechanism is designed and implemented on the
   basis of the HE framework proposed in this document.

5.1.  Caching

   As pointed out in RFC 6555 [RFC6555], a HE algorithm should not waste
   networking resources by routinely making simultaneous connection
   attempts.  To this end, the HE algorithm should cache the outcome of
   previous connection attempts.  Cached connection attempts should be
   valid for a configurable time after which they should become invalid
   and have to be repeated.  The impact and efficiency of the HE
   algorithm has been evaluated in a publication by us [Papastergiou16].
   The paper suggests that caching significantly reduces the CPU load
   imposed by a HE mechanism.

5.2.  Non-Winning Transport Solutions

   As mentioned in Section Section 4, the management of the non-winning
   transport solutions is not within the scope of the HE framework.
   Still, it is recommended that all non-winning transport solutions are
   abandoned.  Moreover, if caching is used, we recommend that the
   outcome of the connection attempt of the non-winning transport
   solution is cached.

6.  Example Happy Eyeballs Mechanism

   Consider the scenario of a dual-stack IPv4/IPv6 client trying to
   setup a connection to a dual-stack IPv4/IPv6 server.  Assume the
   client and server support both TCP and SCTP.  A list of candidate
   transport solutions is put together that contains TCP and SCTP over
   IPv6 (with equal priority) followed by TCP and SCTP over IPv4 (with
   equal priority), but the latter have a lower priority than their IPv6
   counterparts.  The HE mechanism is invoked; traverses the candidate
   list, and spawns a separate thread for each candidate transport
   solution.  In our example, two threads are created for TCP and SCTP
   over IPv4, and two threads for TCP and SCTP over IPv6.  Since the
   IPv4 transport solutions have a lower priority than the IPv4 ones,
   the creation of the threads for the IPv4 transport solutions are
   delayed with respect to the IPv6 transport solution threads.  The
   length of the delay depends on the size of the difference in
   priority.  Within each thread, a connection attempt is made, and if
   the connection attempt is successful, the thread returns a connection
   handle.  Otherwise, it signals a failure by returning an invalid
   connection handle.  In both cases the outcome (connection attempt
   success or failure) is cached.  Assume that in our example all

Grinnemo, et al.         Expires January 9, 2017                [Page 5]
Internet-Draft   Happy Eyeballs for Transport Selection        July 2016

   connection attempts succeed and therefore will be cached as
   successful connection attempts.  Since the IPv6 connection attempts
   were started earlier than IPv4 counterparts, one of these attempts
   will be selected as the winning transport solution.

7.  IANA Considerations

   XX RFC ED - PLEASE REMOVE THIS SECTION XXX

   This memo includes no request to IANA.

8.  Security Considerations

   Security will be considered in future versions of this document.

9.  Acknowledgements

   This work has received funding from the European Union's Horizon 2020
   research and innovation programme under grant agreement No. 644334
   (NEAT).  The views expressed are solely those of the author(s).

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <http://www.rfc-editor.org/info/rfc6555>.

10.2.  Informative References

   [I-D.wing-v6ops-happy-eyeballs-ipv6]
              Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
              Towards Success with Dual-Stack Hosts", draft-wing-v6ops-
              happy-eyeballs-ipv6-01 (work in progress), October 2010.

   [Papastergiou16]
              Papastergiou, G., Grinnemo, K-J., Brunstrom, A., Ros, D.,
              Tuexen, M., Khademi, N., and P. Hurtig, "On the Cost of
              Using Happy Eyeballs for Transport Protocol Selection",
              July 2016.

Grinnemo, et al.         Expires January 9, 2017                [Page 6]
Internet-Draft   Happy Eyeballs for Transport Selection        July 2016

Authors' Addresses

   Karl-Johan Grinnemo
   Karlstad University
   Universitetsgatan 2
   Karlstad  651 88
   Sweden

   Phone: +46 54 700 24 40
   Email: karl-johan.grinnemo@kau.se

   Anna Brunstrom
   Karlstad University
   Universitetsgatan 2
   Karlstad  651 88
   Sweden

   Phone: +46 54 700 17 95
   Email: anna.brunstrom@kau.se

   Per Hurtig
   Karlstad University
   Universitetsgatan 2
   Karlstad  651 88
   Sweden

   Phone: +46 54 700 23 35
   Email: per.hurtig@kau.se

   Naeem Khademi
   University of Oslo
   PO Box 1080 Blindern
   Oslo  N-0316
   Norway

   Phone: +47 2285 24 93
   Email: naeemk@ifi.uio.no

Grinnemo, et al.         Expires January 9, 2017                [Page 7]