Electrical computers and digital processing systems: multicomput – Computer-to-computer data addressing
Reexamination Certificate
1998-10-30
2002-07-02
Harrell, Robert B. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data addressing
C370S401000
Reexamination Certificate
active
06415329
ABSTRACT:
BACKGROUND OF THE INVENTION
The Transmission Control Protocol/Internet Protocol (TCP/IP) suite that forms the basis of the Internet was designed and optimized to operate in a terrestrial environment. Despite this fact, TCP/IP will operate over an extremely large range of link conditions, albeit at reduced levels of performance when the assumptions inherent in its algorithms are violated. For instance, the high delay-bandwidth product and higher bit error rate of a satellite link results in a situation in which the satellite link is not efficiently utilized and the TCP/IP performance (as perceived by an interactive user) is poor.
The use of wireless links provides a very flexible way to extend networks where a wired infrastructure is not available or is not cost effective, but there are a number of important technical issues that need to be addressed. These issues revolve around the fact that most protocols are optimized to run on terrestrial networks. The primary differences between terrestrial and wireless connectivity are the link latency, the bit error rate (BER), and channel asymmetry. In a terrestrial system, error rate is typically low (<10
−10
) and the latency is short (<30 ms), while on a wireless link, the BER can range from 10
−10
to 10
−3
and, in some cases, the round trip latency can exceed 1.0 second. In addition, wireless links tend to be asymmetric with some systems having 100 times or more available capacity in one direction than the other.
In some scenarios, the physical characteristics of the wireless link are such that the assumptions about link quality and latency inherent in the TCP design are rendered invalid and poor performance results. In these cases, the poor performance may be attributed to a combination of TCP's automatic repeat request (ARQ) and flow control (FC) algorithms. The ARQ algorithm uses a combination of strategies that depends heavily on the TCP implementation used at each end of the connection. In some scenarios, especially if the receiving host does not buffer segments received out of order, an ARQ strategy that is not appropriate for a wireless link may result and, performance will be degraded due to unneeded retransmissions and/or inefficient use of the link.
The TCP FC algorithm also may contribute to poor performance on a wireless link. The existing FC algorithm does not differentiate between packets that are lost (due to congestion) and packets that are received in error (due to bit errors). On a terrestrial link the error rate is very low, so almost no packets are received in error. On a satellite link, however, the situation is the opposite, e.g., almost no packets are lost and many are received in error. The result is that TCP detects congestion where there is none and reacts by reducing the transmission rate to alleviate the congestion, causing the link utilization to shrink further. As with the ARQ algorithm, the exact effects are implementation dependent.
Another effect that can be attributed to the FC algorithm is the slow ramp up of data flow. Most Internet communication occurs on short duration virtual circuits. In other words, the virtual circuit is set up, a small amount of data is sent and received, and the virtual circuit is torn down. On a high delay bandwidth product channel, where delay bandwidth product is defined as the data rate of a channel multiplied by the round trip time of the channel, TCP's slow start algorithm initially takes a long time before it can fully utilize the bandwidth available on a virtual circuit. Slow start is intended to prevent a host from bursting data at the start of a TCP connection and works in the following manner.
TCP has a congestion window that is set to the length of one packet (or segment) at the start of a TCP connection. TCP is only allowed to send up to a congestion window's amount of unacknowledged data at a time. The rate of increase of this congestion window is such that for every segment that is acknowledged the congestion window grows by the length of one segment. Hence, the congestion window grows exponentially at the start of a connection. Note that in most implementations, acknowledgments are delayed and only every second segment is acknowledged, resulting in sub-exponential growth. The TCP connection is often finished before TCP's congestion window gets large enough to fully utilize the wireless link.
SUMMARY OF THE INVENTION
In accordance with the present invention, a method of communicating over a link which may be a high delay-bandwidth link, such as a satellite link, comprises receiving, at a source gateway, incoming packets directed to a destination address, in a first protocol, preferably transmission control protocol (TCP) over Internet protocol (IP), or TCP/IP. At the source gateway, the destination address is modified so that the packets are forwarded to a source gateway application, or protocol translator, in the first protocol. The original TCP connection is terminated at the source gateway, and acknowledgments are transmitted from the source gateway back to a source.
From the source gateway application, the packets are forwarded in a second protocol over the link to a destination gateway application. The destination address is communicated to the source gateway application, and then to the destination gateway application. In the destination gateway application, the destination address is used to determine where to send packets. Finally, the packets are forwarded from the destination gateway application to the destination address. Preferably, packets are forwarded from the destination gateway application to the destination address in the first protocol.
To maintain a low susceptibility to transmission errors, the packets may be transmitted or forwarded over the link by fragmenting the packets, in the source gateway application, into smaller packets. In the destination gateway application, the original packets are reconstructed from the smaller packets.
Preferably, in the second protocol, upon an automatic repeat request (ARQ) from the destination gateway application to the source gateway application, only packets which are incorrectly received by the destination gateway application are retransmitted from the source gateway application. The packets may therefore arrive at the destination gateway application in scrambled order, and are reordered in the destination gateway application into their original order. Incorrectly received packets are retransmitted K times where K depends on the BER. This ensures that the packets are correctly received within one round trip time.
Information from the source gateway application, comprising the destination address and a channel identifier, is transmitted to and stored at the destination gateway application. The channel identifier is appended to packets before their transmission over the high delay-bandwidth link, and the destination gateway application uses the received channel identifier to identify the stored information.
Preferably, forwarding a received packet to the source gateway application is done by replacing the destination address in the packet with an address of the source gateway application. The original destination address is restored at the destination gateway application.
To reduce acknowledgment traffic, acknowledgments preferably are sent over the high delay-bandwidth link only periodically. Only a list containing the first sequence number and the last sequence number of a series of contiguously received packets is sent back to the source gateway application.
Preferably, a source self-network address translator (SNAT) on the source gateway replaces the destination address of each incoming packet with the source gateway application's address. The SNAT forwards the original destination address to the source gateway application. The source and destination gateway applications communicate over the high delay-bandwidth link using a second protocol which ensures that the link is error-free and ordered. The destination address is communicated from the sour
Gelman Jay R.
Stadler J. Scott
Harrell Robert B.
Jaroenchonwanit Bunjob
Massachusetts Institute of Technology
LandOfFree
Method and apparatus for improving efficiency of TCP/IP... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for improving efficiency of TCP/IP..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for improving efficiency of TCP/IP... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2903204