Tunnel overhead [On killing IPv6 transition mechanisms]

[Eric Vyncke (evyncke)]

Brian

Ping ietf with Ttl=66 waouw, I have never seen this value! I wonder which was the hop limit value at ietf web site :-)






Sent on my mobile with a micro keyboard. Please accept my apologies for typos...

 -----Original Message-----
From: 	Brian E Carpenter [mailto:brian.e.carpenter at gmail.com]
Sent:	Wednesday, March 17, 2010 01:41 AM W. Europe Standard Time
To:	Gert Doering
Cc:	ipv6-ops at lists.cluenet.de
Subject:	Tunnel overhead [On killing IPv6 transition mechanisms]

Gert,

The problem is tunnels. The first example is from University of Auckland
via Telstraclear and a HE tunnel. IPv6 penalty is about 390 ms round trip,
crossing one ocean. The second is native all the way. *IPv4* penalty is 5 ms
round trip, crossing two oceans.

The problem is not 6to4 specifically, but I don't have the ability
to compare 6to4 overhead with HE overhead.

>ping www.ietf.org

Pinging www.ietf.org [2001:1890:1112:1::20] with 32 bytes of data:

Reply from 2001:1890:1112:1::20: time=667ms
Reply from 2001:1890:1112:1::20: time=544ms
Reply from 2001:1890:1112:1::20: time=575ms
Reply from 2001:1890:1112:1::20: time=344ms

Ping statistics for 2001:1890:1112:1::20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 344ms, Maximum = 667ms, Average = 532ms

>ping -4 www.ietf.org

Pinging www.ietf.org [64.170.98.32] with 32 bytes of data:

Reply from 64.170.98.32: bytes=32 time=141ms TTL=66
Reply from 64.170.98.32: bytes=32 time=150ms TTL=66
Reply from 64.170.98.32: bytes=32 time=142ms TTL=66
Reply from 64.170.98.32: bytes=32 time=142ms TTL=66

Ping statistics for 64.170.98.32:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 141ms, Maximum = 150ms, Average = 143ms

----------------------------------------------------------
>ping www.surfnet.nl

Pinging www.surfnet.nl [2001:610:1:80d0:194:171:26:201] with 32 bytes of data:

Reply from 2001:610:1:80d0:194:171:26:201: time=311ms
Reply from 2001:610:1:80d0:194:171:26:201: time=310ms
Reply from 2001:610:1:80d0:194:171:26:201: time=311ms
Reply from 2001:610:1:80d0:194:171:26:201: time=310ms

Ping statistics for 2001:610:1:80d0:194:171:26:201:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 310ms, Maximum = 311ms, Average = 310ms

>ping -4 www.surfnet.nl

Pinging www.surfnet.nl [194.171.26.203] with 32 bytes of data:

Reply from 194.171.26.203: bytes=32 time=322ms TTL=110
Reply from 194.171.26.203: bytes=32 time=313ms TTL=110
Reply from 194.171.26.203: bytes=32 time=313ms TTL=110
Reply from 194.171.26.203: bytes=32 time=313ms TTL=110

Ping statistics for 194.171.26.203:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 313ms, Maximum = 322ms, Average = 315ms


Regards
   Brian Carpenter


On 2010-03-16 22:28, Gert Doering wrote:
> Hi,
> 
> On Tue, Mar 16, 2010 at 10:13:18AM +0100, Tore Anderson wrote:
>> on and on.  Network latency is without question on that list. While
>> nothing can be done about a user's high-latency connection, 150ms of
>> additional client-server latency due to IPv6 being used will quickly add
>> up to seconds in terms of overall page load time for a complex web site,
> 
> I keep wondering about those 150ms.  I seem to remember that Google saw
> *few users* that had a much higher IPv6 latency - but at the same time
> they also saw users with a *lower* latency via IPv6 (due to different
> network paths being taken).
> 
> For me, the v4/v6 latency is very similar - I use v6 all day, many of
> the sites I connect to (including google) have v6, and I do not see any
> adverse effects (nor any positive effects - it's just IP, after all).
> 
> So I'd like to see these 150ms qualified - in this discussion, it seems
> to be the assumption that "IPv6 will *always* be 150ms slower", which 
> is most definitely not the case.
> 
> Gert Doering
>         -- NetMaster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100317/1d90460a/attachment.htm>