of line ca- pacity requires about 1 Hz of CPU horsepower to run TCP in software. In other words, a 1 Gbps link will completely consume a 1 GHz CPU, leaving no cycles for doing actual application work besides TCP. Even if we accept the Adaptec estimate, this obviously leaves very little headroom in the CPU for other meaningful application processing. Therefore, storage devices equipped with classical microprocessors cannot be expected to handle SNP chores sustained at multiple gigabits-per-second speeds. This problem can be resolved in two ways: by replacing TCP with a more modern efficient and leaner-and-meaner protocol (an almost impossible prospect, which realistically should not be expected any time soon given the complete domination of the global market by TCP/IP) or by offload- ing TCP processing on an accelerator that will minimize the necessary intervention of the host CPU. Figure 11.4 illustrates the principle of TCP termination or TOE. TCP offloading requires specific functionality. First, consider the sophisticated flow control and error recovery services that TCP offers. These require a significant amount of protocol stack, or pro- tocol message processing, including the following: Copying TCP segments in and out of system buffers. Reassembling of IP datagrams that have been fragmented. Calculating TCP checksums across each data segment/packet. Processing acknowledgements on incoming and outgoing traffic. Detecting all packets that get lost or arrive out of order while trimming overlapping segments. Enabling/disabling retransmission timers and generating and processing retransmissions, if necessary. Updating congestion windows and slow start thresholds.. Keeping all data transmission within the corresponding permissible windows. TCP protocol-based sessions require access to memory where all the session-related data is stored. TCP, for example, requires easy access to station IDs and port numbers for each session. This data must be accessed every single time a session sends or transmits something. The r