[RFC] Happy Eyeballs Algorithm

Geof Houstons' blog about the Happy Eyeballs algorithms has a few godo
points about where they are good, bad or plain ugly. He proposes a
slightly non-standard algorithm which should operate better than all
attempts so far:

"

Rather than opening up a connection in the protocol that has the faster
DNS resolution, or a faster average RTT or even the first to return an
ACK packet, it would be better to try IPv6 first, and then open up an
IPv4 connection if the IPv6 connection has not completed within a
relatively short interval.

This looks a lot like the first version of the dual stack algorithm
described at the start of this article.

What's different?

The difference is the introduction of parallelism into the mix. When the
browser reverts to IPv4 and kicks off the IPv4 connection attempt, that
does not mean that it should immediately stop listening for a SYN/ACK
response from the earlier IPv6 connection attempt. Once the IPv4 SYN has
been sent, the browser should then be prepared to work with whichever
protocol first responds to the outstanding connection attempts. In other
words it still a transformation from a serial effort of "IPv6 first then
IPv4 second" to a parallel effort of trying both IPv4 and IPv6 in
parallel, and being ready to work with which responds first. But the key
aspect here is that while its a race to the first SYN+ACK, its now a
handicapped race, where IPv6 enjoys a slight lead at the outset of the
race. The lead need not be large - Chrome's 300ms delay interval would
be reasonable. Perhaps Safari's single RTT time is a little too
aggressive, but if this timer were to be backed off to a minimum of
300ms or twice the estimated RTT then again this would be a reasonable
balance between performance and easing the pressure on the IPv4 CGNs.
"

What I'm thinking when reading this is that we could implement something
like this easily using the FwdState destinations array and a timeout.
While it is true that our destinations array is N-protocol rather than
2-protocol, the same failover principles apply between any address
regardless of protocol family.
Right now we are still on the old serial sequence algorithm of 0-N timeouts

Say:
  * start opening destination[0], create a timeout event of N ms
  * when the timeout occurs if the connection has not completed, bump
the destination[0] entry off and try the next.
  * when a connection succeeds,
   - if serverConn is already set, push the new conn into idle pconn
immediately and stop.
   - otherwise; set serverConn and *if* it is the destination[0] shift
that list. continue with the request in any event.

Possibly some modifications for the retries handling.

Other ideas?

Amos
Received on Sat Jul 07 2012 - 09:26:40 MDT