Many computer networking technologies and protocols are well known. One of the most widely used protocols is the internet protocol (IP). IP is a connectionless, best-effort, unreliable, routable networking protocol. Applications that require reliable communications typically use the Transmission Control Protocol (TCP) on top of IP. The TCP protocol layer provides required functionality such as flow control, packet loss detection, lost packet retransmission, congestion avoidance, etc. (hereinafter referred to as upper-layer behaviors) that are needed to provide reliable communications over the unreliable IP networking substrate. This pair of networking protocols is common enough that they are often referred to jointly as TCP/IP. Detailed descriptions of TCP and IP are found in RFC 792 and RFC 793, which are herein incorporated by reference.
Research has developed a simple model that predicts the maximum performance of TCP implementations that use the standard congestion avoidance algorithm (TCP Reno and TCP Tahoe). One good explanation of this model and its derivation is in a paper by Matthew Mathis, Jeffrey Semke, and Jamashid Mahdavi, entitled “The Macroscopic Behavior of TCP Congestion Avoidance Algorithm”, herein incorporated by reference. Equation 3 of the paper provides a simple model of TCP performance:BW=(MSS*C)/(RTT*SQRT(P))
Where:
BW=Bandwidth for the TCP Connection
MSS=Maximum Segment Size, i.e., the size of the packets being transported
RTT=Round Trip Time
P=Percentage of packet loss in the network
C=A constant
One of the surprising results of this model is that maximum TCP performance is unrelated to network speed. Another surprising result is that maximum performance is inversely related to round trip time (RTT).
Other phenomena may limit performance below what the model provides as a maximum. For example, if the receiver does not advertise a window that is at least as large as the bandwidth delay product of the connection, then maximum TCP performance will be limited accordingly. Standard implementations of TCP are also known to perform poorly in certain environments and/or conditions. For example, the high rate of packet loss in typical wireless links results in poor TCP performance.
One method of correcting many of these problems is to modify the TCP implementation of one or both of the participants. However, this is frequently not a viable option such as when the source code is unavailable or when there are too many endpoints to conveniently manage.
Another method is to interpose another element in the TCP conversation. This element, called a Performance Enhancing Proxy (PEP), applies algorithms to manipulate the conversation so as to overcome the performance limitations. Many types of PEPs and PEP algorithms are known; the reader is directed to RFC 3135, herein incorporated by reference, for a detailed discussion of PEPs.
Deployment of PEPs in a network is known by providing a new network processing node and routing packets through it. This technique suffers from at least two disadvantages: firstly, the extra expense of the additional processing node and its associated administrative overhead; and secondly, the PEP often requires redundant processing due to the poor integration with the other nodes of the network.
Another method of deploying a PEP is to insert it into the software driver stack of a node. Many operating systems provide the ability to insert a software agent (shim) between the TCP/IP processing stack and the driver for the network interface card (NIC). There are many advantages to this method. One advantage is that no changes to the operating system are required, which, in any event, may be impossible since access to the source code is frequently limited. Even with access to the source code of an operating system, the operational issues associated with supplying and supporting customized versions of the operating system make this prohibitive in many environments.
It is desirable that the addition of PEPs (either in shim or stand-alone form), be done in such a way as to minimize changes required to other nodes of the network. In particular, no changes should be required to existing utilities and application programs. No changes to firewall settings, routing tables, or port assignments should be required. No retraining of users or network operations staff should be required. No re-installation of applications or utilities should be required. New software that is being developed should be able to take advantage of PEP capabilities without any change to the development process or to the software itself.
Ideally, existing network equipment and software, both on the Local Area Network (LAN) and the Wide Area Network (WAN), should not require any modification, aside from the addition of the invention.
The PEP itself should not require substantial system resources, such as random access memory or disk storage. Requiring large amounts of these resources not only increases system expense, but requires additional environment attention (more power, more space, etc.) and also reduces overall system reliability.
The communications protocols used by the PEP should adhere to the standard TCP/IP protocols as they currently appear on the network, minimizing any disruption to existing network software or equipment and ensuring compatibility with new equipment that is currently in development now or in the future by inventors not aware of the present invention. Some prior art techniques translate the TCP/IP protocol into other protocols (e.g., User Datagram Protocol (UDP)), causing disruption to network monitoring, traffic shaping, Quality of Service (QoS), Service Level Agreement (SLA), statistics measuring applications, and others; they also require modifications to firewall and security settings due to the usage of protocols that were not previously employed. Worse, applications environments and settings will require modification to direct traffic flows to explicitly designated transcoding network nodes.
Security techniques that are currently deployed should be preserved wherever possible. The ideal PEP should be fully functional in the presence of modern encryption and authentication techniques.
The PEP should operate incrementally, with a minimal increase in the latency of data transmission. It should not require access to multiple blocks of data before data transmission can begin. The latency of data transiting a PEP should be minimized.
The algorithms employed by a PEP should not be subject to any arbitrary limits. They should scale to any arbitrary speed and handle any type of connection media, including high-delay satellite links, high loss-rate wireless and power-line networking links, and others. The algorithms should function properly in the presence of standard traffic management techniques. Plus, it should smoothly operate with any existing Quality of Service (QoS) or service level agreement (SLA) architecture that might be deployed, allowing these systems to limit the performance of the original endpoint, just as though the PEP were not present.
TCP connection characteristics can be measured along multiple dimensions. A partial list of the dimensions includes: RTT, connection bandwidth, aggregate loss rate, connection lifetime, application burstiness, and others. Across all of these dimensions, no algorithm can be optimal. A PEP should monitor the connection, characterizing it as conditions change, adapting the PEP algorithms accordingly.
One example of prior art is the Transporter Fountain from Digital Fountain Corporation of Fremont, Calif. The product is intended to transfer files across large RTT links without the performance limits that standard File Transfer Protocol-based (FTP) techniques suffer from. (FTP uses TCP/IP which has the performance limit described above.) This product consists of a “box” that the user connects to his network. The user must explicitly copy the files to be transferred to the box before the files can be transferred. Thus, all applications programs and scripts that wish to utilize the product must be changed to utilize the new box with its proprietary command set. Further, the transfer protocols used by the product are UDP based, requiring the modification of network settings, such as security, QoS, SLA, traffic management, and others. The transcoding from FTP to UDP interferes with any network element that might attempt to process the individual TCP connection, such as QoS, SLA or traffic management.
Another example of prior art is the Sequence Reducer from Peribit Corporation of Santa Clara, Calif. This product provides data compression using advanced data sequence recognition techniques developed for the Human Genome project. However, general-purpose lossless data compression is typically limited to a two- to three-times reduction in data, placing an upper limit on the total performance improvement that can be provided by this technique. Further, many data types are already compressed, wasting system resources attempting any further compression for these data types. The computational expense of this method requires the addition of an extra box to the network and limits the speed at which packets can be processed. Current CPU technology seems to limit processing speeds to about 45 Mb/sec (T3) for any one connection. Current data link speeds are well in excess of this limit and growing at a faster rate than CPU performance is growing. The product does not address the fundamental limits of the TCP/IP protocol and is thereby permanently limited to a maximum of two- to three-times performance improvement over offerings without the PEP.
Consequently, a new method of deploying of PEPs is required to efficiently integrate them into a network. These PEPs must supply algorithms that remove the performance limitations inherent in TCP implementations.