TCP congestion avoidance algorithm

From Wikipedia, the free encyclopedia

The TCP uses a network congestion avoidance algorithm that includes various aspects of an additive-increase-multiplicative-decrease (AIMD) scheme, with other schemes such as slow-start in order to achieve congestion avoidance.

Contents 1 TCP Tahoe and Reno 2 TCP Vegas 3 TCP New Reno 4 TCP Hybla 5 Other TCP congestion avoidance algorithms

[edit] TCP Tahoe and Reno

Two such variations are those offered by TCP Tahoe and Reno. TCP specifies a maximum segment size (MSS). The sender maintains a congestion window, limiting the total number of unacknowledged packets that may be in transit end-to-end.

Slow Start. To avoid congestion collapse, TCP makes a slow start when the connection is initialised and after a timeout. It starts with a window of 2 MSS. Although the initial rate is low, the rate of increase is very rapid: for every packet ACKed, the congestion window increases by 1 MSS so that for every round trip time, the congestion window has doubled. When the congestion window exceeds a threshold ssthresh, or a packet is lost, the algorithm enters a new state, called congestion avoidance. In some implementation (e.g. Linux), the initial ssthresh is large, and so the first slow start usually ends after a loss. However, ssthresh is updated at the end of each slow start, and will often affect subsequent slow starts triggered by timeouts.

Congestion Avoidance. As long a non-duplicate ACKs are received, the congestion window is additively increased by one MSS every round trip time. When a packet is lost, duplicate ACKs will be received. The behaviour of Tahoe and Reno differ in how they detect and react to packet loss:

• Tahoe: Loss is detected when a timeout expires before an ACK is received. Tahoe will then reduce congestion window to 1 MSS, and reset to slow-start state.
• Reno: If three duplicate ACKs are received (i.e., four ACKs acknowledging the same packet, which are not piggybacked on data, and do not change the receiver's advertised window), Reno will halve the congestion window, perform a "fast retransmit", and enter a phase called Fast Recovery. If an ACK times out, slow start is used as it is with Tahoe.

Fast Recovery. (Reno Only) In this state, TCP retransmits the missing packet that was signaled by 3 duplicate ACKs, and waits for an acknowledgment of the entire transmit window before returning to congestion avoidance. If there is no acknowledgment, TCP Reno experiences a timeout and enters the slow-start state.

Both algorithms reduce congestion window to 1 MSS on a timeout event.

[edit] TCP Vegas

Up until the mid 1990s, all TCPs set timeouts and measured round-trip delays were based upon only the last transmitted packet in the transmit buffer. With TCP Vegas, timeouts were set and round-trip delays were measured for every packet in the transmit buffer. In addition, TCP Vegas uses additive increases and additive decreases in the congestion window.

[edit] TCP New Reno

TCP New Reno improves retransmission during the fast recovery phase of TCP Reno. During fast recovery, for every duplicate ACK that is returned to TCP New Reno, a duplicate unacknowledged packet from the front of the transmit buffer is sent. In other words, several packets from the front of the transmit buffer may be retransmitted. For every ACK that makes progress in the sequence space, new unsent packets from the back of the transmit buffer are sent, to keep the halved congestion window full.

Because the timeout timer is reset whenever there is progress in the transmit buffer, this allows New Reno to fill large holes, or multiple holes, in the sequence space - much like TCP SACK. Because New Reno can send out new packets at the end of the transmit buffer during fast recovery, high throughput is maintained during the hole-filling process, even when there are multiple holes, of multiple packets each.

In fact, New Reno performs as well as SACK at low packet error rates, and substantially outperforms Reno at high error rates.

[edit] TCP Hybla

TCP Hybla aims to eliminate penalization of TCP connections that incorporate a high-latency terrestrial or satellite radio link, due to their longer round trip times. It stems from an analytical evaluation of the congestion window dynamics, which suggests the necessary modifications to remove the performance dependence on RTT. Read more at [1]

[edit] Other TCP congestion avoidance algorithms

• TCP Westwood
• TCP SACK
• H-TCP
• Scalable TCP
• HS-TCP
• BIC TCP
• FAST TCP
• XCP

To flesh out: TCP NewReno would be the most commonly implemented algorithm, SACK support is very common and is an extension to Reno/NewReno. Most others are competing proposals which still need evaluation. Version of Linux since 2.6.8 implement a version of BIC-TCP, and use it by default. When the per-flow product of bandwidth and latency increases, regardless of the queuing scheme, TCP becomes inefficient and prone to instability. This becomes increasingly important as the Internet evolves to incorporate very high-bandwidth optical links .A new approach to Internet congestion control that outperforms TCP in conventional environments, and remains efficient, fair, scalable, and stable as the bandwidth-delay product increases is proposed ‘eXplicit Control Protocol’ (XCP), it generalizes the Explicit Congestion Notification proposal (ECN). In addition to that, XCP introduces the new concept of decoupling utilization control from fairness control. This allows a more flexible and tractable protocol design and could be helpful for service differentiation. XCP is modeled based on control theory framework and demonstrates that it is stable and efficient regardless of the link capacity, the number of sources, and the round trip delay. Simulations show that XCP outperforms TCP in both conventional and high bandwidth-delay environments. XCP achieves fair bandwidth allocation, high utilization, small standing queue size, and near-zero packet drops, with both steady and highly varying traffic.

This may be true for some academic cases. But in wireless network scenarios (WLAN, UMTS), for example, XCP has a lot of problems to reach the current pipe capacity. Other new approaches, e.g. Fuzzy XCP or Enhanced TCP (ETCP), reach much better performance.