Tunnel overhead [On killing IPv6 transition mechanisms]

[Gert Doering]

Hi,

On Wed, Mar 17, 2010 at 01:40:55PM +1300, Brian E Carpenter wrote:
> 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.

Sounds like something that can be easily identified and people should
work to fix, no?

From here:

$ ping6 -c3 www.surfnet.nl
PING6(56=40+8+8 bytes) 2001:608:2:2::250 --> 2001:610:1:80d0:194:171:26:201
16 bytes from 2001:610:1:80d0:194:171:26:201, icmp_seq=0 hlim=54 time=15.950 ms
16 bytes from 2001:610:1:80d0:194:171:26:201, icmp_seq=1 hlim=54 time=16.674 ms
16 bytes from 2001:610:1:80d0:194:171:26:201, icmp_seq=2 hlim=54 time=15.807 ms

$ ping -c3 www.surfnet.nl 
PING www.surfnet.nl (194.171.26.203): 56 data bytes
64 bytes from 194.171.26.203: icmp_seq=0 ttl=118 time=32.051 ms
64 bytes from 194.171.26.203: icmp_seq=1 ttl=118 time=31.909 ms
64 bytes from 194.171.26.203: icmp_seq=2 ttl=118 time=31.905 ms

(now that is cool, isn't it?)

$ ping -c3 www.isc.org 
PING www.isc.org (149.20.64.42): 56 data bytes
64 bytes from 149.20.64.42: icmp_seq=0 ttl=57 time=168.623 ms
64 bytes from 149.20.64.42: icmp_seq=1 ttl=57 time=168.590 ms
64 bytes from 149.20.64.42: icmp_seq=2 ttl=57 time=168.420 ms

$ ping6 -c3 www.isc.org
PING6(56=40+8+8 bytes) 2001:608:2:2::250 --> 2001:4f8:0:2::d
16 bytes from 2001:4f8:0:2::d, icmp_seq=0 hlim=55 time=172.308 ms
16 bytes from 2001:4f8:0:2::d, icmp_seq=1 hlim=55 time=172.482 ms
16 bytes from 2001:4f8:0:2::d, icmp_seq=2 hlim=55 time=173.099 ms

(not too bad - those 4ms shouldn't really affect anything)


www.ietf.org sucks, tho (226 ms vs. 168 ms).


So yes - we're back at the Subject: line - "on killing transition
technologies".  There's tunnels that don't impact performance (because
they are on well-controlled infrastructure and just circumvent some
local problem), and there's other tunnels that are obviously bad.

These are local problems, though: someone has setup the tunnel, and this
person can control working on the situation and improving it.  6to4 
relays, on the other hand, are usually run by someone completely unknown 
to you, and if one of them is slow/unreliable, it's very hard to find 
out where it is.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100317/93844c0a/attachment.sig>