Does Size Matter?
By Ankur Chadda and Philip Joung
Spirent Communications

Most readers of this newsletter fully understand and appreciate the value and reasons for IPv6. Indeed, IPv6 will make our networks easier to use, more secure, more scalable and perform faster, right? Well, strong arguments can be made for the first three (and numerous articles have discussed this previously), but what about the fourth? The story for performance isn't quite so clear.

For one, maximum packet sizes have increased in size from 64 kilobytes in IPv4 to 4 gigabytes in IPv6, enabling a significant improvement in efficiency depending on the traffic being transferred. IPv6 also has a flow label feature which marks all the packets going to a single destination with the same label. This can improve efficiency by automatically having network equipment handle these labeled packets in a similar way.

Flow label information can be utilized to effectively implement traffic engineering (according to usipv6.com, it can improve efficiency from 27% in IPv4 to 81% in IPv6). Headers in IPv6 have changed, with six fields removed and one new field added, allowing for more efficient routing.

What performance hits does IPv6 have? The headers in IPv6 are now twice the size of ones in IPv4, which is not bad given the large increase in address bit size. IPv6 also adds IPSec, which itself adds further overhead and can reduce performance. IPv4 is well understood and mature, with many years of use globally, often with custom hardware devoted to dealing with and minimizing the weaknesses of IPv4. The IPv4 versions of software have been optimized and tweaked for many years, often bringing about improvements in performance and stability. IPv6 can't claim the same level of hardware or software maturity yet, although it will quickly catch up as adoption increases. Indeed, the story for performance isn't completely straightforward.

Testing is one way to gain a clearer picture of performance, so that's what we did. In our testing we used a Web traffic generator creating HTTP/1.1 requests against a Web site simulator, connected to each other using a cross-over Ethernet cable. The systems support both IPv4 and IPv6 natively. However, since we didn't know if the software implementations for IPv4 and IPv6 would perform similarly in these testers, we controlled for that factor by keeping configurations as between IP versions as constant as possible. In other words, we took great pains to eliminate all extraneous variables and ensure a true apples-to-apples comparison. We also ensured that we didn't stress the systems beyond their capacity.

Before running our actual tests, we verified that the system could generate similar amounts of bandwidth utilization on the 1-gigabit copper port we used. During testing using the same configurations, IPv4 and IPv6 both exceeded 850 Mbps. Given this result, we conducted tests that made sure to remain well under this performance "ceiling."

Next, we ran tests to isolate the differences in IPv4 and IPv6 by changing only one factor at a time. In this case, we changed file sizes being retrieved, which would translate to an alteration of the average packet size being used in the test. We ran several tests, each using the different file sizes, first using IPv4, and then using IPv6. For the test gear, this meant that the amount of data transferred in each HTTP connection was varied. Traffic was held steady at 50 HTTP connections per second, and we recorded the bandwidth utilization. Given the increased header size and IPSec in IPv6, we would expect IPv6 traffic to need more bandwidth, and that is indeed what we saw.

Also, as expected, as the file sizes got larger, the amount of extra bandwidth needed decreased. The larger packet size enabled IPv6 to improve in efficiency with respect to IPv4. At a file size of 100 bytes, IPv6 needed 8.33 percent more bandwidth while a 1-megabyte file size required only 0.93 percent extra bandwidth. Please note that as the file size increases to the extent that it starts hitting the maximum packet size, there will not be much change in the packet size.

File size	Steady state HTTP connections/sec	IPv4 bandwidth utilization (Mbps)	IPv6 bandwidth utilization (Mbps)	Increase v4 to v6 in percent
100 B	50 cps	0.168	0.182	8.333%
1 KB	50 cps	5.485	5.603	2.151%
10 KB	50 cps	4.478	4.539	1.362%
100 KB	50 cps	43.691	44.102	0.941%
1 MB	50 cps	446.326	450.459	0.926%

What does this test tell us? We know that as the transition to IPv6 takes place, there will probably be a minor increase in the bandwidth utilization for most networks. For protocols that use very small packets such as Voice over IP (VoIP) or Simple Network Management Protocol (SNMP), the increase will be more pronounced. Typically VoIP applications use small packet sizes so that the delay is low and the voice quality degradation from loss might be minimized. VoIP applications tend to use packet sizes in the range of hundreds of bytes. SNMP, which tends to have small notification messages, typically has even smaller packet sizes.

What is this test not showing us? Since the traffic in this test is not routed, we did not test the difference that routing would have in IPv4 and IPv6. Also, we did not exhaust all the possible combinations of parameters that might have an effect on performance. We didn't test transition mechanisms, which may have their own performance issues. We also could have delved into specific products to determine the performance of their specific IPv4 and IPv6 implementations (e.g. take a particular firewall and test identical traffic through it using IPv4 and IPv6).

In the end, many readers of the 6Sense newsletter will be the forerunners in transitioning legacy IPv4 networks over to IPv6 networks. We have an obligation to make this transition occur as effectively as possible, and performance will likely be an important consideration for a smooth transition. We hope you'll run your own tests to determine the changes in performance. We're certain readers of 6Sense would be very interested to hear about your results!