IPv6 Performance – and how to test it

Whether you are an IPv6 enthusiast who managed to get your IT organization excited about the opportunities offered by the IPv6 transition or you are an IPv6 pragmatist who is, for now, focused on managing the potential risk of an unmanaged transition, it is time to take IPv6 seriously. We cannot claim to be serious about IPv6 unless we can quantify the effectiveness of our IPv6 enablement and unless we have the tools to measure the performance of our IPv6 enablement.

To get IPv6 into production we need metrics and tools that allow us to operate and improve IPv6 enabled services. These are not new services. There is no “easing into the service” process, customers already have the baseline set by their IPv4 user experience.

Read the post as PDF...

In what cases do I need this information?

If you are an IPv6 Transition Program Manager, if you are operating a production IPv6-enabled web service or if for other reasons you need to demonstrate the effectiveness of an IPv6 enablement, you should ask yourself the following questions:

• How likely is it that users with IPv6 access will actually use the website over IPv6? In other words, is the investment made in IPv6 enabling the Internet Edge meeting the need that triggered the effort?
• Let’s assume users with IPv6 access will now start using your web services over IPv6 instead of IPv4. What is their user experience compared to what they were used to? Can you ensure their experience is meeting the IPv4 experience or is there a risk that their IPv6 experience is doing more harm than good?
• Can you monitor, manage and plan your web services delivered over IPv6 on par with those delivered over IPv4?
• Can you detect faults and troubleshoot problems with IPv6 enabled web services?

Are there any tools to do that?

We found a tool that helps to measure and monitor this type of information. It is called v6Sonar (www.v6sonar.com) and is a MaaS (Monitoring as a Service), cloud based service developed and managed by the IPv6 practitioners at Nephos6. The primary purpose of the service is to enable organizations to effectively manage their presence on the IPv6 Internet.

The service consists of a set of dual-stacked agents deployed in cloud provider infrastructures around the World. There are agents in San Jose, Chicago, Frankfurt and Hongkong. There will be more agents deployed in the coming weeks. (Figure 1)

Figure 1. Distribution of v6Sonar agents Worldwide.

Each agent collects DNS, website connectivity and website performance information at regular, configurable time intervals. Each agent calculates an IPv6 Effectiveness^TM score that accounts for the IPv6 behavior of various browsers (Happy Eyeballs type algorithms) and users experience over IPv6 versus IPv4. A high IPv6 Effectiveness means users who have IPv6 access are very likely to actually connect to the site over IPv6 and to have a user experience similar or better to the user experience they have over IPv4.

v6Sonar provides a quantitative, geographically meaningful way to measure the success of your IPv6 enablement of the Internet edge and to effectively operate it. Provisioning a website for monitoring is quick and simple. All relevant information is easily accessible via a web based interface.

The Tools section of the service provides access to several tools that will help in both analyzing the website performance and in investigating issues:

• HTTP history – displays the HTTP performance measurements for the past 5 hours (Figure 2)
• Ping history – displays the Ping history over the past 5 hours
• HTTP – enables users to measure the performance of a website on the spot and see the load times for all resources over IPv6 and over IPv4
• Traceroute – enables users to analyze the routing differences between IPv4 and IPv6 as seen by different agents (Figure 3)
• DNS (lab) – enables users to examine the IPv6 related records
• SMTP (lab) – enables users to measure the performance of IPv6 enabled mail service for a domain
• Security (lab) – enables users to compare the IPv4 and IPv6 Internet edge security rules (limited ports included by default, more extensive capabilities are available).

Case Study: www.swisscom.com

For our case study we have chosen Swisscom's main website. It is one of the major commercial websites in Switzerland that runs dual-stack (since World Launch Day in June 2012). The long term data was analyzed specifically for this case study. This type of service is available to licensing customers.

Data Snapshots

Data collected is summarized on the tool dashboard (Figure 2). It presents instantaneous performance information across the World on an interactive map, alerts related to website performance and short histories for ping (basic network connectivity test) and HTTP. Lines represent IPv6 data while dotted lines present IPv4 data. All measurements are in milliseconds. Figure 2 also shows the instantaneous IPv6 Effectiveness score of 22%.

Figure 2. Snapshot of the dashboard for swisscom.com

