happy CGN -- beating happy eyeballs and trending toward E2E success

[Phil Mayers]

On 13/06/12 09:38, Nick Hilliard wrote:
> On 12/06/2012 23:50, Daniel Roesen wrote:
>> On Tue, Jun 12, 2012 at 05:21:05PM -0400, Erik Nygren wrote:
>>> A "good" Happy Eyeballs implementation should compare IPv4 vs IPv6
>>> TCP (HTTP) performance and availability with some preference towards
>>> IPv6 (whether it is 30ms or 300ms).
>>
>> Unfortunately, Apple thinks different:
>>
>> http://www.ietf.org/mail-archive/web/v6ops/current/msg10080.html
>
> not an unreasonable position.

It's certainly an argument with a lot going for it, and some interesting 
implications for IPv6 adoption.

I knocked up a quick C program to connect to all the IPs behind a name 
(v4 & v6), send an HTTP request, read the response, and report the TCP 
RTT time using the linux TCP_INFO socket options.

 From my location (a UK university with excellent connectivity, no NAT) 
to www.google.com, I see ~9.8msec RTT over IPv4, and ~11.8msec RTT over 
IPv6:

$ ./httptime www.google.com 80 | fgrep rtt
closing 173.194.67.103 6 tx/rx=72/988 rtt/variance 10000/5250
closing 173.194.67.104 7 tx/rx=72/988 rtt/variance 9875/5250
closing 173.194.67.106 9 tx/rx=72/988 rtt/variance 9875/6000
closing 173.194.67.99 5 tx/rx=72/988 rtt/variance 9875/6000
closing 173.194.67.105 8 tx/rx=72/988 rtt/variance 9875/5250
closing 173.194.67.147 4 tx/rx=72/988 rtt/variance 9875/6000
closing 2a00:1450:4007:803::1010 3 tx/rx=72/988 rtt/variance 11000/4250

It's worth noting that, in this case, these numbers correspond very 
closely indeed to ping and simple 3-way handshake timings, although in 
the general case I would expect those to be slightly slower over IPv6 as 
the header size dominates?

I wonder where this differential is coming in? Anyone have any ideas? It 
doesn't seem likely that the extra 20 bytes header is the cause; maybe 
lower IPv6 per-packet performance on current routers?

I also wonder if basic consumer-grade NAT, or CGN, will impose enough 
overhead to reverse this. It might be the case that CGN end up being 
hardware-based, and impose so little overhead that IPv4 remains faster.