TCP Congestion Control

What Is TCP Congestion Control?

TCP Congestion Control is a set of algorithms and strategies used by the Transmission Control Protocol (TCP) to detect, prevent, and respond to network congestion. Its primary goal is to ensure efficient data transfer over the Internet without overwhelming routers, switches, or receiving devices.

In essence, it’s how TCP answers the question:
“How fast should I send data without causing a network traffic jam?”

While TCP guarantees reliable delivery, it must also play fair on shared networks. Congestion control enables that fairness—balancing speed with stability.

Why Is Congestion Control Necessary?

Modern networks are shared resources. Too many simultaneous data flows can create congestion, much like cars piling up at rush hour.

Without congestion control, TCP would:

Overwhelm intermediate routers and switches
Cause packet drops and retransmissions
Lead to increased latency and jitter
Reduce overall network throughput

TCP Congestion Control ensures that data flows are smooth, fair, and adapt to real-time network conditions.

TCP’s Four Key Control Mechanisms

Slow Start
Congestion Avoidance
Fast Retransmit
Fast Recovery

These stages define how TCP increases, detects, and corrects its sending rate.

1. Slow Start

Initial phase of a TCP connection
Begins with a low transmission rate (often 1–2 segments)
Congestion window (cwnd) grows exponentially with each ACK received
Continues until a threshold is hit or packet loss is detected

Purpose: Probe the available bandwidth gently, instead of flooding the network all at once.

2. Congestion Avoidance

Kicks in after slow start threshold (ssthresh) is crossed
cwnd grows linearly instead of exponentially
Adds one segment per RTT (round-trip time)

Purpose: Avoid congestion by growing more cautiously as traffic increases.

3. Fast Retransmit

Activated when 3 duplicate ACKs are received (indicating likely packet loss)
Retransmits the lost segment immediately, without waiting for timeout

Purpose: React quickly to packet loss caused by congestion

4. Fast Recovery

After fast retransmit, cwnd is reduced, but not all the way back to 1
TCP resumes transmission in congestion avoidance mode, not slow start

Purpose: Maintain throughput while correcting the error

Key Concepts

Term	Meaning
Congestion Window (cwnd)	Max number of bytes TCP can send without acknowledgment
Slow Start Threshold (ssthresh)	Point at which TCP switches from exponential to linear growth
Round-Trip Time (RTT)	Time it takes for a packet to travel from sender to receiver and back
Acknowledgment (ACK)	Signal from receiver confirming successful data delivery
Duplicate ACKs	Repeated ACKs for the same data—usually signal lost packet

TCP Congestion Control Algorithms

Over the years, various congestion control algorithms have been developed and standardized:

1. TCP Reno

Classic implementation used in early Internet
Introduced fast retransmit and fast recovery

2. TCP Tahoe

Predecessor to Reno
Returns to slow start on packet loss

3. TCP NewReno

Improves retransmission during fast recovery

4. TCP Cubic

Default algorithm in modern Linux kernels
Optimized for high-speed, long-distance networks
Uses a cubic function for cwnd growth

5. TCP BBR (Bottleneck Bandwidth and RTT)

Developed by Google
Estimates bottleneck bandwidth and minimum RTT
Focuses on maximizing throughput and minimizing delay
Does not rely on packet loss as a congestion signal

Example: Slow Start in Action

Time 0: Sender sends 1 segment
ACK received → cwnd = 2
Next ACK → cwnd = 4
Next ACK → cwnd = 8
...
Once cwnd > ssthresh → enters congestion avoidance

This exponential growth continues until a packet loss or threshold triggers a change in behavior.

TCP Congestion vs Flow Control

Although often confused, these are distinct mechanisms in TCP:

Feature	Congestion Control	Flow Control
Purpose	Protect the network from overload	Protect the receiver from overload
Scope	End-to-end and network-wide	Sender-to-receiver only
Mechanism	cwnd, RTT, packet loss, bandwidth estimation	Advertised window (rwnd) in TCP header
Reacts to	Network feedback (loss, delay)	Receiver’s buffer capacity

They work together to ensure reliable and efficient data transfer.

Use Cases in Modern Systems

Video streaming: TCP may scale down quality during congestion
Cloud services: BBR improves latency for HTTP/2 and QUIC over long-haul networks
Gaming: Latency-sensitive applications often benefit from lighter congestion control strategies
CDNs and edge computing: Use tuning and monitoring to adapt congestion strategies for optimal delivery

How Developers Can Interact with TCP Congestion Control

Socket options: On Linux, setsockopt() allows specifying the congestion algorithm:

setsockopt(sockfd, IPPROTO_TCP, TCP_CONGESTION, "cubic", strlen("cubic"));

Tuning sysctl: Configure global defaults in /etc/sysctl.conf

net.ipv4.tcp_congestion_control = bbr

Monitoring: Use tools like ss, netstat, or tcpdump to observe congestion behavior

Challenges and Trade-Offs

Latency vs Throughput: Algorithms like Cubic favor bandwidth, while BBR aims for lower delay
Packet Reordering: Some algorithms misinterpret reordering as packet loss
Fairness: Multiple flows from different algorithms can lead to unfair bandwidth allocation
Tuning Complexity: System admins may need to experiment to find optimal settings

Summary

TCP Congestion Control is the invisible hand that keeps the Internet from crashing under its own weight. By intelligently adjusting how fast data is sent based on network conditions, it ensures that every flow gets a fair share of bandwidth—without causing chaos.

From early days of Reno to modern approaches like BBR, congestion control has evolved to meet the demands of video streaming, cloud computing, and real-time communication. It’s a classic example of software doing less, smarter—and achieving more.