Emulation Result

We compare the performance of IST implemented in application layer as well as in kernel layer. Since application layer forwarding requires at least four memory copies to forward a packet and TCP Splice in OS kernel only needs two memory copies, the latter would obviously feature better performance than the former. The main purpose of this emulation is to show how much improvement our method can achieve on a network device with limited computing power.

We estimate the improvement of our method by performing the emulation in five phases:

Direct Connect, Forwarder, NAT, IST in Application Layer and IST in OS Kernel. The

topologies are shown in Figure 5.4. Host A and host B are normal PCs which have 256 Mbytes memory and operate at 568 MHz. We test Direct Connect performance by measuring the maximal throughput between host A and host B. The forwarder here is the forwarding

functionality in Linux kernel. Once the functionality is turned on, Linux will forward packets from each NIC to all NICs. We test the performance of Linux forwarder to get the maximal throughput that IXP425 can achieve. The third phase is NAT. We turn on the NAT ability of Linux kernel to test its maximal throughput. Since the Linux kernel is finely tuned, we

consider the throughput of Linux NAT as the best throughput a forwarder can achieve when it needs to check some information in a table while forwarding a packet. The fourth and fifth phases are implementation of IST in application layer and kernel layer respectively. We compare the results of these two phases to show the improvement of our method. Since the implementation of IST in application layer is similar to Skype [9], we can consider the

emulation result of phase four as the performance of Skype when applying to general purpose solution.

Figure 5.4:29Emulation Topologies. (A): Forwarder, NAT and IST. (B): Direct Connect

Figure 5.5 shows the comparison of round trip time of five phases. The results are measured by a UDP Ping-Pong program. The Direct Connect phase has the lowest RTT. The RTT of forwarder and NAT phases is more than one hundred nano-seconds longer than that of Direct Connect. This result shows that the forwarder and NAT implementation of Linux Kernel is well tuned and the IXP425 processor is capable of doing this job, because it needs only about one hundred nano-seconds to duplicate and transmit a packet. The RTT of our IST

implementations in application layer and kernel layer are about 498 and 423 nano-seconds. The long latency of IST in application layer is obvious since it requires at least four memory copies.

However, the RTT of IST in kernel layer is still up to 425 nano-seconds which may be considered as too long. We believe the long RTT of IST in kernel layer is due to our kernel code that has not been finely tuned. If we carefully tune our kernel code, the best RTT of IST in kernel maybe reduced to equal to the RTT of NAT.

134

Figure 5.5:30Comparison of Round Trip Time.

We test the TCP throughput of five phases above. One host creates one TCP connection, ten TCP connections, twenty TCP connections … one hundred TCP connections to the other host via either a direct link or a forwarder and sends huge volume of data. Furthermore, the sender estimates the total number of data it sends in a time period as transmission throughput;

and the receiver estimates the total number of data it receives in a time period as receiving throughput. Finally we average these two throughputs as the final result. Figure 5.6 shows the results of TCP throughput. It is obvious that only IST in application layer phase has poor performance, while IST in kernel layer phase performs as well as first three phases. The main reason of IST in application layer phase has such poor performance may be due to the fact that it requires additional two memory copies (kernel layer to application layer and application layer to kernel layer). This emulation result also shows that if we use Skype to transmit normal

application data instead of voice data, we would get very poor performance.

Figure 5.6:31Comparison of TCP throughput.

Figure 5.7:32Magnification of TCP throughput comparison.

Figure 5.7 magnifies Figure 5.6 and shows that Direct Connect phase has the best throughput. There is a trend that IST in kernel layer would perform better than NAT when the number of connections increases. This maybe due to that NAT needs to lookup its NAT mapping table to forward a packet. When the mapping table becomes bigger, it may require a little more table lookup time to lookup this table. Our IST kernel implementation uses hash table to maintain the connection splicing information. When the number of connections becomes larger, the table lookup time would not increase. With the trend that TCP throughput increases with the number of connections, IST kernel implementation performs better than

NAT when the number of connections is bigger than 70.

