Re: [v6ops] An Update to Happy Eyeballs

[Tommy Pauly <[e-mail]>]

Hi Philip,

As James mentioned, getaddrinfo isn't technically an IETF standardized API. There are many networking APIs that are based on asynchronously handling DNS responses. We can certainly soften some of the language to make it clear that if your system has no such option, you are not necessarily out of spec, but if such an option is available, we believe that it SHOULD indeed be used. This fits with the Happy Eyeballs paradigm: if I am waiting for one of the DNS responses to come back, I could have already made my connection in that time, getting the user the resource loaded more quickly.

To the point of how often this situation occurs, we have done a lot of measurements in our stack. The approach documented in this document is essentially the algorithm that we have implemented for Apple devices. We do observe that fairly often, when DNS results are not already cached, one result (AAAA) may be returned asynchronously, and the TCP connection can be fully established before the other result (A) is returned. Using this algorithm, even if it only helps in a small percentage of overall connections, is a big win.

For those who are interested, I'd like to also point to some work going on in TAPS that build upon Happy Eyeballs to do connection racing and use asynchronous APIs to get wins not just in IPv4-vs-IPv6, but between paths, interfaces, and other protocols (and hopefully make it easier to application developers to write their networking code in the process):
https://tools.ietf.org/html/draft-pauly-taps-guidelines-00
https://tools.ietf.org/html/draft-trammell-taps-post-sockets-00

Thanks,
Tommy

> On Mar 9, 2017, at 2:51 AM, Philip Homburg <[e-mail]> wrote:
> 
>> Tommy Pauly and myself have written up what we've learned
>> in the past few years maintaining and improving Apple's Happy Eyeballs stack,
>> and submitted it as draft-pauly-v6ops-happy-eyeballs-update.
> 
> The draft says: Intended status: Standards Track
> 
> With that in mind I would prefer splitting the DNS and the connection
> parts over two different drafts.
> 
> The reason is two fold:
> 1) The only API that we standardized (getaddrinfo) cannot support the required
>   behavior. So an application would have to choose between using a standard
>   API or implementing happy eyeballs.
> 2) In my experience, AAAA hardly ever times out. (I wanted to write 'fail',
>   but failure, as in not returning the correct AAAA can be close to 1%. But
>   as long as there is no delay, it doesn't matter for happy eyeballs).
> 
> I think setting up tcp connections in staggered fashion is highly useful. 
> Writing code that gets triggered by DNS responses coming is not supported by
> standard APIs and may make code needlessly complex. So we should not require
> such behavior.
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops