Skip to main content

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

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 , Zdravko Bozakov
Last updated 2017-03-13
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-02
TAPS                                                       K-J. Grinnemo
Internet-Draft                                              A. Brunstrom
Intended status: Informational                                 P. Hurtig
Expires: September 14, 2017                          Karlstad University
                                                              N. Khademi
                                                      University of Oslo
                                                              Z. Bozakov
                                                Dell EMC Research Europe
                                                          March 13, 2017

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

Abstract

   Ideally, network applications should be able to select an appropriate
   transport solution from among available transport solutions.
   However, at present, there is no agreed-upon way to do this.  In
   fact, there is not even an agreed-upon way for a source end host to
   determine if there is support for a particular transport along a
   network path.  This draft addresses these issues, by proposing a
   Happy Eyeballs framework.  The proposed Happy Eyeballs framework
   enables the selection of a transport solution that according to
   application requirements, pre-set policies, and estimated network
   conditions is the most appropriate one.  Additionally, the proposed
   framework makes it possible for an application to find out whether a
   particular transport is supported along a network connection towards
   a specific destination or not.

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 September 14, 2017.

Grinnemo, et al.       Expires September 14, 2017               [Page 1]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

Copyright Notice

   Copyright (c) 2017 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  . . . . . . . . . . . . . . . .   3
   5.  Design and Implementation Considerations  . . . . . . . . . .   5
     5.1.  Candidate List Generation . . . . . . . . . . . . . . . .   5
     5.2.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Concurrent Connection Attempts  . . . . . . . . . . . . .   7
   6.  Example Happy Eyeballs Scenario . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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

   Information services on the Internet come in varying forms, such as
   web browsing, email, and on-demand multimedia.  The main motivation
   behind the design of next-generation computer and communications
   networks is to provide a universal and easy access to these various
   types of information services on a single multi-service Internet.
   This means that all forms of communications, e.g., video, voice, data

Grinnemo, et al.       Expires September 14, 2017               [Page 2]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

   and control signaling, along with all types of services -- from plain
   text web pages to multimedia applications -- are bonded in a single-
   service platform through Internet technology.  To enable the next-
   generation networks, the TAPS Working Group suggests a decoupling
   between the transport service provided to an application, and the
   transport stack providing this transport service: An application
   requests an appropriate transport service on the basis of its
   transport requirements, and the available transport stack that best
   meets these requirements is selected.  In case the most preferred
   transport stack is not supported along the network path to the
   destination, or is not supported by the end host, a less-preferred
   transport stack is selected instead.  As a way to realize the
   selection of transport stacks, this document suggests a
   generalization of the transport Happy Eyeballs (HE) mechanism
   proposed in Wing et al.  [RFC6555] which addresses the selection of
   complete transport solutions, and which lends itself to arbitrary
   transport selection criterias.

   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-tsvwg-happy-eyeballs-sctp].  The HE
   framework suggested in this document could be seen as a natural
   continuation of this proposal.

3.  Problem Statement

   Currently, there is no agreed-upon way for a source end host to
   select an appropriate transport service for a given application.  In
   fact, there is no common way for a source end-host to find out if a
   transport stack 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 stacks, and several
   applications, including many web applications, run over TCP although
   there are other transport protocols that better meet the requirements
   of these applications.

4.  The Happy Eyeballs Framework