We test the UDP performance by using one host sending variable data rate to another host and measure the packet loss rate. The emulation experience shows an interesting phenomenon, the packet size plays an important role when measuring the UDP loss rate. When the packet size is bigger than a certain threshold, the UDP loss rate is kept persistent no matter how light the sending rate is.

UDP Transmission Speed(Mbps) (packet size = 1k)

Loss Rate (%)

Figure 5.8:33Comparison of UDP loss rate with 1Kbyte packet size.

Figure 5.8 shows the UDP loss rate of variable sending rate when packet size equals 1 Kbytes. Only IST implementation in application layer would drop packets, while IST kernel implementation would not. This result shows that IXP425 is sufficient to perform the

functionality of IST when it runs MontaVista Linux kernel. However, when the packet size increases up to 6 Kbytes, NAT phase and IST kernel layer phase drop packet when the sending rate is larger than 63 Mbps. The overhead of memory copy is so enormous and IST application layer phase drops almost all packets no matter what the data rate is.

0

UDP Transmission Speed(Mbps) (packet size = 6k)

Loss Rate (%) Direct Connect

Forward NAT IST - App.

IST - Kernel

Figure 5.9:34Comparison of UDP loss rate with 6Kbyte packet size.

Figure 5.10 shows the UDP loss rate with variable packet sizes and UDP is sending at full line speed. Direct Connect phase and Forward phase perform well and never drop packets. The performance of IST kernel implementation is similar to NAT since they do almost the same job (modification to packet header and recalculate checksum). The performance of IST application layer implementation is the worst due to the overhead of memory copies.

0

512 786 1024 2048 3072 4096 5120 6144

UDP Packet Size (Byte) (send at full speed)

Loss Rate (%) Direct Connect

Forward NAT IST - App.

IST - Kernel

Figure 5.10:35Comparison of UDP loss rate with variable packet sizes.

It is interesting that when packet size is less than 1 Kbytes the UDP loss rate increases rapidly. We consider the reason of this phenomenon is similar to the “Live Lock” problem of operating system. Since the emulation is performed by sending UDP packets with maximal rate, the IXP425 needs to handle too many small packets at the same time and finally drops some of them. This figure also shows that Linux kernel is optimized for handling packets with size

around 1 Kbytes. Linux kernel adjusts its data structures and default buffer size to optimize it whole system performance.

When packet size is bigger than 1KB, the UDP loss rate also increases. We consider it is due to the overhead of memory copies. The bigger the packet size is, the more memory copy latency would be required.

Since the default Ethernet MTU (Maximum Transmission Unit) of most OSs are 1500 bytes, we can consider that our IST kernel implementation on IXP425 network processor is very capable of performing the functionalities of IST. And we can deploy ISTs to each system users’ home network as their home gateway to improve the whole system performance.

Chapter 6

Conclusion and Future Work

In this thesis, we design and implement the infrastructure of Internet Service Broker for NAT traversal. There are many related techniques devised to NAT traversal problem. However, each of them has some drawbacks or inconvenience. We propose an infrastructure of Internet Service Broker to overcome these disadvantages and provide a general purpose solution which can be applied to all sorts of existing network applications. The key design guideline is to make our solution feasible for deployment. Users of our system only need to execute an application layer daemon and login to the Internet Service Broker located in globally-addressable Internet, and existing network applications can get the capability of NAT traversal without any

modification. In addition, our system can be also applied to Firewall Traversal and IPv4 / IPv6 translation.

We propose Passive TCP Splice and Pure TCP Splice to improve the forwarding performance of third party node for our system. Furthermore, our system can utilize P2P structure to improve scalability. The emulation result shows that we can apply our TCP Splice mechanisms to the computing power limited network device and achieve satisfactory

performance.

Since the emulation result only demonstrates that our Internet Service Translator can be

guarantee the whole system performance when there are huge number of system users. Our future work is to implement our system in P2P structure. The main objective is to let every system users to perform the functionalities of centralized servers. In addition, we have to propose an algorithm for Internet Service Broker to help system users find the closest Internet Service Translator. Once these works were accomplished, our system can provide the

guaranteed quality of service.

Reference

