 |
Applications and Benchmarks |
This webpage presents basic performance measurements and describes a set of applications that we have used to verify whether the translator works for real applications. Our experimental setup consists of IPv6 and IPv4 machines connected to separate, private Ethernet segments. The translator is equipped with two Ethernet cards and acts as a gateway between the IPv6 and IPv4 Ethernet segments. All machines in our setup are Intel PCs equipped with a 200Mhz Pentium Pro processor, 64MB of RAM, and 3COM 3c905 fast Ethernet cards. We use both Linux (2.1.95) and Windows NT 4.0 as our IPv6 test machines. For Windows NT we use Microsoft Research’s publicly released IPv6 stack. The translator is implemented as a Windows NT device driver and roughly consists of 2000 lines of C code. It uses the IPv4 and IPv6 stacks in Windows NT to send IP packets.
Latency and Bandwidth
To evaluate the performance of the translator we used the
ttcp tool to measure bandwidth and ping to measure latency between a pair of IPv6 and IPv4 hosts. We compare the packet forwarding performance of the IPv6/IPv4 translator with NT’s built-in IPv4 forwarding support.We measured the roundtrip latency of
ping packets ranging in size from 64 bytes to 1440 bytes on 100Mbps Ethernet links. In Table 1, the columns labeled v4-v4 and v6-v6 show the latency between two machines communicating directly using the same protocol. The columns labeled FWD and NAPT show the roundtrip latency going through NT’s forwarder and our translator, respectively. The translator is on average about 30 microseconds slower compared to the forwarder.
Table 1. Roundtrip latency of PING packets measured in microseconds. |
Table 2 shows the bandwidth of sending 64 Mbytes using TCP for both 10Mbps and 100Mbps Ethernet. Note that for 10Mbps Ethernet the overhead of the translator and the forwarder are essentially unnoticeable. However, the bandwidth for the forwarder and the translator on fast Ethernet is much lower compared to two machines communicating directly using either IPv4 or IPv6. Using NT’s performance monitor we noticed that processor utilization reaches nearly 100% on our forwarder/translator machine when running the ttcp bandwidth benchmark over fast Ethernet. The reason for the high CPU utilization is NT’s packet receive architecture, which assumes the device driver owns the packet buffer rather than passing buffer ownership to the module receiving the packet (as is the case in most UNIX systems). Consequently, we believe that bandwidth through the translator and the forwarder are CPU limited, as they incur significant overhead due to NT’s packet receive architecture; they must allocate buffer space for the IP packet’s payload and copy the data in its entirety before being able to forward it. Additionally, note that the bandwidth through the translator is 10% slower compared to the forwarder. We attribute this performance degradation partly to the IPv6 prototype from Microsoft Research, which is roughly 1.9Mbytes/second slower than the production IPv4 stack shipped with Windows NT. We expect the end-to-end TCP bandwidth to improve as the IPv6 implementation for Windows NT matures.
Table 2. TCP bandwidth measured in Kbytes/second. |
We are pleased with the current latency and bandwidth measurements, as they indicate that translation does not inherently have a significant impact on performance.
ApplicationsThe goal of the translator is to transparently work for "real world" applications, and we used a representative set of programs that exercise the TCP, UDP, and ICMP protocols via the translator. Our test applications consist of an IPv6 version of an Apache web-server,
ttcp, finger, telnet, ping, traceroute, and ftp.We knew from our experiments with
ttcp that the TCP protocol translation works, but wanted to verify this with common TCP applications. We were able to use telnet and finger to connect between IPv6 and IPv4 hosts through the translator. Additionally, a web browser on an IPv4 host retrieving documents from an IPv6 Apache web-server was equally successful.The
ping program uses ICMP messages to determine whether a particular host is alive. We also used ping to measure basic roundtrip latency between hosts.The
traceroute program tracks the flow of a packet from router to router. When tracking routes from an IPv6 node through the translator along an IPv4 network, the addresses of the IPv4 routers are translated into IPv4-mapped IPv6 addresses. For the other direction, the translator establishes bindings for the IPv6 router addresses to private network addresses.Although
ping and traceroute use ICMP, they do not adequately test whether the recursive ICMP translation was working properly. Table 3 lists how we caused various ICMP error messages to verify their correct translation.
Table 3. Error causing actions to verify ICMP tranlation. |
Finally, we tested
ftp, which is an application that embeds an ASCII IP address and sends it to its peer. For it to work correctly via the translator, the IPv6 implementation of the ftp client needs to detect whether the connection is with an IPv6 or IPv4 version of the ftp daemon. When communicating with an IPv4 ftp daemon it needs to use as an ASCII IP address of its host's IPv4-compatible IPv6 address instead of the host's native IPv6 address. Conversely, when an IPv4 ftp client contacts an IPv6 ftp daemon, the daemon must treat the ASCII IP address as an IPv4-mapped IPv6 address. With this approach it is not necessary for the translator to update the ASCII IP address.