Shortcuts

TCP Congestion Control Algorithms Comparison

Comparison of the most popular CCAa (congestion control/avoidance algorithms)
2020-08-26 (updated: 2023-07-13) by Philip

TCP congestion control and avoidance algorithms (CCAs) are an important connection tuning consideration, especially with high bandwidth/high latency broadband networks. Below is a list of the most commonly used algorithms that all aim to improve the traditional TCP congestion control algorithm as defined in RFC 2581. The algorithms have continued to evolve over the years, and are listed in below in loose chronological order, with their advantages and shortcomings. Current recommendations are in the last section of the article.

There are generally three types of CCAs based on how they detect network congestion to control the congestion window (cwnd) buffer:

loss-based - algorithms respond to packet loss to determine congestion and change the buffer. Most CCAs use this metric, including TCP Reno, New-Reno and CUBIC.
delay-based - algorithms like TCP Vegas that use variations of latency (RTT) to determine congestion and change the buffer size.
model-based - modern algorithms like BBR use combination of factors to determine congestion, they are both rate-based and delay-based, introduce packet pacing, etc. BBRv2 also uses packet loss for the model, BBRv1 does not.

TCP Reno (1986)

Traditional TCP congestion control used by older OSes. Reno uses slow start, congestion avoidance, and fast retransmit triggered by triple duplicate ACKs. Reno uses packet loss to detect network congestion. It cannot distinguish between random errors and congestion loss, so it can overreact to random packet loss. Similar to TCP Tahoe algorithm of the same era.

TCP Vegas (1994)

Emphasizes packet delay, rather than packet loss, as a signal to determine the rate at which to send packets. Unlike TCP-Reno which detects congestion only after it has happened via packet drops, TCP-Vegas detects congestion based on increasing RTT values of the packets in the connection, detecting congestion in the network before packet loss occurs.

TCP Vegas tends to limit throughput with very small RTT values, and overruns the connection in large RTT values. TCP Vegas does not co-exist well with other congestion control algorithms because it is the fastest to detect congestion and throttle the connection, before other algorithms that use packet loss as the main indication.

TCP New-Reno (1999)

[RFC 6582], obsoletes [RFC 3782]

New-Reno improves retransmissions compared to TCP Reno during fast recovery. New-Reno is able to detect multiple lost packets. The only problem with this algorithm mistakes some TCP reordering by more than 3 sequence numbers.

SACK (Selective Acknowledgements) is an extension to TCP Reno and New-Reno that helps with detection of multiple lost packets, and retransmission of more than one lost packet per RTT. SACK TCP acknowledges segments selectively, rather than cumulatively.

TCP Westwood (TCPW, 2001)

Westwood is a modification of TCP Reno optimized for lossy networks. It works well with wireless networks, the improvement is most significant in wireless networks with lossy links. TCPW is also not very sensitive to random packet loss, while TCP Reno is equally sensitive to random loss and congestion loss and cannot discriminate between them.

The key innovative idea in TCP Westwood is to measure the bandwidth used by the connection via monitoring the rate of returning ACKs at the sender side. This allows for faster recovery of the connection than TCP Reno. The TCP Westwood mechanism is particularly effective over wireless links where sporadic losses due to radio channel problems are often misinterpreted as a symptom of congestion by other congestion algorithms and thus lead to an unnecessary TCP window reduction.

TCP BIC (2004)

The Binary Increase Congestion (BIC) control is optimized congestion control algorithm for high speed/high latency networks. BIC has a unique congestion window algorithm which uses a binary search algorithm in an attempt to find the largest congestion window that will last the maximum amount of time. BIC was used by default in Linux kernels 2.6.8 through 2.6.18, before CUBIC became the default.

TCP CUBIC (2007)

CUBIC is one of the most popular congestion control/avoidance algorithms currently in use. It is used by default in Linux kernels after 2.6.19, it is also the default in later Windows 10 builds, and Windows Server 2019.

CUBIC is a less aggressive and more systematic derivative of BIC, in which the window is a cubic function of time since the last packet loss. There are two components to TCP window growth. In the first part the window ramps up quickly to the size as it was before the packet loss occurred. After the first part, there is a delay allowing enough time for the network to stabilize. After this delay, the second part of CUBIC probes for more bandwidth, slowly at first then very rapidly.

CTCP (Compound TCP, 2006)

CTCP is a Microsoft algorithm that was introduced as part of the Windows Vista and Window Server 2008 TCP stack. It is designed to aggressively adjust the sender's congestion window to optimize TCP for connections with large bandwidth-delay products and large receive window sizes. CTCP attempts to maximize throughput on these types of connections by monitoring delay variations and packet loss. CTCP also ensures that its behavior does not negatively impact other TCP connections. It is also available for some Linux kernels as a patch, for Windows XP and Windows Server 2003 via a hotfix.

Notes: CTCP was the default congestion control protocol for Windows 8/10, 2008 Server. This default has changed to CUBIC in more recent builds of Windows 10 and Windows 2019 Server.
CTCP may perform slightly better than CUBIC with VoIP, and possibly gaming in combination with ECN. CUBIC performs a bit better for pure throughput when there is no excessive network congestion.

TCP LEDBAT (2010)