[1] V. Fuller, T. Li, J. Yu, and K. Varadhan, “Classless Inter Domain Routing (CIDR): an address assignment and aggregation strategy,” IETF RFC 1519, Sept. 1993.

[2] P. Srisuresh and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT),” IETF RFC 3022, January 2001.

[3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.

Handley and E. Schooler, “SIP: Session Initiation Protocol,” IETF RFC 3261, June 2002.

[4] M. Leech, M. Ganis, Y. Lee, R. kuris, D. Koblas, and L. Jones, “SOCKS protocol version 5”, RFC 1928, April 1996.

[5] E.S. Lee, H.S. Chae, B.S. Park and M.R. Choi, “An Expanded NAT with Server

Connection Ability”, TECON 99, Proceedings of the IEEE Region 10 Conference, Volume:

2, pages 1391 - 1394, Sept. 1999.

[6] V. Pai and P. Rana, “A Transparent Framework for Enabling Incoming TCP Connections to Hosts Behind a NAT Gateway,” IEEE Computer Communications and Networks, 2003.

ICCCN 2003. Proceedings. The 12th International Conference, pages 572 – 575, October 2003.

[7] Microsoft Corporation, UPnP – Universal Plug and Play Internet Gateway Device v1.01,

Nov. 2001. Available online http://www.upnp.org/standardizeddcps/documents/

UPnP_IGD_1.0.zip. 30 April 2004.

[8] P. Francis and R. Gummadi, “IPNL: A NAT-Extended Internet Architecture,” ACM SIGCOMM Computer Communication Review, Proceedings of the 2001 conference on

Applications, technologies, architectures, and protocols for computer communications, Volume 31 Issue 4, August 2001.

[9] Skype, http://www.skype.com.

[10] S. Guha, Y. Takeda and P. Francis, “NUTSS: A SIP-based Approach to UDP and TCP Network Connectivity,” ACM SIGCOMM, Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture, pages 43 – 48, August 2004.

[11] KaZaa, http://www.kazaa.com.

[12] S.A. Baset and H. Schulzrinne, “An Analysis of the Skype Peer-to-Peer Internet

Telephony Protocol,” Available online http://arxiv.org/ftp/cs/papers/0412/0412017.pdf, Sept. 2004.

[13] J. Rosenberg, R. Mahy, and C. Huitma, “TURN – Traversal Using Relay NAT,” IEEE Internet draft, Feb. 2004.

[14] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, “STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” IEEE RFC 3489, Mar. 2003.

[15] Netperf, http://www.netperf.org/netperf/NetperfPage.html.

[16] D. Maltz and P. Bhagwat, “TCP Splicing for Application Layer Proxy Performance,” IBM Research Report, Mar. 1998.

[17] B.Y. Zhao, J. Kubiatowicz and D. Joseph, “Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing,” Selected Area in Communications, IEEE Journal on Volume 22, Issue1, Jan. 2004.

[18] Richard Steven, “TCP/IP Illustrated Volume 1,” Addison Wesley.

[19] B. Braden, D. Borman and C. Partridge, “Computing the Internet Checksum,” IEEE RFC 1071, Sep. 1988.

[20] T. Mallory and A. Kullberg, “Incremental Updating of the Internet Checksum,” IEEE RFC 1141, Jan. 1990.

[21] K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” IEEE RFC 1631, May 1994.

[22] Intel IXP425 Network Processor,

http://www.intel.com.tw/design/network/products/npfamily/ixp425.htm [23] MontaVista Linux, http://www.mvista.com/

[24] I. Stoica, R. Morris, D. Karger, M. Frans and H. Balakrishnan, “Chord: A Scalable

Peer-to-Peer Lookup Service for Internet Applications,” ACM SIGCOMM, Proceedings of the ACM SIGCOMM, Volume 11, Issue 1, Feb. 2003.

[25] S. Ratnasamy, P. Francis, M. Handley and R. Karp, “A Scalable content-Addressable Network,” ACM SIGCOMM, Proceedings of the ACM SIGCOMM, Volume 31, Issue 4, Aug. 2001.