Closed
Bug 621558
Opened 14 years ago
Closed 13 years ago
Implement "happy eyeballs" IPv6 autodetection at TCP open, or similar
Categories
(Core :: Networking: HTTP, enhancement)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
People
(Reporter: usenet, Assigned: Biesinger)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
10.35 KB,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 2•13 years ago
|
||
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.
Blocks: IPv6
Reporter | ||
Comment 3•13 years ago
|
||
See http://code.google.com/p/chromium/issues/detail?id=81686 for discussion of the current state of this functionality in Google Chrome.
Assignee | ||
Updated•13 years ago
|
Assignee: honzab.moz → cbiesinger
Comment 4•13 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).
Assignee | ||
Comment 5•13 years ago
|
||
Attachment #543434 -
Flags: review?
Assignee | ||
Updated•13 years ago
|
Attachment #543434 -
Flags: review? → review?(mcmanus)
Comment 6•13 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.
Comment 7•13 years ago
|
||
With this patch, is backup connection disabled for IPv6 only hosts?
Comment 8•13 years ago
|
||
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.
Attachment #543434 -
Flags: review?(mcmanus) → review+
Assignee | ||
Comment 9•13 years ago
|
||
(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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•13 years ago
|
||
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
Updated•13 years ago
|
Keywords: dev-doc-needed
Comment 13•13 years ago
|
||
This was added for Firefox 7.
Comment 14•13 years ago
|
||
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.
Keywords: dev-doc-needed → dev-doc-complete
Comment 15•13 years ago
|
||
This implementation not exaclty "happy-eyeball". I would call it quick fall-back to IPv4. Can make enable/disable user configurable?
Comment 16•13 years ago
|
||
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?
Comment 17•13 years ago
|
||
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)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 18•13 years ago
|
||
Looks like fast-fallback was disabled due to bug 679090. Leaving this bug as reopened until it's re-enabled.
Comment 19•13 years ago
|
||
we have bug 684893 for getting it re-enabled
Comment 20•13 years ago
|
||
We don't need 2 bugs. Use 684893 for new work.
No longer blocks: 684893
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•