Measuring World IPv6 Launch - Comparing IPv4 and IPv6 Performance

Like for last year's World IPv6 Day we looked into relative performance of IPv4 and IPv6 from the measurements we conducted. In our measurements we had 52 vantage points and 33 destinations (web servers) that provided both IPv4 and IPv6 ping round trip times. While our vantage points and destinations are geographically diverse, we don't know how representative they are for the Internet as a whole. For the part of the Internet that we measured, we see some interesting things about the state of IPv4 and IPv6.

Figure 1: Histogram of relative performance of IPv4/IPv6 for 15 minute intervals per source-destination pair

Figure 1 is a histogram of the relative performance of IPv4 and IPv6 as recorded by our World IPv6 Launch measurements. We took the minimum round trip time (RTT) we saw in IPv4 and IPv6 in each 15 minute time interval between each source and destination and calculated the performance from that. We defined relative performance as the difference between RTTs relative to the fastest protocol (i.e. 100% * (slowRTT - fastRTT) / fastRTT ).

The result is similar to what we saw last year . The distribution has a bell-shape, that is clearly "fatter" on the IPv4 side. Because RTTs will never be exactly the same in IPv4 and IPv6, we picked several ranges that we define as "equal performance". Table 1 shows the ranges we picked and how our measurements were split in 3 groups: IPv6 performing better, equal performance and IPv4 performing better.

Table 1: Performance categorisation for various definitions of equal performance.

For most of the definitions in Table 1, the majority of measurements showed equal performance for IPv4 and IPv6. If performance was not equal, IPv4 more often performed better.

As this distribution has long tails, we aggregated values of over 250% difference into a single bin, as can be seen in Figure 1. This shows that in 8% of cases IPv4 was over 250% faster, while in 2% of cases IPv6 was over 250% faster.

Looking deeper into these "over 250%" performance differences we see that these mostly seem to occur when websites are hosted from multiple locations across the world. Examples are the big search engines (Google,Yahoo,Bing) and content hosted on content delivery networks (CDNs). The typical setup here is that by DNS-redirects a client is directed to a specific locations, which can be a different physical location for IPv4 and IPv6 (some people call this "stupid DNS tricks" ). It would make sense to direct clients to the closest data center, for reduced latency and thus the best possible user experience. While we see this is typically the case, sometimes the performance difference between IPv4 and IPv6 is major, which is an indication that clients get directed to different physical locations depending on what IP protocol they would use. This could be caused by either the intelligence behind the DNS-redirects not always picking the 'best' data center for a particular client connection to be terminated. An alternative explanation could be that only a part of all data centers for a particular content provider are IPv6 enabled. If, for instance, an organisation has not enabled IPv6 on its data centers in South America, dual-stacked clients in South America will feel a performance hit by going to dual-stacked content for that organisation, as they will need to go off-continent to fetch content over IPv6, while in IPv4 they can stay relatively local.

In these cases of major performance difference, end-users that use some form of happy-eyeballs (HE) in web browser and/or operating system are at an advantage. At lower RTT differences (i.e. the majority of cases) the usage of happy-eyeballs seems less useful, but instead could hamper IPv6 deployment by having browsers not use perfectly usable IPv6 connectivity, but instead potentially clogging the legacy IPv4 network.

Figure 2: Relative performance of IPv4 and IPv6 split into two broad classes

Figure 2 shows the relative performance split into two broad classes, that we defined as follows:

• Low RTT: both IPv4 and IPv6 have RTTs of under 50 ms (green solid line), and
• Higher RTT: at least one of IPv4 and IPv6 has an RTT of over 50 ms (blue dotted line).

One thing that Figure 2 shows is that the extremes of the graph (over 250% difference in performance) become less pronounced at higher RTTs. Figure 2 also shows that in these measurements at higher RTT, IPv4 and IPv6 performance becomes more similar, while at lower RTT (i.e. source and destination are closer together) the chances of IPv4 performing better are higher. It is not entirely surprising that at higher RTTs performance becomes more similar, because the relative time that packets are 'on the wire' (as opposed to in buffers at routers or maybe even at the end points) increases, and the speed of light in fiber should be pretty much exactly the same for IPv4 and IPv6 packets. The fact that for lower RTTs IPv4 does a bit better in our measurements could indicate that either the infrastructure or the end points (our vantage points and the web servers) that we measured as a whole perform a bit better on IPv4 then on IPv6. It would be interesting to find out what causes this slight, but measurable difference.

Differences in AS path could also explain differences in performance over IPv4 and IPv6. Measurements by Nikkah et al. indeed show that with equal AS-paths performance is similar, while with different AS-paths IPv4 typically performs better. This suggests that it is in the best interest of the Internet as a whole to have the same interconnects between networks in IPv6 as there are currently in IPv4, as already outlined in: IPv6: what could be (but isn't yet)

Conclusion

We can basically repeat most of last year's conclusion (in blue) from similar IPv4/IPv6 performance measurements:

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, but for a significant fraction of measurements IPv6 is the faster protocol.

This year we saw in roughly 10% of the cases that IPv6 was already faster, and with further maturation of the IPv6 network this is only expected to rise. When there is a difference in performance it is typically IPv4 that is faster. When there is a major difference in performance we see this typically being caused by IPv4 and IPv6 end-points for a single hostname being terminated at physically different locations.

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.

So being dual-stacked means 2 chances for best performance!