RFC 6817

Low Extra Delay Background Transport (LEDBAT) is an algorithm that uses changes in one-way delay measurements to limit congestion. It is designed to for use by background bulk-transfer applications to be less aggressive than competing flows, limiting interference with the network performance of competing data streams. It is a way to transfer data in the background quickly, consuming unused bandwidth without clogging the network and without interfering with other TCP connections.

TCP BBR (2016)

Bottleneck Bandwidth and Round-trip propagation time (BBR) is a modern congestion control and avoidance algorithm. It was initially developed at Google in 2016, and a second version with some changes was introduced in 2020. It is available in Linux since kernel 4.9 and the default algorithm used by YouTube and Google cloud. While most algorithms above are loss-based (they rely on packet loss to detect congestion and lower transmission rates), BBR is model-based, using the maximum bandwidth and round-trip time to build a model of the capability of the network based on BDP (bandwidth-delay product). The BBR model is rate-based and delay-based. It is vaguely similar to TCP-Vegas in its partial reliance on latency to detect congestion, without the downsides. BBR limits its number of packets in flight to be a multiple of the bandwidth-delay product (BDP) and also uses pacing to control the inter-packet spacing.

The BBR model of calculating the congestion window: Max measured bandwidth (BW) x minimum latency (RTT) = BDP x 2 = congestion window (CWND, amount of data in the network)
Note: The algorithm uses the maximum measured bandwidth over last 8 RTTs for the calculation. It also adds pacing to the above, and tries to increase its sending rate by 25% for next 6 RTTs. The amount of data in flight is limited to 2 times BDP, which also dictates BBR's fraction of the bandwidth under competition with other algorithms in the same network. In essence, under competition it is not only rate-limited, it is also window-limited.

BBR is efficient and fast, however there were some issues with version 1 of the algorithm. There were some questions raised about BBR's fairness to non-BBR streams. There is potentially some "unfairness" between BBR v1 and CUBIC, reportedly dependent on the bottleneck TCP window buffer size (BBR v1 obtains more of the total bandwidth with smaller buffers, CUBIC gets bigger percentage with very large buffers and gigabit transfers). BBR v1 also causes more packet retransmissions compared to CUBIC, as it ignores packet loss. This is only apparent in the presence of packet loss.

Google has released BBR v2 in 2020 which uses both packet loss and ECN to help identify network congestion and achieve better fairness and fewer packet retransmissions than BBR v1. Below is a list of key differences between the two versions.

BBR v1: low throughput for CUBIC/Reno flows sharing some paths, does not use packet loss, does not use ECN

BBR v2: better coexistence with Reno/CUBIC, uses packet loss as a signal, uses ECN if available

See: BBR v2, A Model-based Congestion Control

C2TCP (2018)

Cellular Controlled Delay TCP (C2TCP) targets interactive applications requiring low latency in high-speed cellular networks. It is inspired by in-network active queue management (AQM) designs to adapt itself to different applications QoS requirements without modifying any client network devices. C2TCP is designed to work as an add-on to existing TCP (e.g. New Reno, CUBIC, BIC, etc.), it only needs to be installed on the server-side, and improves the average delay of packets to be bound to the QoS requirements for different applications. C2TCP aims to satisfy applications such as virtual reality, video conferencing, gaming, vehicular communication systems, etc. in a highly dynamic environment such as LTE and future 5G cellular networks. It can outperform BBR, Cubic and other TCP variants in achieving lower average delay and jitter.

Other TCP congestion control/avoidance algorithms

Below is a list of many other, less common and special use CCA algorithms not covered above, mostly targeted at improving performance of networks with large bandwidth-delay product.

DCTCP (Data Center TCP, 2011): RFC 8257. Intended for data-center traffic extending ECN processing

FAST TCP: especially targeted at long-distance, high latency links

HSTCP (HighSpeed TCP): RFC 3649

H-TCP (Hamilton TCP): targeted at high-speed high-latency networks, developed at the Hamilton Institute in Ireland

Copa: delay-sensitive algorithm that uses a Markovian packet arrival model, used by Facebook for live video uploads

ProPrate: aimed at cellular networks, rate-based algorithm to balance between delay and throughput

Scalable TCP: simple change to traditional TCP CCA to increase congestion window faster

TCP-Jersey: aimed at wireless networks, able to distinguish between wireless packet loss and congestion loss

TCP Hybla (2004): aimed to improve wireless and satellite links, Emory University paper

TCP-Illinois: targeted at high-speed long-distance networks, developed by University of Illinois

TCP Veno: enhancement of transmission over wireless networks

YeAH-TCP (Yet Another Highspeed TCP, 2007): delay-aware/state-enabled to keep a pipe at, or below a threshold.

Conclusion (TL;DR;)

CUBIC is the recommended, and currently most popular congestion control/avoidance algorithm, it is the default in Linux since kernel 2.6.19. CTCP is ok to use with Windows. BBR is a great new algorithm that is gaining popularity, it is available in Linux since kernel 4.9, available in Windows 11, but not yet available in Windows 10. While BBR version 1 had some quirks, if your OS supports BBR version 2 it is likely even better than CUBIC. Westwood can be tried with lossy wireless networks.