Evaluating the Effectiveness of Happy Eyeballs

Vaibhav Bajpai — Jun 13, 2013 12:14 PM
Contributors: Prof. Dr. Jürgen Schönwälder
Filed under: , ,
The IETF has developed solutions that promote a healthy IPv4 and IPv6 co-existence. The happy eyeballs algorithm for instance, provides recommendations to application developers to help prevent bad user experience in situations where IPv6 connectivity is broken. We study the effectiveness of the happy eyeballs algorithm.


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.


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.


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.

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]

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]


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


[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


Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Related Items
NTP Measurements with RIPE Atlas

This article describes how RIPE Atlas probes and anchors maintain their clocks, and how accurate ...

Visualising Network Outages With RIPE Atlas

This article shows some prototypes of visualising network outages with RIPE Atlas using CartoDB.

Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Distribution of RIPE Atlas Probes

As the RIPE Atlas network continues to grow, it's useful for ambassadors and potential probes hosts ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

more ...