<p><br>
On Jun 13, 2012 6:55 AM, "Phil Mayers" <<a href="mailto:p.mayers@imperial.ac.uk">p.mayers@imperial.ac.uk</a>> wrote:<br>
><br>
> On 13/06/12 09:38, Nick Hilliard wrote:<br>
>><br>
>> On 12/06/2012 23:50, Daniel Roesen wrote:<br>
>>><br>
>>> On Tue, Jun 12, 2012 at 05:21:05PM -0400, Erik Nygren wrote:<br>
>>>><br>
>>>> A "good" Happy Eyeballs implementation should compare IPv4 vs IPv6<br>
>>>> TCP (HTTP) performance and availability with some preference towards<br>
>>>> IPv6 (whether it is 30ms or 300ms).<br>
>>><br>
>>><br>
>>> Unfortunately, Apple thinks different:<br>
>>><br>
>>> <a href="http://www.ietf.org/mail-archive/web/v6ops/current/msg10080.html">http://www.ietf.org/mail-archive/web/v6ops/current/msg10080.html</a><br>
>><br>
>><br>
>> not an unreasonable position.<br>
><br>
><br>
> It's certainly an argument with a lot going for it, and some interesting implications for IPv6 adoption.<br>
><br>
> 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.<br>
><br>
> From my location (a UK university with excellent connectivity, no NAT) to <a href="http://www.google.com">www.google.com</a>, I see ~9.8msec RTT over IPv4, and ~11.8msec RTT over IPv6:<br>
><br>
> $ ./httptime <a href="http://www.google.com">www.google.com</a> 80 | fgrep rtt<br>
> closing 173.194.67.103 6 tx/rx=72/988 rtt/variance 10000/5250<br>
> closing 173.194.67.104 7 tx/rx=72/988 rtt/variance 9875/5250<br>
> closing 173.194.67.106 9 tx/rx=72/988 rtt/variance 9875/6000<br>
> closing 173.194.67.99 5 tx/rx=72/988 rtt/variance 9875/6000<br>
> closing 173.194.67.105 8 tx/rx=72/988 rtt/variance 9875/5250<br>
> closing 173.194.67.147 4 tx/rx=72/988 rtt/variance 9875/6000<br>
> closing 2a00:1450:4007:803::1010 3 tx/rx=72/988 rtt/variance 11000/4250<br>
><br>
> 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?<br>

><br>
> 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?<br>
><br>
> 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.</p>
<p>CGN operator here.</p>
<p>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)<br>
</p>
<p>CB<br>
</p>