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

[Cameron Byrne]

On Jun 13, 2012 6:55 AM, "Phil Mayers" <p.mayers at imperial.ac.uk> wrote:
>
> 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.

CGN operator here.

CGN does not add any measurable latency.  Specifically in mobile, they are
almost always colocated with the other gateway equipment and therefore
there is no latency added for indirection and asic processing of the nat is
all very fast (you cannot measure it with a Macbook)

CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120613/a3187ae4/attachment.html