TCP congestion control
lastmod 2025-11-12created 2025-11-121 edits
The Transmission Control Protocol (TCP) uses a network congestion-avoidance algorithm to reduce packet loss caused by load on the network. This page covers the TCP congestion-avoidance algorithms used in TCP.
TCP Tahoe & TCP Reno
To prevent congestive collapse caused by network congestion, TCP uses a variety of congestion control methods. TCP maintains a congestion window for each connection, and the congestion window limits the maximum number of packets for which no ACK packet has been received. This is similar to the way TCP uses a sliding window for flow control. When a connection starts and when a timeout occurs, TCP enters a state called slow start, beginning with a small value and gradually increasing the size of the congestion window. The initial congestion window size is twice the maximum segment size (MSS). Although it starts with a small value, the congestion window grows very quickly. Each time an ACK packet is received for a packet, the congestion window grows by one MSS. As a result, the congestion window effectively doubles every round-trip time (RTT).
When the congestion window size exceeds a threshold called the slow start threshold (ssthresh), TCP enters a new state called congestion avoidance. In some implementations, including Linux, the initial ssthresh value is large, so the first slow start usually ends only after packet loss occurs. However, once slow start ends, the ssthresh value is adjusted to a smaller value, which affects subsequent slow starts.
In the congestion avoidance state, TCP increases the congestion window by one MSS every round-trip time, as long as no duplicate ACK packets are received. When packet loss occurs, duplicate packets are very likely to be received. (In theory, extreme packet reordering can also cause duplicate ACKs.) Tahoe and Reno take different strategies for detecting and responding to packet loss.
- Tahoe
- When three duplicate ACKs are received, it treats them exactly as if a timeout had occurred. When a timeout occurs, Tahoe performs a "fast retransmit": it first sets the slow start threshold to half the current congestion window size, sets the congestion window size equal to the MSS, and then enters the slow start state again.
- Reno
- When three duplicate ACKs are received, Reno halves the congestion window, also sets the slow start threshold equal to the reduced congestion window size, then performs fast recovery and enters fast recovery. On an ACK timeout, it performs slow start in exactly the same way as Tahoe.
The fast retransmit state exists only in Tahoe. In this state, TCP retransmits the packet indicated by the duplicate ACKs and waits until ACKs are received for all packets in the transmit window. Only after all ACKs are received does TCP return to the congestion avoidance state. If the ACKs are not received, a timeout occurs and TCP will perform slow start.
On a timeout, both algorithms reduce the congestion window size to the MSS.
Both algorithms can occasionally get stuck in a frozen state when the congestion window size is set to 0.
TCP Vegas
Until the mid-1990s, all TCPs detected timeouts and measured round-trip times only through the last packet sent in the transmit buffer. Larry Peterson and Lawrence Brakmo of the University of Arizona introduced TCP Vegas, named after Las Vegas, the largest city in Nevada. In this algorithm, timeout detection and round-trip time measurement were done for every packet in the transmit buffer. TCP Vegas also uses additive increase for the congestion window. The algorithm was not widely implemented outside Peterson's lab. In a comparative study of various TCP congestion control algorithms, TCP Vegas, together with TCP CUBIC, showed the smoothest behavior.
TCP Vegas was used as the default congestion control algorithm in DD-WRT firmware v24 SP2.