Re: [v6ops] An Update to Happy Eyeballs

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Stuart Cheshire wr
ites:
> 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.

Happy Eyeballs is working group consensus.  It's a product of the
working group.

> 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.

And that isn't a server failure?  https://www.kb.cert.org/vuls/id/714121
was issued in 2003 about this.  We have similar issues with TLSA
today.

> 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.

Actually most AAAA queries have always worked.  The ones that failed
were those directed at load balancers.

> 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.

Which is Happy Eyeballs.  Just because HE isn't what Apple experimented
with doesn't make my statement was wrong.  Apple has never implemented
HE.  It's implemented something that is HE like but not HE.  Apple
actually got complaints about that.

A bit like the load balancers implemented something that was like
a DNS server but wasn't actually a DNS server. They implements a A
record server and failed to handle all the other types as required
by RFC 1034.

> 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.

And we are pushing back because it goes too far.

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]