Last Comment Bug 621558 - Implement "happy eyeballs" IPv6 autodetection at TCP open, or similar
: Implement "happy eyeballs" IPv6 autodetection at TCP open, or similar
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: unspecified
: All All
: -- enhancement with 3 votes (vote)
: ---
Assigned To: Christian :Biesinger (don't email me, ping me on IRC)
:
:
Mentors:
: 199333 213121 657426 662544 (view as bug list)
Depends on:
Blocks: IPv6 662740 679090 680466 684893
  Show dependency treegraph
 
Reported: 2010-12-27 11:07 PST by Neil Harris
Modified: 2012-04-25 06:52 PDT (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (10.35 KB, patch)
2011-07-01 07:44 PDT, Christian :Biesinger (don't email me, ping me on IRC)
mcmanus: review+
Details | Diff | Splinter Review

Description Neil Harris 2010-12-27 11:07:10 PST
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 1 Jason Duell [:jduell] (needinfo me) 2011-05-16 23:51:11 PDT
*** Bug 657426 has been marked as a duplicate of this bug. ***
Comment 2 Jason Duell [:jduell] (needinfo me) 2011-05-16 23:52:18 PDT
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.
Comment 3 Neil Harris 2011-06-07 07:32:52 PDT
See

http://code.google.com/p/chromium/issues/detail?id=81686

for discussion of the current state of this functionality in Google Chrome.
Comment 4 Jason Fesler 2011-06-22 09:04:51 PDT
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).
Comment 5 Christian :Biesinger (don't email me, ping me on IRC) 2011-07-01 07:44:07 PDT
Created attachment 543434 [details] [diff] [review]
patch
Comment 6 Wan-Teh Chang 2011-07-01 09:05:07 PDT
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 Masatoshi Kimura [:emk] 2011-07-01 13:12:11 PDT
With this patch, is backup connection disabled for IPv6 only hosts?
Comment 8 Patrick McManus [:mcmanus] 2011-07-03 06:28:24 PDT
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.
Comment 9 Christian :Biesinger (don't email me, ping me on IRC) 2011-07-04 02:52:43 PDT
(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
Comment 10 Christian :Biesinger (don't email me, ping me on IRC) 2011-07-04 06:58:43 PDT
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
Comment 11 Matthias Versen [:Matti] 2011-07-04 15:40:33 PDT
*** Bug 199333 has been marked as a duplicate of this bug. ***
Comment 12 Matthias Versen [:Matti] 2011-07-04 15:41:27 PDT
*** Bug 662544 has been marked as a duplicate of this bug. ***
Comment 13 Christopher Blizzard (:blizzard) 2011-08-09 09:26:13 PDT
This was added for Firefox 7.
Comment 14 Eric Shepherd [:sheppy] 2011-08-09 11:34:00 PDT
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.
Comment 15 mohacsi 2011-08-15 01:49:17 PDT
This implementation not exaclty "happy-eyeball". I would call it quick fall-back to IPv4. Can make enable/disable user configurable?
Comment 16 Eduardo Trápani 2011-08-16 08:29:53 PDT
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 Lorenzo Colitti 2011-09-07 23:44:08 PDT
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)
Comment 18 Lorenzo Colitti 2011-09-07 23:52:23 PDT
Looks like fast-fallback was disabled due to bug 679090. Leaving this bug as reopened until it's re-enabled.
Comment 19 Matthias Versen [:Matti] 2011-09-08 05:12:21 PDT
we have bug 684893 for getting it re-enabled
Comment 20 Patrick McManus [:mcmanus] 2011-09-08 05:32:41 PDT
We don't need 2 bugs. Use 684893 for new work.
Comment 21 Matthias Versen [:Matti] 2012-04-25 06:52:38 PDT
*** Bug 213121 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.