Interesting Graph - IPv6 Performance

Emile Aben — Aug 25, 2010 01:00 AM
Filed under: ,
This graph shows IPv6 performance as measured to www.ripe.net. These measurements show performance of native IPv6 on average being very close to IPv4.

IPv6 client performance to www.ripe.net

 

The data for this graph shows the difference between fetching an HTTP object over IPv4 and IPv6 to the same server by web-clients visiting www.ripe.net. I measured the time between receiving a DNS request and the corresponding HTTP request for both IPv4 and IPv6. The various types of IPv6 connectivity of web-clients show different performance characteristics. On average unicast IPv6 (native, green) is only 35 ms slower than IPv4, whereas brokered IPv6 (cyan) is 121 ms slower [1]. The autotunnel technologies perform a bit worse with 6to4 (blue) having an average extra delay of 259 ms and Teredo IPv6 (purple) takes on average 744 ms more than an IPv4 request from the same web-client [2].

This performance data and other information for a couple of sites that we monitor is available at http://albatross.ripe.net/v6-clientresolver/ (updated daily).

So in the near-future, when IPv6 content starts to become more commonplace, it's way better to have native IPv6 access to IPv6-only content. If you depend on 6to4 or Teredo for End Users to access IPv6-only content, expect noticeable difference in network performance.

This is joint work with Geoff Huston and George Michaelson of APNIC R&D, also see their presentation at APNIC30.

 

Footnotes:

[1] Brokered IPv6 is IPv6-tunneling through a tunnel-broker. We distinguish this from unicast/native IPv6 by labeling connections coming from IPv6 prefixes of well-known IPv6 tunnel-brokers as brokered. The large spike at the end of the graph is likely due to a problem at one of the IPv6 prefixes of one of the tunnel-brokers.

[2] We don't have Teredo or 6to4 relays in our network close to the measurement point. With local relays the extra delay for autotunneled IPv6 will probably be a bit less.

2 Comments

shane
shane says:
Aug 25, 2010 10:50 AM
I noticed the big spike in the brokered delay one day. It occurs to me that this may be one broker that is experiencing a lot of delay, and making the overall results look bad.

My point is that IPv6 problems may be related to the small amount of traffic, and that specific bad cases may change the overall picture.

There are lots of ways to try to figure this out. Maybe converting IPv6 origin address to AS number and then plotting the chart might be interesting. Or maybe just removing duplicate addresses (although this is always tricky with IPv6 of course, since the meaningful part of an address might be /128, /64, /48, /19, or... well, anything!
emileaben
emileaben says:
Aug 26, 2010 09:41 AM
It was indeed a single location of a single broker, ie. a single /40 in this case, that made that result for that day look bad, which proves your point.
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Navigation
Related Items
Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

Modifications to the IP Analyser to Reflect New Policy

We are in the process of implementing the policy regarding Post Depletion Adjustment of Procedures ...

Report on IPv6 Security Test Methodology

The Dutch Institute for Applied Scientific Research (TNO) and a number of Dutch security companies ...

RIPE Atlas: Improved Probe Pages

We've made it much easier to get an overview of the history and measurements for all the public ...

more ...