RTC Magazine

The Transmission Control Protocol (TCP), a transport layer protocol, was originally designed for low-speed terrestrial links. However, with the proliferation of high-speed transmission mediums, as well as sophisticated access mechanisms, extensive computing power and memory are required for software-only TCP implementations.

In recent years, there has been an explosion in the speed of networks, CPUs and memories. Since the speed of Ethernet has increased much more rapidly than that of CPUs or memories, the performance of today’s networks continues to be limited mainly by memory and CPU speeds.

One method for overcoming these limitations and accelerating a TCP/IP connection is TCP offloading. TCP processing complexity is offloaded from the host CPU to specialized TCP accelerators. Usually, the accelerating TCP offload engine (TOE) is a dedicated subsystem co-located with the host CPU. However, an alternative, more scaleable approach to achieving the same end, which also works with legacy equipment, is to move the complicated TCP/IP processing to a network processor (NP). This is a special-purpose programmable hardware device, which is connected to the TCP server over a high-speed link.

The NP-based TOE combines the low cost and flexibility of a general-purpose processor with the speed and scalability of custom silicon solutions. Furthermore, the NP offloads both memory-intensive and CPU-intensive processing from the TCP server. In the NP-based TOE mechanism described here, TCP splicing is used to enhance TCP performance.

An Alternative TCP Offload Approach

For low-end enterprise products limited by cost and size, addressing the memory/CPU bottleneck by introducing a remotely located TOE on a central networking element is a scaleable and cost-effective solution. This is especially true when contrasted with the solution of increasing the capability of the host itself, such as via keyboard, video and mouse (KVM) switches.

In one sample deployment scenario (Figure 1), a remote keyboard, monitor and mouse control multiple, remotely managed servers connected to a KVM-over-IP switch. The mouse and keyboard events from remote controlling computers are transmitted over the Internet via the KVM switch to the server. Compressed monitor data is sent to the remote computer by the server via a KVM switch. The KVM switch offloads TCP processing to the NP-based TOE, simplifying KVM switch hardware.

TCP Offloading Using TCP Splicing

TCP offloading can be performed across two network entities, an enterprise TCP host and a remote NP. This is achieved by using a split TCP connection, also known as TCP splicing, a well-known technique for enhancing TCP performance. In TCP splicing, two independent TCP connections span a session: one from the client to the NP, and the second from the NP to the server.

Data from the server is locally acknowledged by the NP, thereby reducing server buffering requirements and speeding up congestion window growth (Figure 2). The NP buffers the data until the acknowledgment (ACK) from the far end (client) arrives. In the absence of an acknowledgment, the NP performs timer management to retransmit TCP segments toward the far end. The usage of local acknowledgments also shields the TCP server from any network congestion and excessive delays between the NP and the client. This reduces the memory burden at the server.

The NP also performs optional network address translation (NAT) for data from the server to the client involving checksum computations. Although this functionality is computationally intensive and heavily loads a general-purpose processor, an NP is well suited for such operations.

In contrast to traditional NP applications such as routing, the TCP offload application requires inter-packet dependency and connection-based state machines. Furthermore, this application deals with transport layer functionality, which is beyond traditional NP link- and network-layer processing.

There are two fundamental complexities in TCP processing. Buffer management consists of storing unacknowledged segments, out-of-order segments and stalled segments in congested networks. Timer management involves Retransmission Timeout (RTO) estimation and triggering retransmission of unacknowledged segments. Both of these are offloaded to the NP.