Measuring the Effectiveness of Happy Eyeballs

The function getaddrinfo(...) resolves a service name to a list of endpoints in an order that prioritizes an IPv6-upgrade path . The order can dramatically reduce the application's responsiveness when IPv6 connectivity is broken. The degraded user experience can be subverted by implementing the happy eyeballs algorithm . The algorithm recommends that a host, after resolving the service name, tries a TCP connect(...) to the first endpoint. However, instead of waiting for a timeout, it waits for 300ms, after which it must initiate another TCP connect(...) to an endpoint with a different address family and start a competition to pick the one that completes first. This document describes a metric used to measure the effectiveness of the happy eyeballs algorithm. The insights uncovered by analysing the data from multiple locations is discussed.

Fred Baker in describes metrics and testbed configurations to measure how quickly an application can reliably establish connections from a dual-stacked environment. The metrics measure whether the communication establishment time is same regardless of the address family and the routing viability available to a dual-stacked host. The metrics defined in is different in three ways: DNS is accounted in connection establishment time. Our metric does not take this into account. Accounting DNS resolution may invite multiple input factors (slow resolvers) that may bias our TCP connection establishment time results. In addition, according to , the 300ms advantage applies to the first address family after the getaddrinfo(...) call. From a programming perspective, an application calls getaddrinfo(...) and that does its job, regardless of which address family is used. The testbed configuration in is more passive than active. An external analyser is used to passively observe the client's traffic using tcpdump. There is no active measurement test, instead the routers along the path are configured to control what connectivity route is taken. We on the other hand, have an active measurement test running on the client. The test is agnostic to network path configuration since it independently tries a TCP connection to each connectivity route. It also actively measures the time taken instead of relying on an external analyser program. The testbed setup in is designed for a controlled environment. The router in the path is configured to disrupt all but one routes to control the prefix used in the connection. As such, the test is repeated N times with different router configurations to try all possible permutations of route connectivity. Our measurement test is agnostic to the network path and does not require path configuration changes.

We have defined a metric that uses the TCP connection establishment times as a parameter to measure the algorithm's effectiveness. The methodology also helps examine the impact of tunneling mechanisms employed by early adopters. The input parameter of the metric is a (IP address, port number) tuple and the output is the connection establishment time, typically measured in microseconds.

We have developed happy, a simple TCP happy eyeballs probing tool that conforms to the definition of our metric. It uses non-blocking connect(...) calls to concurrently establish connections to all endpoints of a service and measures the elapsed time. The tool enforces a small delay between concurrent connect(...) calls to avoid bursty TCP SYN traffic. The initially performed service name resolution is not accounted in the connection establishment elapsed time.

We use Alexa's top 1M service names as input to prepare a top 100 dual-stacked service names list. We run happy on our internal test-bed of multiple measurement agents with different flavors of connectivity ranging from native IPv4, native IPv6, IPv6 tunnel broker endpoints, Teredo and tunnelled IPv4. The list of Measurement Agents (MAs) is shown in . MA # IPv4 AS IPv6 AS City Country Platform 1 AS680 AS680 Bremen Germany Mac OS X 2 AS680 AS680 Braunschweig Germany GNU/Linux 3 AS13237 Teredo Berlin Germany GNU/Linux 4 AS31334 AS6939 Bremen Germany OpenWrt 5 AS680 AS680 Bremen Germany SamKnows 6 AS31334 AS6939 Bremen Germany SamKnows 7 AS24956 AS24956 Braunschweig Germany SamKnows 8 AS3320 AS3320 Bremen Germany SamKnows 9 AS5607 AS5607 London England SamKnows 10 AS3269 AS3269 Torino Italy SamKnows 11 AS8903 AS8903 Madrid Spain SamKnows 12 AS2614 AS2614 Timisoara Romania SamKnows 13 AS13030 AS13030 Olten Switzerland SamKnows 14 AS2856 AS2856 Ipswich England SamKnows

The initial results show higher connection times and variations over IPv6 as shown in .

1e+06 ++-----+-----+------+-----+------+------+-----+------+-----+ +mean (v4) ****** + + + + + + + +mean (v6) ###### : : : : : : : * + * * : : : : : : * * * * : * * : : : : : :** * * |* : * ##*# : : : : : :** * * 100000 +*.......*.#.**.......................................****** +* : *##*:* : : : : : #****** +* : **#*:* : : : : : * ***** +* :*****:*# : : : : : * **** +*# :**** : * : # : : : * ** * 10000 +*#*******.....**#*#*##**#####*##*####*#########*##*#*...*.. + ** *** : * ****** ********:*******************: * : + * :* : : : : : : *: * : + * :* : : : : : : *: * : + : : : : : : : : : + + + + + + + + + + 1000 ++-----+-----+------+-----+------+------+-----+------+-----+ 0 10 20 30 40 50 60 70 80 90 Service Names Fig. 1. shows the average TCP connection establishment times for both IPv4 and IPv6. The Measurement Agent (MA) is a SamKnows probe connected at Jacobs University Bremen. It receives IPv4 and IPv6 connectivity via German Research Network (DFN) [AS 680]. A PDF rendering of the plot is available at .

1e+06 ++-----+-----+------+-----+------+------+-----+------+-----+ +std (v4) ****** + + + + + + + +std (v6) ###### : : : : : : : + + + : : : : : : # : 100000 ++.......*...**..........................................#.* + : * ##** : : : : : : * # * * # : * # ** : # : : : :***# * #* # # : * **#*#* * #*# # # #: # : :***##* 10000 #*.#.*..**.**..**#..*.#**.#.#..##*...#..##......*...*.***..* # *#** *** * : **** * #**#### *#** #* ### :#* #*** # * * +#*#** **** : * ****#* #**###* *#* # * # # #** #* * # * * +##*#**#*** : * ****** #********#****************** *# **: |# :##* : : : * : : : #* *: 1000 ++......#...........................................#.....*. + : : : : : : : : : + : : : : : : : : : + + + + + + + + + + 100 ++-----+-----+------+-----+------+------+-----+------+-----+ 0 10 20 30 40 50 60 70 80 90 Service Names shows the standard deviation of the TCP connection establishment times for both IPv4 and IPv6. The Measurement Agent (MA) is a SamKnows probe connected at Jacobs University Bremen. It receives IPv4 and IPv6 connectivity via German Research Network (DFN) [AS 680]. A PDF rendering of the plot is available at . It appears that an application never uses IPv6 using Teredo except when IPv4 connectivity is broken. We noticed, that a 300ms advantage leaves a dual-stacked host only 1% chance to prefer a IPv4 route even though it may be significantly faster than IPv6. We also measured the margin by which happy eyeballs is inhibiting the fastest available route by comparing the slowness of a happy eyeballed winner to that of the loser.

We have performed a preliminary study on measuring the effectiveness of happy eyeballs. We noticed several cases where the algorithm does not select the best route and instead hampers the user experience. We are working towards running this test on a large-scale measurement platform to develop a more comprehensive picture to help improve the algorithm.