Tuesday, October 31, 2006

Paper: "Connection Handoff Policies for TCP Offload Network Interfaces"

Connection Handoff Policies for TCP Offload Network Interfaces
Hyong-youb Kim and Scott Rixner, Rice University

Abstract

This paper presents three policies for effectively utilizing TCP offload network interfaces that support connection handoff. These policies allow connection handoff to reduce the computation and memory bandwidth requirements for packet processing on the host processor without causing the resource constraints on the network interface to limit overall system performance. First, prioritizing packet processing on the network interface ensures that its TCP processing does not harm performance of the connections on the host operating system. Second, dynamically adapting the number of connections on the network interface to the current load avoids overloading the network interface. Third, the operating system can predict connection lifetimes to select long-lived connections for handoff to better utilize the network interface. The use of the first two policies improves web server throughput by 12-31% over the baseline throughput achieved without offload. The third policy helps improve performance when the network interface can only handle a small number of connections at a time. Furthermore, by using a faster offload processor, offloading can improve server throughput by 33-72%.

2 Comments:

Blogger Leonid Ryzhyk said...

Talk summary
============

Speaker: Hyong-youb Kim

The talk focused on efficient utilisation of TCP offload capabilities available in some modern NIC's. While smart network processors can potentially improve the performance of network-intensive applications by taking over some of the TCP processing load, it turns out that if used without care this feature can easily saturate the NIC and degrade the overall system performance.

Three techniques for optimising connection handoff policy were proposed.
1. Prioritise packet processing on the NIC by giving packets handled by the host processor higher priority over packets processed by the NIC.
2. Dynamically adapt the number of TCP connections handled by the NIC based on the length of packet queues.
3. Compensate for the handoff cost by offloading long-lived connections to the NIC.

The proposed techniques were evaluated using a system simulator modeling the NIC as a MIPS processor with 32MB of RAM.

Q&A
===

Q: If there is a sudden change in number of received packets, would there be a lot of overhead in switching? For example, if someone wants to DoS by starting to send lots of long packets and then stopping.
A: The NIC currently does not put connections back to the host, so there's no overhead involved in reducing the number of connections. If the host wants to hand a connection to the NIC it has to transfer a small buffer, but it's cheap.

Q: You simulate the NIC as a single general-purpose processor, however actual network processors are more complex and have multiple specialised cores. Are your results representative of what would be observed on real hardware?
A: I believe that network processors should not be multicore.

3:57 PM  
Blogger Leonid Ryzhyk said...

Talk summary
============

Speaker: Hyong-youb Kim

The talk focused on efficient utilisation of TCP offload capabilities available in some modern NIC's. While offload-capable NICs can potentially improve the performance of network-intensive applications by taking over some of the TCP processing load, it turns out that if used without care this feature can easily saturate the NIC and degrade the overall system performance.

Three techniques for optimising connection handoff policy were proposed.
1. Prioritise packet processing on the NIC by giving packets handled by the host processor higher priority over packets processed by the NIC.
2. Dynamically adapt the number of TCP connections handled by the NIC based on the length of packet queues.
3. Compensate for the handoff cost by offloading long-lived connections to the NIC.

The proposed techniques were evaluated using a system simulator modeling the NIC as a MIPS processor with 32MB of RAM.

Q&A
===

Q: If there is a sudden change in number of received packets, would there be a lot of overhead in switching? For example, if someone wants to DoS by starting to send lots of long packets and then stopping.
A: The NIC currently does not put connections back to the host, so there's no overhead involved in reducing the number of connections. If the host wants to hand a connection to the NIC it has to transfer a small buffer, but it's cheap.

Q: You simulate the NIC as a single general-purpose processor, however actual network processors are more complex and have multiple specialised cores. Are your results representative of what would be observed on real hardware?
A: Network processors are not good at handing NIC workloads, so they should not be used for NICs. Network processors are built for switching packets. NIC workloads are different, and network processors do not work well.

3:15 PM  

Post a Comment

<< Home