The dashboard shows a global overview of the agents (also see Figure 1, it's larger), including the IPv6 Effectiveness per agent, as well as the comparison of IPv4 and IPv6 ping and HTTP performance. The instantaneous data shown in Figure 2 snapshot shows IPv6 having a similar (Frankfurt) or even better performance than IPv4 (San Jose, Hong Kong). The long term data generated analytics indicates that on average, performance over IPv6 is better than over IPv4 for all agents (see Table below).

Both IPv6 and IPv4 performance is consistent during the day in the absence of unique events. As expected an elevated average load time is observed during European work hours. The v6Sonar service monitors and reports unique events such as: site down and site underperforming as shown in Figure 3.

Figure 3. HTTP history indicating a temporary incident for swisscom.com reported by v6Sonar

The typical performance of the website over IPv4 and over IPv6 is seen between 8:00 and 9:00 in Figure 3. Degraded performance is seen between 4:30 and 5:30 while the 30 seconds data points between 6:00 and 7:15 represent timeouts as seen by the various agents.

IPv6 Effectiveness

The IPv6 Effectiveness is calculated at agent level, regional level and Globally. Figure 4 shows the Frankfurt agent, the European region and Global IPv6 Effectiveness scores for www.swisscom.com.

Figure 4. IPv6 Effectiveness scores for www.swisscom.com.

Currently, v6Sonar is running a single agent in Europe thus being unable to provide details related to geographical dependencies of IPv6 Effectiveness within Europe. A more granular perspective is important, particularly as global IPv6 Internet topology is not the same as IPv4 topology. For example, the perspective from the two North America agents, San Jose and Chicago, shows variations due to performance of IPv6 paths from the two locations.

In an analysis of the website of a North American large Service Provider, the Chicago agent displayed very poor IPv6 performance due to the path established by that service provider’s peering choices.

In March 2013, a London based based and a Singapore based agent were installed thus providing additional data on IPv6 performance of webpages. Additional agents can easily be installed and operated at locations requested by customers.

HTTP Performance

Figure 5. HTTP performance historical data snapshot for www.swisscom.com.

The colors of the lines represent the agent (color scheme upper right corner). Normal lines represent IPv6 and dotted lines represent IPv4 performance. With this overview it is easy to get an overall understanding of performance and quickly detect exceptional cases to be further analyzed.

While the data captured in Figure 5 can provide an indication of the average performance over IPv4 and IPv6 for the past 5 hours, v6Sonar analyzes larger data sets and continuously calculates the key metrics relevant to assessing the performance and reliability of the webpage.

The average HTTP performance for www.swisscom.com over IPv6 is better than over IPv4 for all agents (Figure 6). The subsequent section discusses the Chicago data point which represents a manageable problem.

Figure 6. Average load times over IPv4 and IPv6 for each agent.

Figure 7 shows the hourly average of the webpage load times over IPv4 (in orange) and over IPv6 (in blue) for one of the observation days: February 17, 2013.

Figure 7. Daily history of IPv6/IPv4 load times measured by San Jose agent.

As expected, increased variability and an increased average load time is observed for both IPv6 and IPv4 during the European regular business hours (the graph time stamps are Eastern Standard Time, 6 hours behind Switzerland time). The multiday monitoring shows that IPv6 load times for wwwswisscom.com are consistently shorter than the IPv4 load times.

This data enables operations teams to analyze IPv6 performance compared to IPv4 performance and to observe and analyze any patterns or trends related to performance.

v6Sonar can also send automated alerts to designated accounts when the site is not accessible by either IPv6 or IPv4 and when performance degradation is experienced over either of the two protocols.

IP Connectivity

Slower and longer IPv4 path from Chicago impacts the IPv4 load times measured by the local agent.

To better understand the problem, the traceroute tool was used to identify and compare the IPv4 and IPv6 paths from the Chicago agent to the target web server (Figure 8).

Figure 8. IPv6 and IPv4 traceroutes to www.swisscom.com from Chicago agent.

The IPv6 path is shorter than the IPv4 path and it does not appear to include tunnels. This topological difference is reflected in a significantly better performance over IPv6 vs IPv4. This is not always the case. As mentioned earlier, for the website of other large Service Providers, IPv6 peering problems can lead to highly degraded IPv6 performance from certain geographical locations.

As seen in Figure 2, Swisscom blocks IPv4 Echo ICMP traffic but does not block IPv6 Echo ICMP traffic.