Throughput and CPU Utilization of kP2PADM plus the Connection

cache is enabled. In the experiment, we set a policy on kP2PADM to block all packets from one of two clients. This policy forces the blocked client to keep sending reconnections. The connection cache can increase the throughput by about 15%. The CPU utilization always reaches about 100% because all handlings of kP2PADM are coded in the kernel space except for virus scanning, so the CPU utilization will be occupied by kP2PADM.

NAT NAT + Packet queue NAT + L7 + Packet queue P2P proxy + Filter P2P proxy + Log file

Throughput (Mbps)

kP2PADM kP2PADM + Connection Cache

Figure 8. Throughput of kP2PADM plus connection cache

0

P2P proxy + Filter P2P proxy + Log file P2P proxy + Virus scan P2P proxy + Virus scan + Log file + Filter

CPU Utilization (%)

kP2PADM Kernel CPU Utilization kP2PADM Total CPU Utilization

kP2PADM + Connection Cache Kernel CPU Utilization kP2PADM + Connection Cache Total CPU Utilization

Figure 9. CPU utilization of kP2PADM plus connection cache

4.2.3 Evaluation of Fast Pass 4.2.3.1 Benchmarking Environment

To emulate packet loss and out-of-order packets, we install a WAN emulator called NIST Net from National Institute of Standards and Technology (NIST) [7] on Linux. NIST Net allows a single Linux PC to act as a router to emulate a wide variety of network conditions, say packet loss, out-of-order packets, transmission delay, and so on. Fig. 10 illustrates the benchmark environment. A NIST Net stands before kP2PADM and emulates packet loss and delay. A notebook serves as the FTP client to request about 300 MB files from the FTP server.

Figure 10. Benchmarking environment for fast pass

4.2.3.2 Impact from Out-of-order Packets on Performance

Fig. 11 shows the transfer time with fast pass and without fast pass in different packet loss rate, respectively. The packet loss rate is from 0% to 5% to simulate the real environment [8]. Fast pass can reduce the transfer time between ftp client and ftp server. In the benchmarking result, we have two observations: (1) the higher the packet loss rate is, the more the transfer time between with fast pass and without fast pass can shorten and (2) the longer the delay is, the more the transfer time can be reduced. The first observation is because the times of queuing in the gateway is more high if more packet loss rate, so transfer time will more larger. The second observation is because the queue time in the gateway is longer if the delay of each packet is longer. Shortly speaking, fast pass can reduce the more transfer time while the delay time and drop rate is larger.

0

with Fast Pass (delay 0ms) without Fast Pass (delay 0ms) with Fast Pass (delay 10ms) without Fast Pass (delay 10ms) with Fast Pass (delay 100ms) without Fast Pass (delay 100ms)

Figure 11: Transfer time with Fast Pass and without Fast Pass in different packet loss rate

4.3 Internal Benchmarking

To further identify the improvements and the bottlenecks of kP2PADM, we examine the execution time of each step in the entire packet processing flow with all

functions turned on. Measuring execution time is performed by calculating the difference of time-stamps taken by the do_gettimeofday() kernel function before and after the code segments. Figure 12 (a) and (b) illustrate the internal benchmark of P2PADM and kP2PADM. Moving code from the user space to the kernel space can reduce the time of all steps. The most time-reduction is the time of getting packets and it shows that kP2PADM takes 5 ms to get packets. The least time-reduction is the time of handling HTTP protocol. Why the improving of handling HTTP protocol is marginal is because it takes much time to processing HTTP protocol rather than data passing between the kernel and the user space.

(a)

„ M1: Copy packet from kernel to user space (30 ms)

„ M2: Check checksum (8 ms)

„ M3: Packet classification (5 ms)

„ M4: Handle TCP sequence problem (20 ms)

„ M5: Handle HTTP Protocol (30 ms)

„ M3: Packet classification (5 ms)

„ M4: Handle TCP sequence problem (10 ms)

„ M5: Handle HTTP Protocol (28 ms)

„ M8: Log files (12 ms)

„ M9: Proxy sets verdict (6 ms)

Figure 12: Internal benchmark result

Chapter 5 Conclusions

This work presents the improvement of the P2PADM performance by moving the code of management from the user space to the kernel space. The main challenge in this work is how to move the code to the kernel space compatibly with Linux kernel without panicking the kernel. The new architecture, kP2PADM, must maintain some kernel-space data structures by itself, say structure sock to get data form packets effectively rather than get data through socket description in P2PADM. Besides, kP2PADM is responsible for scheduling the kernel because it is a kernel process. A kernel process occupies the CPU unless it surrenders the CPU voluntarily. kP2PADM also solves two weaknesses of P2PADM: the reconnection issue and non-deterministic delays from out-of-order packets. Through connection cache and fast pass, we can increase the throughput of P2PADM and the transmission time.

The external benchmarking results indicate that in-kernel management improves the performance of P2PADM. With and without kP2PADM, the throughput can achieve 164.68 Mbps and 85 Mbps, respectively. The throughput of kP2PADM is 79.68 Mbps higher than that of P2PADM. The connection cache can increase the throughput by about 20 Mbps. The CPU utilization of kP2PADM always reaches to 100% that is because all the handling of kP2PADM is implemented in the kernel space except for virus scanning. Therefore CPU always blocked by kP2PADM when benchmarking. Fast pass can reduce the more transfer time while the delay time and drop rate is larger.

References

[1] S. Sen, and Jia Wang, “Analyzing Peer-to-Peer Traffic across Large Networks,”

IEEE/ACM Transactions on Networking, vol. 12, no. 2, pp. 219-232, April 2004.

[2] S. Sen, O. Spatscheck, and D. Wang, “Accurate, Scalable In-Network Identification of P2P Traffic Using Application Signatures,” in Proc.

International WWW Conference, New York, 2004.

[3] Meng-Fu Tsai, “A Novel Gateway Architecture for Managing Dynamic Port Peer-to-Peer Traffic,” Master thesis, National Chiao Tung Unviersity, Hsinchu, Taiwan, 2005.

[4] Daniel P. Bovet and Marco Cesati, “Understanding the Linux Kernel,” 2^nd Ed, pp.

695, O’REILLY, 2003.

[5] J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov, “Linux Netlink as an IP Services Protocol,” RFC 3549, July 2003.

[Online] available: http://www.ietf.org/rfc/rfc3548.txt?number=3549

[6] S. Josefsson, “The Base16, Base32, and Base64 Data Encodings,” RFC 3548, July 2003.

[Online] available: http://www.ietf.org/rfc/rfc3548.txt?number=3548

[7] Mark Carson, Darrin Santay, “ NIST Net – A Linux-based Network Emulation Tool,” Computer Communication Review, ACM SIGCOMM, 2003.

[8] Maya Uajnik, Sue Moon, Jim Kurose and Don Towsley, ”Measurement and Modeling of the Temporal Dependence in Packet Loss,” Tech. Rep. UMASS CMPSCI 98-78, University of Massachusetts, Amherst, MA, 1998.