Happy Eyeballs for Transport Selection

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.

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 : 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 . This document suggests a further generalization of the transport HE mechanism proposed in Wing et al. 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 , 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.

| | TS2: SYN | +------------------------>| | TS3: SYN | +------------------------>| | | | | | TS1: SYN+ACK | |<------------------------| | TS2: SYN+ACK | | <---------------------+ | TS3: SYN+ACK | | <----------------+ | | | | ]]> 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. ): 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. 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.

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 , 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 . The paper suggests that caching significantly reduces the CPU load imposed by a HE mechanism.

As mentioned in Section , 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).