| 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
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.
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.
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.
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].
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 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.
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.
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):
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.
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.
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.
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 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.
XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA.
Security will be considered in future versions of this document.
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).
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6555] | Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012. |
| [I-D.wing-v6ops-happy-eyeballs-ipv6] | Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Internet-Draft draft-wing-v6ops-happy-eyeballs-ipv6-01, 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. |