The initial development of transmission control protocol (TCP) was based on networking and processing capabilities that were then currently available. As a result, various fundamental assumptions regarding its operation were prefaced on networking and processor technologies that existed at that time. The scarcity and high cost of network bandwidth and the partially limitless processing resources available from a host processor were among the various assumptions on which TCP was prefaced. With the advent of faster network technologies such as Gigabit Ethernet (GbE), the fundamental assumptions on which TCP was prefaced have changed radically. Network bandwidth is no longer as scarce and as expensive as it once was while host processing resources are now regarded as being limited when once they were plentiful. In this regard, the original constraints have shifted from limitations in network bandwidth to bottlenecks between host processor and host memory.
Host processing systems are not only responsible for providing faster network connections but must also execute system applications. Shifting more of the host processing resources to provide faster network connections will do little to address the fundamental change in assumptions. Notably, using a larger portion of host processing resources to execute TCP applications would occur at the expense of executing system applications, thereby resulting in an overall degradation in system performance rather than in the desired improvement in network connectivity.
Although new networking architectures and protocols may be created to address the fundamental shift in assumptions, these new architectures and protocols may still have to provide support for an extensive network of current and legacy systems. These new solutions may be required to address the shift in assumptions and, in doing so, alleviate any bottlenecks that may now result by the demands being placed on host processing systems.
A transmission control protocol/internet protocol (TCP/IP) offload engine may be utilized in a network interface card (NIC) to redistribute TCP processing from the host onto specialized processors for handling TCP processing more efficiently. The TCP offload engines may have specialized architectures and suitable software or firmware that allows them to efficiently implement various TCP algorithms for handling faster network connections, thereby allowing host processing resources to be allocated or reallocated to system application processing.
In order to alleviate the consumption of host resources by networking applications, a TCP connection can be offloaded from a host to a dedicated TCP/IP offload engine (TOE) in a NIC. Some of the host resources released by offloading may include CPU cycles and subsystem memory bandwidth, for example. During the offload process, TCP connection state information may be offloaded from the host, for example, from a host software stack, to the TOE. A TCP connection may be in any one of a plurality of states at a given time. To process the TCP connection, TCP software applications may be adapted to manage various TCP defined states. Being able to manage the various TCP defined states may require a high level of architectural complexity in the TOE.
In some instances, offloading information on all TCP defined states to the TOE may not be necessary because many of the TCP states such as CLOSING, LAST_ACK and FIN_WAIT_2 may not be performance sensitive. Furthermore, many of these non-performance sensitive states may consume substantial processing resources to handle error conditions and potentially malicious attacks, for example. These are but some of the factors that may substantially increase the cost of building and designing the TOE. In addition, a TOE that has control, transferred from the host, of all the state variables of a TCP connection may be quite complex. Such complexity may require the use of considerable processing power and may also require and/or consume a lot of TOE onboard-memory. Moreover, the TCP connection offloaded to the TOE that has control, transferred from the host, of all the state variables of the TCP connection may be inflexible and susceptible to connection loss.
When a host system offloads TCP transmission support to a TOE, the TOE must also have a mechanism in place to handle any network requests for retransmission. For example, retransmission may occur from a timer expiration mechanism or from a fast retransmit mechanism generated by the TCP transmission applications in the TOE. Timer expiration may occur when an acknowledgement is not received from a remote peer that a packet has been received within a certain amount of time from transmission. Fast retransmission may occur when the TOE may deduce or determine that a packet has not been received from the acknowledgement of other packets transmitted. In this regard, acknowledgement may be provided on a packet-by-packet basis or on a byte-by-byte basis.
A copy of the packets and/or bytes to be transmitted may be kept in the NIC in order to provide direct access to the data for transmission and retransmission operations. Supporting retransmission, however, may require more hardware storage capacity than the NIC may be able to support. In this regard, the limited storage capacity of the NIC may result in a slowdown in transmission, which is the problem that the offloading of TCP operations was intended to address.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.