During World IPv6 day we measured the performance of IPv4 and IPv6 between 40 vantage points and 46 World IPv6 Day participants and other dual-stacked sites. If one has to pick a winner, then the old protocol, IPv4, would win, but IPv6 often shows comparable or better performance.
If a dual-stack client connects to a hostname for which both an A and a AAAA record is advertised in DNS, it has to make a choice: Connect over IPv4 or over IPv6. Assuming both are viable options, there is a lot that can influence the performance of the IPv4 and/or the IPv6 connection. Some of the factors that influence performance are:
Forwarding:
- Routers that forward one protocol in hardware (fast) the other in software (slower). So if IPv6-forwarding is implemented in software, while IPv4-forwarding is implemented in hardware, IPv4 would have a clear performance advantage.
- Fewer parts in the IPv6 header have to be changed on a hop-to-hop basis, which should make it perform better relative to IPv4
- IPv6 has larger packet headers, which could make it slower relative to IPv4
End points:
- For a given hostname, the IPv4 and IPv6 end-points may end up at a completely different host in a completely different network. The distance from a source to either the IPv4- or IPv6-destination influences the performance.
Network:
- The BGP path-forwarding decision process makes IPv4 packets to a given AS go over a completely different path than IPv6 packets to the same AS. This is necessarily the case when one AS in the IPv4 forwarding path doesn't have IPv6 capabilities.
- Differential treatment of IPv4 and IPv6 within an AS. For instance if IPv6 is tunneled across an IPv4-only core network.
Results
Our active measurements during World IPv6 Day (8 June 2011), included ICMP (IPv4) and ICMP6 (IPv6) measurements from our vantage points to selected hostnames of World IPv6 Day participants and other dual-stacked parties. For details about the IPv4/IPv6 performance metric used in the graphs below see footnote [1]. Figure 1 shows a histogram of all relative IPv4/IPv6 performance data points we collected during World IPv6 Day. A single data point consists of the relative IPv4/IPv6 performance from a single vantage point to a single destination during a 10 minute interval.
Figure 1 shows that while this distribution has a bell-shape, it clearly is "fatter" on the IPv4 side. So IPv4 is more often faster then IPv6. What this tells us is that you are slightly better off in an IPv4-only than an IPv6-only environment. On a dual-stack client that unconditionally prefers IPv6 over IPv4, IPv4 is more often the faster protocol, but this is far from a universal truth. There is also a significant chance that IPv6 is faster, since the "IPv6-is-faster" part of the histogram also has a significant volume.
If we take the same data and split it out by destination (Figure 2), we see clear differences between some of the World IPv6 Day participants. Each box in this boxplot shows 25th and 75th percentile of values as bottom and top of the boxes respectively and the median is displayed as a black bar. The "whiskers" extend out to the extreme values. We only show the participant names for sites where the median IPv6 performance was better then the IPv4 performance.
Note that we measured ICMP/ICMPv6, not HTTP performance. Also note that the IPv4 and IPv6 end-points for a given hostname may be topologically and/or geographically in (very) different places, especially when proxies are used for IPv6 to IPv4 translation. In cases where the IPv4 and IPv6 destination end-points are not at the same location, the distance between a vantage point and either the IPv4 or IPv6 destination end-point has a large influence on the measured performance.
If we look at the relative IPv4/IPv6 performance aggregated per vantage point (Figure 3), we see far less differences between vantage points. For all of our vantage points we know for sure that the IPv4 and IPv6 end-point are at the same physical location. This could be the reason for seeing less variation in IPv4/IPv6 performance between vantage points (Figure 3) then between destinations (Figure 2).
Conclusion
Comparable IPv4 and IPv6 performance can be seen as an indication of a mature deployment of both IPv4 and IPv6 in a network. In the data we analysed we see IPv4 is still generally faster then IPv6, for a significant fraction of measurements IPv6 is the faster protocol.
There is some potential benefit from this information for applications that need their communications to be as real-time as possible, like Internet telephony/video or gaming. For end-hosts that are dual-stacked, there are now two chances (IPv4 and IPv6) for the fastest method to get packets to another dual-stacked end-host, not only IPv4 anymore. While some (notably Blizzard ) have made significant steps towards enabling IPv6 in their applications, others (notably Skype ) have not yet taken steps. One operating system (Mac OS X Lion) has already started using a similar strategy . I think it will be interesting to see if and how applications will also start using "use-whatever-protocol-is-faster" strategies.
Footnote
[1] Aggregation methodology: To be able to compare performance of dissimilar source-destination pairs, for every source-destination pair the 10 minute average of IPv4 RTT was divided through the 10 minute average of IPv6 RTT. This results in a single performance metric per 10 minutes for a single source-destination pair. When aggregating across multiple source-destination pairs, for instance to get a single performance metric for a given source, the geometric mean was taken for all of the performance metrics calculated for the given aggregation (either time, sources or destinations). The geometric mean was chosen because it is insensitive to either IPv4 or IPv6 being chosen as denominator for the performance metric. In the plots the metric is displayed as how much better (as a percentage) the better performing protocol performs relative to the other protocol.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.