Happy Eyeballs

[Jana Iyengar]

Paper to appear in ANRW '16: Measuring the Effects of Happy Eyeballs. We should probably revisit our 300ms happy eyeballs timer at some point.

TL;DR

" We want to empirically

determine the right HE timer value that provides the same preference

levels over IPv6 as is today but also reduces the performance

penalty in situations where IPv6 is slower. [...] 

Our contributions − a) We show that TCP connect times to

popular websites over IPv6 (see § 3.1) have considerably improved

over time. As of May 2016, 18% of websites are faster over IPv6

with 91% of the rest being at most 1 ms slower, b) Only around 1%

of the TCP connect times over IPv6 were ever above the HE timer

value (300 ms), which leaves around 2% chance for IPv4 to win a

HE race towards these websites. As such, 99% of these websites

prefer IPv6 connections (see § 3.2) more than 98% of the time and

c) Although absolute TCP connect times (in ms) are not that far

apart in both address families, HE with 300 ms timer value tends

to prefer slower IPv6 connections (see § 3.3) in around 90% of the

cases. A lowering of the HE timer value to 150 ms (see § 3.4) gives

us a margin benefit of 10% while retaining same preference levels

over IPv6."

[Matt Menke]

We could also consider more drastic changes - racing IPv4 lookup + connect against IPv6 lookup + connection, for instance.  That conveniently also partially solves problems with our IPv6 probes incorrectly failing in some types of network configurations.  On the other hand, it could increase the time to failure for requests on systems with borked IPv6 connectivity (Borked meaning IPv6 DNS lookups take forever, or IPv6 connections take forever).  Also would mean potentially more DNS lookups in the IPv4 only case, with non-borked IPv6, where we're only doing IPv4 lookups today.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAGD1bZabALth-YyjnZsSzcO6U4LhzzBStudq7A%3Dp6Oc8ooNzbg%40mail.gmail.com.

[Randy Smith]

So AIUI the point of Happy Eyeballs (at least the 300ms delay for IPv4) is to try and incentivize web servers and the supporting ecosystem to support IPv6.  Do we have a sense of a) how effective that incentive has been, b) if it's likely to continue being effective given current trajectories, and c) what the effect on the incentive of reducing the HE timer value would be?

-- Randy

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvq9rBu-Xm-%2BHPNE7%2BKzM4VmXnrG7LrdYOUcSJrpBiC3gg%40mail.gmail.com.

[Chris Bentzel]

Chrome's initial version of this was here, which was done in advance of the first World IPv6 Day. The issue was that a dual-stack client would get AAAA records, but be unable to establish a TCP connection and would take minutes before falling back to IPv4.

So the 300ms solution does strike a balance between that worst case behavior and giving some preference to IPv6.  There have been discussions about whether that's the right amount, or whether there should be a 300ms delay at all and to just start a race. I think it's an interesting thing to revisit. We'd want to make sure a solution works on network types ranging from poor 2G connections to well-connected-and-located FTTH.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAFbEG_re0m35B%2BvW0_jDgL7P8iSz4rBAGz70ohN3O60b31F5OQ%40mail.gmail.com.