Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
Following on from last year’s measurements after World IPv6 Day (see an earlier post on CircleID: Comparing IPv4 and IPv6 Performance), the RIPE NCC carried out active measurements on World IPv6 Launch on 6 June 2012. These measurements included latency measurements both on IPv4 and IPv6 from our vantage points to selected hostnames of World IPv6 Launch participants and other dual-stacked parties. We used these measurements to determine the performance of IPv4 versus IPv6 connections.
The figure below shows a histogram of all relative IPv4 versus IPv6 performance data points collected during World IPv6 Launch. A single data point consists of the relative performance of IPv4 and IPv6 between one of our vantage points and a World IPv6 Launch participant over a15 minute time frame.
The peak in the middle of this histogram shows that the IPv4 and IPv6 performance that we measured is roughly similar. Comparable IPv4 and IPv6 performance can be seen as an indication of mature deployment of both IPv4 and IPv6 in a network.
The fact that the bell-shaped curve is a little “fatter” on the IPv4 side, indicates that when performance differs, it is usually IPv4 that is faster than IPv6.
For end-hosts, being dual-stacked means there are two methods (IPv4 and IPv6) to get packets to another dual-stacked end-host, so they are not only relying on IPv4. This year we saw that IPv6 was already faster in roughly 10% of the cases, and with further maturation of the IPv6 network this is only expected to rise.
So being dual-stacked means two chances for better performance!
For more information and a description of the methodology, please refer to the background article on RIPE Labs: Measuring World IPv6 Launch - Comparing IPv4 and IPv6 Performance.
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byCSC
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.
I really don’t follow the metric of this graph. Is the horizontal supposed to show a ratio of performance? Fractal ratios migh be easier to grasp rather than percentages (well, for me). Something like a Stern-Brocot ratio breakdown.
I only have a couple of points I can do any real IPv6 speed measurement with (where I control both machines to be sure what they are doing), that are at different points on the internet. So I’m really only measuring a single path.
Well, actually it is two paths, so I don’t know this means anything at all to compare them. Traceroute in IPv4 shows something entirely different than traceroute in IPv6. What is that like in tests others have done?
Between the two ISPs I have servers at, there’s a world of difference between IPv4 and IPv6. I’ve seen as much as a 40x ratio (IPv6 40 times faster than IPv4). Since it is different equipment on each, it could be the configuration, or how much saturation they have.
Another thing I find ironic is when testing in SCTP instead of TCP. In IPv4 SCTP is generally slower than TCP, sometimes a lot. In IPv6 SCTP is usually faster than TCP, with the ratio being rather stable. This may also be a factor of the fact that IPv6 is going over different (probably newer) equipment.
As for the metric: It is explained in more detail in the RIPE Labs article. As an example: if IPv4 takes 100ms and IPv6 takes 110ms, there is a 10% performance difference ( 100%*(110-100)/100 ), according to this metric. As for the measurements: These measurements are from 52 vantage points and we realize that our 33 destinations may or may not be the same physical server. We didn't select for destinations being the same physical end-point, because in real-life end-users also don't do that, for instance when they go to fetch content from a CDN. It is indeed interesting to look at performance when destinations are the same physical end-point and see how performance differs then. A few interesting results by Upenn+Comcast and independently CAIDA indicate that AS-path (dis)similarity is a good predictor for relative performance then.