Implement "happy eyeballs" IPv6 autodetection at TCP open, or similar

RESOLVED FIXED

Status

()

Core
Networking: HTTP
--
enhancement
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: Neil Harris, Assigned: Biesinger)

Tracking

(Blocks: 1 bug, {dev-doc-complete})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
Duplicate of this bug: 657426
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: 136898

Updated

6 years ago
Assignee: nobody → honzab.moz
(Reporter)

Comment 3

6 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.
Blocks: 662740
Assignee: honzab.moz → cbiesinger

Comment 4

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).
Created attachment 543434 [details] [diff] [review]
patch
Attachment #543434 - Flags: review?
Attachment #543434 - Flags: review? → review?(mcmanus)

Comment 6

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.
Attachment #543434 - Flags: review?(mcmanus) → review+
(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
Last Resolved: 6 years ago
Resolution: --- → FIXED
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
Duplicate of this bug: 199333
Duplicate of this bug: 662544
Keywords: dev-doc-needed
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.
Keywords: dev-doc-needed → dev-doc-complete

Comment 15

6 years ago
This implementation not exaclty "happy-eyeball". I would call it quick fall-back to IPv4. Can make enable/disable user configurable?
Blocks: 679090

Comment 16

6 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?
Blocks: 680466

Comment 17

6 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

6 years ago
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
Blocks: 684893
We don't need 2 bugs. Use 684893 for new work.
No longer blocks: 684893
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Blocks: 684893
Duplicate of this bug: 213121
You need to log in before you can comment on or make changes to this bug.