|Publication number||US20080043621 A1|
|Application number||US 11/923,732|
|Publication date||Feb 21, 2008|
|Filing date||Oct 25, 2007|
|Priority date||Jan 8, 2004|
|Also published as||US7310682, US20050165948|
|Publication number||11923732, 923732, US 2008/0043621 A1, US 2008/043621 A1, US 20080043621 A1, US 20080043621A1, US 2008043621 A1, US 2008043621A1, US-A1-20080043621, US-A1-2008043621, US2008/0043621A1, US2008/043621A1, US20080043621 A1, US20080043621A1, US2008043621 A1, US2008043621A1|
|Original Assignee||Hicham Hatime|
|Export Citation||BiBTeX, EndNote, RefMan|
|Referenced by (14), Classifications (22), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present application relates to computer/communication networking and in particular relates to improved methods for detecting and avoiding network congestion and for reducing retransmission latencies in packetized protocols applied to network communications.
2. Discussion of Related Art
Many present day communication networks exchange packets of information between nodes coupled to a common communication medium. The nodes may be, for example, computing devices, storage devices for storing information, or other communication or network appliances for generating, receiving, storing, forwarding or routing the packets of information. The communication medium may be widely distributed as in a so-called wide area network (“WAN”) or localized within an enterprise as in a so-called local are network (“LAN”). The information be exchanged between nodes is generally subdivided into one or more packets. Each packet may include some subset of the total information to be exchanged between nodes over the network. Packets may be fixed or variable in size in accordance with the particular protocols and communication media employed. Further, each packet may represent a unit of information to be verified and acknowledged between the nodes in accordance with the particular protocols and media employed.
For example, in TCP/IP protocols applied to Ethernet communication media, information is subdivided into one or more packets of variable sizes less than a pre-determined maximum size. Packets are initially transmitted in a sequential order corresponding to the order of the information to be exchanged. Individual packets are each identified by a sequence ID field to indicate their proper order relative to one another. The receiving node(s) may then reassemble the received packets into the originally transmitted information.
In TCP/IP networks and other packetized networks, packets may be lost in transmission for various reasons. For example, a noisy communication medium (one having a low signal to noise ratio) may cause errors in the transmitted packets. Another reason for packet loss is congestion on the communication medium. Ethernet and other communication media allow devices to communicate over multiple segments of communication links through one or more intermediate nodes or devices. Where the multiple links vary in speed or where the intermediate device(s) are of variable processing capability, a sequence of packets transmitted from a sender to a receiver may cause congestions. Packets moving from a faster network segment or node to a slower segment may over-run the available bandwidth of the slower link or node. If the intermediate node detects such congestion it may discard received packets from its internal queues. Such congestion may be more common where multiple transmitters attempt to forward packets through a common segment or node. However, even a single node may generate and transmit packets so quickly that it may, alone, utilize all available bandwidth. Such saturation of the communication medium can cause packet loss if the receiving intermediate node(s) or segment(s) cannot process the received packets quickly enough.
When packets are lost, TCP/IP and other common protocols may cause retransmission of packets that were lost and all subsequent packets from that point forward (in the sequence of transmitted packets). Such retransmissions are costly in terms of elapsed time to complete the desired transmission and in terms of bandwidth utilization since information (packets) previously transmitted must be transmitted again. In some presently known protocols (such as the so-called Reno version of TCP/IP), the sender determines that a packet has been missed by the receiving node when the sending node receive three consecutive acknowledgement messages (i.e., TCP/IP ACK messages) each indicating a duplicate sequence ID value.
To avoid such costly packet loss and the associated retransmissions, present TCP/IP (and other) protocols use techniques to attempt to estimate the available bandwidth on the communication medium and then to use the estimated available bandwidth to limit the transmitting node in hopes of thereby avoiding congestion and the resulting packet loss and performance degradation. Presently known techniques, such as those practiced in the present-day Reno version of the TCP/IP protocols (“Reno TCP/IP”), attempt to avoid congestion by predicting the available bandwidth of the communication medium and then limiting the transmitting node to a fixed percentage thereof RFC2581 provides specifications for the TCP/IP protocol for presently known techniques to reduce congestion packet loss and the associated packet retransmission. RFC2581 and other related TCP/IP specifications are readily available to those of ordinary skill in the art and may be found, for example, at http://www.rfc-editor.org/rfc.html. However, these presently practiced techniques predict the available bandwidth using essentially static information regarding the communication medium at a fixed point in time. Further, present techniques, such as those in Reno TCP/IP, often intentionally generate packet loss conditions in order to determine the available bandwidth on the communication medium.
It is therefore an ongoing challenge to detect and avoid congestion on a communication network. It is a further ongoing challenge to reduce the time required to detect a lost packet and to retransmit any necessary packets in response to such detection.
The present invention solves the above and other problems, thereby advancing the state of the useful arts, by providing improved methods and structures for detecting and avoiding network congestion and for detecting and retransmitting lost packets when required. In one aspect hereof, the available bandwidth is estimated dynamically by features hereof that continually learn the available bandwidth of the network medium based on mathematical analysis of one or more past responses from the receiving node(s). Another aspect hereof uses a curve fitting mathematical analysis of prior responses from the receiving node to permit interpolation/extrapolation techniques to predict an estimated future response. Still other aspects hereof improve the speed of detecting loss of a packet by improving the accuracy of round-trip time (“RTT”) estimates. The RTT is estimated based on measurements of the actual time to respond from previous acknowledged packet transmissions.
A feature hereof therefore provides a method of reducing network congestion comprising the steps of: transmitting multiple packets from a sending node to a receiving node over a network communication medium at a rate no faster than a predetermined maximum packet transmission rate value; receiving multiple acknowledgements at the sending node from the receiving node; measuring a transmission performance value based on transmission of a packet of the multiple packets and a corresponding acknowledgement of the multiple acknowledgements; predicting an available bandwidth value based on at least two transmission performance values; and adjusting the predetermined maximum packet transmission rate based on the predicted available bandwidth to reduce network congestion on the network communication medium.
Another feature hereof provides a method for reducing re-transmission delays in a packetized network protocol comprising: measuring a time between a successful packet transmission and receipt of a corresponding acknowledgement; using the measured time as a timeout value for a subsequent packet transmission; detecting expiration of the timeout value following the transmission of the subsequent packet; and retransmitting the subsequent packet in response to detecting expiration of the timeout value.
Another feature hereof provides a system comprising: a packet network communication medium; a first network appliance communicatively coupled to the medium; and one or more other network appliances communicatively coupled to the first networl appliance via the medium, such that the first network appliance further comprises: a predictive tuning element to dynamically predictively adapt protocol parameters of the first network appliance based on present and past measurements of throughput on the medium.
Network appliance 100 includes packet transmitter element 106 and packet receiver element 108 for transmitting and receiving packets, respectively, via media 150. Packet processing element 110 generates packets to be transmitted via packet transmitter 106 and reconstructs buffers of data from received packets received via packet receiver element 108.
In accordance with features and aspects hereof, network appliance 100 may also include dynamic congestion avoidance element 102 and dynamic retransmission tuning element 104 to improve network communications capabilities of network appliance 100 (collectively or individually also referred to herein as a predictive tuning element 101). Dynamic retransmission tuning element 104 is generally operable to adjust parameters of the packet transmission protocol to reduce latencies associated with retransmission of a failed or lost packet. Dynamic congestion avoidance element 102 also tunes parameters of the packet protocol to reduce the possibility of congestion generated by network appliance 100 on the communication medium 150. By reducing the possibility of such congestion on the communication medium 150, enhanced network appliance 100 improves overall system performance by reducing the number of occurrences of lost packets and associated, time consuming, packet retransmissions. In addition, by dynamically tuning the retransmission related protocol parameters, latencies associated with the occasional need for retransmission may be reduced thereby further improving overall system performance.
Upon receipt of the corresponding ACK message, element 203 is operable to estimate the next RTT value based on the elapsed time between the packet transmission and the corresponding ACK receipt. The next RTT value may be predicted as a function of the current throughput value (computed from the measured time interval) and previous measured values. As discussed further herein below, a cubic spline function may be used such that the next RTT value may be extrapolated from the current RTT estimated value and one or more past measured values. Using the predicted next RTT value so determined, element 204 next sets RTT to the predicted next value. The method of
While prior techniques used a coarse timer value to conservatively overestimate the round trip time of packet exchange, features and aspects hereof more accurately estimate RTT based on current and past actual measurements of elapsed times between packet transmission and receipt of a corresponding ACID message. Such dynamically adjust RTT values using improved accuracy in the estimation of the actual throughput enhances the time required for detection of the need to retransmit a packet.
If the acknowledgement message is not a duplicate ACK, processing continues looping back to the element 304 to await receipt of another acknowledgement message. If element 310 determines that the received ACK is a duplicate ACK, indicating likely loss of a transmitted packet, element 312 is then operable to commence retransmission processing.
By comparison with presently practiced retransmission techniques, features and aspects hereof reduce the delay in determining that a retransmission must occur. Where prior techniques (as documented in, for example, RFC2581) awaited receipt of three duplicate ACK messages, features and aspects hereof my detect the need to transmit by waiting for two duplicate ACK messages and the expiration of the RTT timeout period. Since the RTT timeout period is dynamically adjusted by features and aspects hereof, the timeout may be tuned to an optimal or near optimal value. Thus, features and aspects hereof may notably reduce the time required to detect the need for a retransmission of a previously sent packet.
In particular, during enhanced congestion avoidance operation mode initiated by element 404, elements 406 and 408 are operable to detect bandwidth changes from performance measurements made during normal packet transmission to the network medium and to dynamically adjust cwnd in accordance with those measured parameters. Element 410 then determines whether congestion has been detected on the network as reflected by a lost packet and the need for a corresponding packet retransmission. If no such congestion and corresponding retransmission is detected, processing continues in the enhanced congestion avoidance mode of operation. Elements 406 and 408 continue to dynamically measure network performance and adjust congestion detection related parameters of the TCP/IP transmitter. If congestion is detected by element 410 as reflected in packet loss and corresponding retransmission, processing continues by looping back to element 402 to reinitialize the TCP/IP transmitter of the enhanced appliance and to restart transmission using the “slow stall” mode of operation specified by TCP/IP protocol standards.
In view of the improved accuracy in estimating the available bandwidth for transmission throughput, the method of
Where S is the packet size and t1 and t2 are the absolute times of arrival of two acknowledgement messages: t1 corresponding to the arrival of the ACK for the first packet and t2 corresponding to the arrival of the ACK for the second packet.
Alternatively, bandwidth may be measured by counting the number of packets of equal size transmitted before receiving an acknowledgement for a first of a sequence of such packets.
Having so computed the Bbln from the time difference between arrival of two acknowledgement messages or from the count of the number of packets sent before receiving an acknowledgement for a particular transmitted packet, the future performance of the communication medium may be extrapolated from this current performance measurement and past measurements. The next cwnd parameter value may then be computed as the previous value plus or minus any incremental value. The incremental value may be determined as the minimum of a value computed from the predicted next throughput value and a value determined by exponential or linear increases dictated by the slow start standard congestion avoidance techniques. More specifically, the cwnd may be dynamically, periodically adjusted as:
next_cwnd=prev_cwnd+min((predicted_throughput−previous_throughput)/segment_size), (exponential or linear increase depending on proximity to ssthresh))
In other words, if the current throughput is near the ssthresh TPC/IP parameter value (slow start threshold), then the congestion window (cwnd TCP/IP parameter value) is adjusted by the lesser of the next predicted throughput value and the linear increase value as normally utilized in slow start processing. If the current throughput is far from ssthresh, then cwnd is adjusted by the lesser of the next predicted throughput value and the exponential increase value as normally utilized in congestion avoidance processing. This aspect hereof-helps adjust the congestion window (cwnd) to adapt to the actual, present throughput while adjusting more rapidly or more slowly to adhere to present TCP/IP slow start processing standards. As noted above, the RTT TCP/IP parameter could be similarly adapted based on current and previous throughput measurements and extrapolated values.
The cubic spline extrapolation is based on fitting a cubic function curve through all the points of a given set. Given a function Yi=f(Xi), i=1 . . . N, and given an interval [Xi, Mi+1], the cubic function is given by the formula:
C=⅙(A 3 −A)(Xi+1−Xi)2
D=⅙(B 3 −B)(Xi+1−Xi)2
And the second derivatives Y′ of the curve are given by:
after deriving the value of the function, it can be used to determine the value of any point within or outside the interval.
Element 512 is then operable to adjust the TCP/IP transmitter's cwnd parameter based on the predicted next performance measurement. Processing then continues looping back to element 500 to await a next packet transmission. The method of
By so periodically measuring and adjusting performance related values of the TCP/IP transmitter, the sending node may reduce potential for congestion on the network medium and thereby improve overall system performance by reducing potential for packet loss and associated retransmission.
Those of ordinary skill in the art will readily recognize numerous functionally equivalent techniques for providing the desired dynamic adjustment to packet protocol transmission parameters to reduce potential for packet loss due to congestion and to reduce the latencies associated with packet retransmission when required. The particular exemplary methods and functions depicted herein may be implemented as one or more threads in a multithreaded or event driven programming paradigm. Such design choices are well known to those of ordinary skill in the art. Further, the methods and features and aspects described herein may be implemented in suitably programmed instructions for programmable devices as well as customized application specific integrated circuitry. Equivalency of such hardware, firmware and software designs and the performance and cost related tradeoffs associated with each represent well known design choices to those of ordinary skill in the art.
While the invention has been illustrated and described in the drawings and foregoing description, such illustration and description is to be considered as exemplary and not restrictive in character. One embodiment of the invention and minor variants thereof have been shown and described. Protection is desired for all changes and modifications that come within the spirit of the invention. Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention. In particular, those of ordinary skill in the art will readily recognize that features and aspects hereof may be implemented equivalently in electronic circuits or as suitably programmed instructions of a general or special purpose processor. Such equivalency of circuit and programming designs is well known to those skilled in the art as a matter of design choice. As a result, the invention is not limited to the specific examples and illustrations discussed above, but only by the following claims and their equivalents.
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8004985 *||Feb 1, 2008||Aug 23, 2011||Nec Corporation||Communication terminal which perform low-delay communication by using a broadband line|
|US8190891 *||Sep 6, 2006||May 29, 2012||Kabushiki Kaisha Toshiba||Receiver, transmitter and communication control program|
|US8356327 *||Apr 21, 2005||Jan 15, 2013||Sharp Laboratories Of America, Inc.||Wireless video transmission system|
|US8976665||Jul 1, 2013||Mar 10, 2015||Centurylink Intellectual Property Llc||System and method for re-routing calls|
|US9042370||Nov 6, 2013||May 26, 2015||Centurylink Intellectual Property Llc||System and method for establishing calls over a call path having best path metrics|
|US9054915||Jul 16, 2013||Jun 9, 2015||Centurylink Intellectual Property Llc||System and method for adjusting CODEC speed in a transmission path during call set-up due to reduced transmission performance|
|US9054986||Nov 8, 2013||Jun 9, 2015||Centurylink Intellectual Property Llc||System and method for enabling communications over a number of packet networks|
|US9094257||Aug 9, 2012||Jul 28, 2015||Centurylink Intellectual Property Llc||System and method for selecting a content delivery network|
|US9094261||Aug 8, 2013||Jul 28, 2015||Centurylink Intellectual Property Llc||System and method for establishing a call being received by a trunk on a packet network|
|US20050071876 *||Sep 30, 2003||Mar 31, 2005||Van Beek Petrus J. L.||Wireless video transmission system|
|US20080192935 *||Sep 6, 2006||Aug 14, 2008||Kabushiki Kaisha Toshiba||Receiver, Transmitter and Communication Control Program|
|US20090213744 *||Feb 19, 2009||Aug 27, 2009||Phoenix Contact Gmbh & Co. Kg||Self-testing communications device|
|US20120320784 *||Dec 20, 2012||Embarq Holdings Company, Llc||System and method for generating a graphical user interface representative of network performance|
|US20140304425 *||Apr 6, 2013||Oct 9, 2014||Citrix Systems, Inc.||Systems and methods for tcp westwood hybrid approach|
|International Classification||G06F15/16, H04L29/06, H04L12/56|
|Cooperative Classification||H04L69/16, H04L69/163, H04L47/283, H04L47/12, H04L47/193, H04L47/37, H04L47/10, H04L47/25, H04L47/11|
|European Classification||H04L29/06J7, H04L47/10, H04L47/11, H04L47/19A, H04L47/25, H04L47/12, H04L47/28A, H04L47/37, H04L29/06J|
|Oct 25, 2007||AS||Assignment|
Owner name: LSI CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HATIME, HICHAM;REEL/FRAME:020012/0794
Effective date: 20040107
|Feb 19, 2008||AS||Assignment|
Owner name: LSI CORPORATION,CALIFORNIA
Free format text: MERGER;ASSIGNOR:LSI SUBSIDIARY CORP.;REEL/FRAME:020548/0977
Effective date: 20070404