Grinnemo, et al.       Expires September 14, 2017               [Page 3]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

                  +---------------+
                  |               |
                  |  Application  |
                  |               |
                  +-------+-------+
                          |
                  +-------v-------+     +---------------+
                  |               |     |               |
                  |   TAPS API    +----->               |
                  |               |     |               |
                  +---------------+     |    Policy     |
                                     +--|  Management   |
                  +---------------+  |  |               |
                  |   Transport   |<-+  |               |
                  |    Probing    |     |               |
                  |               +----->               |
                  +---------------+     +---------------+

                  Figure 1: The Happy Eyeballs Framework.

   The generalized HE mechanism proposed in this draft is carried out
   within the framework depicted in Figure 1.  It comprises the
   following steps:

   1.  The Policy Management component takes as input application
       requirements from the TAPS API, stored information about previous
       connection attempts (e.g., whether previous connection attempts
       succeeded or not), and network conditions and configurations.  On
       the basis of this input, the Policy Management component creates
       a list of candidate transport solutions, L, sorted in decreasing
       priority order.  To be compliant with RFC 6555 [RFC6555], the
       Policy Management component SHOULD, in those cases there are no
       policies telling otherwise, give priority to IPv6 over IPv4.
   2.  It is the responsibility of the Transport Probing component to
       select the most appropriate transport solution.  This is done by
       initiating connection attempts for each transport solution on L.
       To minimize the number of connection attempts that are initiated,
       the Transport Probing component SHOULD cache the outcome of
       connection attempts in a repository kept by the Policy Management
       component.  The Policy Management component SHOULD in turn only
       include those transport solutions on L that have not been
       previously attempted, have valid successful connection-attempt
       cache entries, or have previously been attempted but whose cached
       connection-attempt entries have expired.  Cached connection-
       attempt results SHOULD be valid for a configurable amount of time
       after which they SHOULD expire and have to be repeated.  The
       transport solutions on L are initiated in priority order.  The

Grinnemo, et al.       Expires September 14, 2017               [Page 4]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

       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 initiation of the connection
       attempts C1 and C2.
   3.  After the initiation of the connection attempts, the Transport
       Probing component waits for the first or winning connection to be
       established, which becomes the selected transport solution.  For
       the Transport Probing component to be able to efficiently use the
       connection-attempt cache, already-initiated, non-winning
       transport solutions SHOULD NOT be terminated as soon as a winning
       connection has been established.  Instead, they SHOULD themselves
       be given a fair chance to establish connections.  In that way,
       the connection-attempt cache will be provided with a fairly
       accurate knowledge of which transport solutions work and does not
       work against frequently visited transport endpoints.  Moreover,
       it MAY be beneficial to let those transport solutions which have
       a higher priority than the winning transport solution, live a
       predetermined amount of time after their establishment, since
       this enables the reuse of already established connections in
       later application requests.

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.  Candidate List Generation

Grinnemo, et al.       Expires September 14, 2017               [Page 5]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

                 +---------------+
                 |               |
                 |  Application  |
                 |               |
                 +-------+-------+
                         |
                 +-------v-------+     +---------------+
                 |               |     |               |
                 |   TAPS API    +--+--|Policy Manager |<-+
                 |               |  |  |               |  |
                 +---------------+  |  +-------^-------+  |
                                    |          |          |
                 +---------------+  |  +-------+-------+  |
                 |   Transport   |<-+  |    Policy     |  |
                 |    Probing    |     |  Information  |  |
                 |               +--+  |     Base      |  |
                 +---------------+  |  +---------------+  |
                                    |                     |
                                    |  +---------------+  |
                                    |  |Characteristics|  |
                                    +-->  Information  |--+
                                       |     Base      |
                                       +---------------+

               Figure 2: The NEAT Happy Eyeballs Framework.

   There are several ways in which the list of candidate transport
   solutions, L, could be created by the Policy Management component.
   For example, L could be a list of all available transport solutions
   in an order that except for giving priority to IPv6 is arbitrary.

   The NEAT System is developed as part of the EU Horizon 2020 project,
   "A New, Evolutive API and Transport-Layer Architecture for the
   Internet" (NEAT) [NEAT-Webb], and aims to provide a flexible and
   evolvable transport system that aligns with the charter of the TAPS
   Working Group.  In the NEAT System [NEAT-Git], the HE framework is
   realized as shown in Figure 2.  As follows, the Policy Management
   component comprises three components in the NEAT HE framework: a
   Policy Manager (PM), a Policy Information Base (PIB), and a
   Characteristics Information Base (CIB).  PIB is a repository that
   stores a collection of policies that map application requests to
   transport solutions, i.e., map application requests to appropriately
   configured transport protocols, and CIB is a repository that stores
   information about previous connection attempts, available network
   interfaces, supported transport protocols etc.  The PM takes as input
   application requirements from the TAPS API, and information from PIB
   and CIB.  On the basis of this input, the PM creates L.

Grinnemo, et al.       Expires September 14, 2017               [Page 6]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

5.2.  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 to the same peer.  The impact and
   efficiency of the HE algorithm has been evaluated in
   [Papastergiou16].  The paper suggests that caching significantly
   reduces the CPU load imposed by a HE mechanism.

