At the moment, many dual-stack environments are wholly or partially broken, presenting problems for seamless IPv6 deployment. Long timeouts are bad for users, making the system appear to be broken. http://tools.ietf.org/html/draft-wing-http-new-tech-00 "Happy Eyeballs: Successful Introduction of New Technology to HTTP" suggests the use of overlapped attempts to resolve names for and to open IPv4 and IPv6 sockets to HTTP-like network endpoints as a way to autodetect IPv6 operation in a dual-stack environment, without significantly degrading performance if that environment is broken. Support for this, or something similar, in the core networking code would greatly ease the development of practical IPv6 interoperability in Mozilla products. The Internet-Draft describes a number of heuristics that may be possible to improve upon over time -- if this code were to be implemented centrally, this would also provide a good place to implement these new heuristics.
The canary build of Google Chrome implements a variant of parallel connect that reduces latency of broken IPv6 connections from 20 / 75 seconds to 300 milliseconds. In many cases (e.g., for hostnames you've already been before), it preconnects anyway, so by the time you've hit enter, there is no latency hit at all.
See http://code.google.com/p/chromium/issues/detail?id=81686 for discussion of the current state of this functionality in Google Chrome.
6 years ago
Chrome's implementation works quite nicely. Given a "broken user" configuration with respect to IPv6, the failover is almost not noticeable; yet there is still a good 300ms bias towards preferring IPv6 (versus the future of IPv4 and NAT).
6 years ago
Comment on attachment 543434 [details] [diff] [review] patch >@@ -1315,16 +1316,19 @@ nsHalfOpenSocket::SetupStreams(nsISocket > > PRUint32 tmpFlags = 0; > if (mTransaction->Caps() & NS_HTTP_REFRESH_DNS) > tmpFlags = nsISocketTransport::BYPASS_CACHE; > > if (mTransaction->Caps() & NS_HTTP_LOAD_ANONYMOUS) > tmpFlags |= nsISocketTransport::ANONYMOUS_CONNECT; > >+ if (isBackup) >+ tmpFlags |= nsISocketTransport::DISABLE_IPV6; Please add a comment. The purpose of disabling IPv6 on the backup connection is not obvious at all.
With this patch, is backup connection disabled for IPv6 only hosts?
Comment on attachment 543434 [details] [diff] [review] patch Review of attachment 543434 [details] [diff] [review]: ----------------------------------------------------------------- I think a comment in ::SetupStreams pointing to happy eyeballs, and we're all set. This is great. This kind of code also makes me very glad we're on rapid releases.
(In reply to comment #7) > With this patch, is backup connection disabled for IPv6 only hosts? Yes. I see no good way around that; fortunately, IPv6-only hosts are rare on the current internet. Comment added and pushed: http://hg.mozilla.org/mozilla-central/rev/06815ff84678
After being asked about this in private mail and thinking about it some more, I came to the conclusion that fixing the IPv6-only issue is actually not too hard. Filed bug 669159
This was added for Firefox 7.
Documentation updated: https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISocketTransport#Connection_flags https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIDNSService Also, a brief note about "happy eyeballs" is added at the top of the nsIDNSService page. Mentioned on Firefox 7 for developers as well.
This implementation not exaclty "happy-eyeball". I would call it quick fall-back to IPv4. Can make enable/disable user configurable?
I would like to reopen this bug. Please see Bug 679090 (I've provided logs). I *think* the problem is that after 250ms this code assumes that IPv6 is broken, when it's not. As a result, before I can navigate any ipv6-only site I have to reload many times, until my DNS server resolves all queries from its cache and Firefox (based on the response time) decides that the IPv6 stack is sane. From where I am, resolving ipv6.google.com the first time took 561 msec. Sometimes it takes longer. For IPv4 times are more or less the same. I think this type of "happy eyeball" based on fixed times just doesn't work. By the way, on the same machine, under the same conditions and delays chromium does show ipv6.google.com. Could we reverse this patch (it can still be easily done on trunk) until we can better assess the impact?
This doesn't seem to work. I tried both Firefox 7.0b4 (20110902161802) and Aurora 8.0a2 (20110907042004). To reproduce, set up a broken IPv6 connection with the following commands: sudo ip tunnel add sit1 mode sit local any remote 192.0.2.1 sudo ip addr add 2001:db8::1 dev sit1 sudo ip link set sit1 up sudo ip -6 route add default dev sit1 metric 1 Then launch Firefox and try to go to www.ripe.net, www.arin.net or www.ietf.org. Expected: page loads quickly after 300ms. Actual: page hangs for many seconds before loading. (To clean up: sudo ip tunnel del sit1)
Looks like fast-fallback was disabled due to bug 679090. Leaving this bug as reopened until it's re-enabled.
we have bug 684893 for getting it re-enabled
We don't need 2 bugs. Use 684893 for new work.