Evaluating the Effectiveness of Happy Eyeballs

Motivation

The function getaddrinfo(...) resolves a service name to a list of endpoints in an order that prioritises an IPv6-upgrade path [1] . 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 [2] . 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.

Metric

We have defined a metric that uses the TCP connection establishment times as a parameter to measure the algorithm’ effectiveness. The methodology also helps examine the impact of tunnelling 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.

Implementation

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.

Measurements Trials

We use the Alexa top 1M list 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 flavours of connectivity ranging from native IPv4, native IPv6, IPv6 tunnel broker endpoints, Teredo and tunnelled IPv4.

Data Analysis Insight

The initial results show higher connection times and variations over IPv6 as shown in Figure 1 below (you can click on the image to enlarge it). 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.

Fig 1. Mean time and its standard deviations to establish TCP connections to a list of web services. The measurement agent is a server located at the University of Braunschweig. It has native IPv4 and IPv6 connectivity via the German Research Network [AS13237]

Conclusion

We have performed a preliminary study on evaluating 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 want to run this test on a large-scale measurement platform to develop a more comprehensive picture to help improve the algorithm.

Further Links

This work was presented within the IPv6 working group at the RIPE 66 meeting. The presentation video and slides are available at:  https://ripe66.ripe.net/archives/video/1208 .

The original manuscript in the PDF form is available at: http://vaibhavbajpai.com/documents/papers/manuscripts/happy-ripe66.pdf

References

[1] D. Thaler, R. Draves, A. Matsumoto, and T. Chown, “Default Address Selection for Internet Protocol Version 6 (IPv6),” RFC 6724 (Proposed Standard), Internet Engineering Task Force, Sep. 2012. [Online]. Available: http://www.ietf.org/rfc/rfc6724.txt

[2] D. Wing and A. Yourtchenko, “Happy Eyeballs: Success with Dual- Stack Hosts,” RFC 6555 (Proposed Standard), Internet Engineering Task Force, Apr. 2012. [Online]. Available: http://www.ietf.org/rfc/rfc6555.txt