5.3.  Concurrent Connection Attempts

   As mentioned in Section 4, it is the responsibility of the Transport
   Probing component to choose the most appropriate transport solution
   on the list of candidate transport solutions, L.  Often this implies
   that several transport solutions need to be tried out, something
   which should not be carried out sequentially, but concurrently or
   partly overlapping depending on the transport-solution priorities.
   The way this is done is implementation dependent and varies between
   platforms.  The NEAT library [NEAT-Git], which implements the HE
   framework herein, is built around the libuv asynchronous I/O library
   [LIBUV] and uses an event-based concurrency model to realize the
   concurrent initialization of connection attempts.  The rationale
   behind using an event-based concurrency model is at least twofold:
   The first is that correctly managing concurrency in multi-threaded
   applications can be challenging with, for example, missing locks or
   deadlocks.  The second is that multi-threading typically offers
   little or no control over what is scheduled at a given momemt in
   time.  Given the complexity of building a general-purpose scheduler
   that works well in all cases, sometimes the OS will schedule work in
   a manner that is less than optimal.  Proponents of threads argue that
   threads are a natural extension of sequential programming in that it
   maps work to be executed with individual threads.  Threads are also a
   well-known and understood parts of OSes, and are mandatory for
   exploiting true CPU concurrency.

6.  Example Happy Eyeballs Scenario

   Consider a scenario in which an IPv4-only client using the NEAT
   System wishes to setup a connection to a server.  Assume both the
   client and server support SCTP and TCP.  The PM is queried about
   feasible transport solutions to connect to the server.  This results
   in the PM retrieving information about network connections against
   this server from the CIB, e.g., supported transport protocols and the
   outcome of previous connection attempts.  In our scenario, the PM
   learns from the CIB that the server supports SCTP and TCP, and, for
   the sake of this example, let us assume that the PM is also informed
   that previous connection attempts against this server, using both

Grinnemo, et al.       Expires September 14, 2017               [Page 7]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

   SCTP and TCP, were successful.  Next, the PM retrieves applicable
   policies from the PIB, and combines these policies with the
   previously retrieved CIB information.  We assume in this example that
   the SCTP transport solution has a higher priority than the TCP
   solution.  As a next step, the PM puts together the feasible
   candidate transport solutions in a list with SCTP over IPv4 placed at
   the head of the list followed by TCP over IPv4, and supplies this
   list to the Transport Probing component.  The Transport Probing
   component traverses the candidate list, and initiates a connection
   attempt with SCTP against the server followed after a short while
   (governed by the difference in priorities between the SCTP and TCP
   transport solutions) by a connection attempt with TCP against the
   server.  In our example, assume both connection attempts are
   successful, however, the SCTP connection attempt completes before the
   TCP attempt.  The Transport Probing component caches in the CIB the
   SCTP connection attempt as successful, and returns the SCTP
   connection as the winning connection.  When the TCP connection is
   established some time later, the Transport Probing component caches
   that connection attempt as successful as well.

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

Grinnemo, et al.       Expires September 14, 2017               [Page 8]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

10.2.  Informative References

   [I-D.wing-tsvwg-happy-eyeballs-sctp]
              Wing, D. and P. Natarajan, "Happy Eyeballs: Trending
              Towards Success with SCTP", draft-wing-tsvwg-happy-
              eyeballs-sctp-02 (work in progress), October 2010.

   [LIBUV]    libuv -- Asynchronous I/O Made Simple, "http://libuv.org",
              March 2017.

   [NEAT-Git]
              A New, Evolutive API and Transport-Layer Architecture for
              the Internet (NEAT), "https://github.com/NEAT-project/
              neat", March 2017.

   [NEAT-Webb]
              NEAT -- A New, Evolutive API and Transport-Layer
              Architecture for the Internet, "https://www.neat-
              project.org", March 2017.

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

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

Grinnemo, et al.       Expires September 14, 2017               [Page 9]
Internet-Draft   Happy Eyeballs for Transport Selection       March 2017

   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

   Email: naeemk@ifi.uio.no

   Zdravko Bozakov
   Dell EMC Research Europe
   Ovens, Co.
   Cork
   Ireland

   Phone: +353 21 4945733
   Email: Zdravko.Bozakov@dell.com

Grinnemo, et al.       Expires September 14, 2017              [Page 10]