Re: [v6ops] An Update to Happy Eyeballs

[Stuart Cheshire <[e-mail]>]

On 14 Mar 2017, at 20:46, Mark Andrews <[e-mail]> wrote:

> So you now want Happy Eyeballs, which was designed to remove delays
> of 10's - 100's of seconds before failover, to now override address
> selection policies because the DNS's cache has one address type
> present and not the other.  That is what the 50ms timer achieves.
> It takes ~200ms to get a answer from the other side of the world
> with terrestial links.
> 
> Happy Eyeballs was never about having the absolute fastest time to
> connect.  It was about establishing a connection in a reasonable
> amount of time in presence of network / server failures without
> having ridiciously long failover delays.

What an utterly absurd statement, to claim to speak for the authors “Happy Eyeballs”, and tell us what our invention was or was not designed to do.

Back in 2007 and 2008 at Apple we started to get real-world bug reports about web sites being unusable. These were major web sites, whose DNS servers simply failed to answer AAAA queries, causing unusably long timeouts before getaddrinfo() completed. I won’t name names, because incredibly, some of these major web sites still have broken DNS servers. Some fixed their DNS servers, only then later to break them again.

Without some workaround in place, any ISP attempting to turn on IPv6 support would have caused client devices to start doing AAAA queries, which time out, which make web sites unusable, which results in complaints from customers, which results in the ISP turning off IPv6 support. So it was vital that we work out how to allow an ISP to enable IPv6 without enraging their customers.

In July 2008 I gave a presentation at the Technical Plenary at IETF 72 in Dublin about how Apple fixed this problem, recommending that others do the same. If you haven’t watched the presentation, please do, before telling us what our invention was designed to do. It’s not very long.

<http://www.stuartcheshire.org/IETF72/>

Dan Wing and Andrew Yiurtchenko decided to write up a subset of my recommendations as RFC 6555. Inexplicably they decided to document the asynchronous TCP connection racing, but not the asynchronous DNS query racing, which is odd, given that, at the time, DNS failure to answer AAAA queries was the dominant problem.

Still, Dan Wing and Andrew Yiurtchenko wrote a good, if incomplete, RFC.

Now, nine years later, Tommy Pauly and David Schinazi thought it was about time we shared the remainder of the relevant information with the community.

Like it or not, this is in fact what Apple networking products do, and have done for many years, and, regardless of what you think, it does provide a better user experience than a synchronous blocking call to getaddrinfo().

Stuart Cheshire