What is TCP Congestion Control?
Learn TCP congestion control — slow start, congestion avoidance, fast recovery, and timeouts — with a clear interview-ready explanation.
Expected Interview Answer
TCP congestion control is the set of sender-side algorithms that limit how much data is put into the network at once, using a congestion window (cwnd) that grows when data flows smoothly and shrinks sharply when packet loss signals the network path itself is overloaded, protecting the shared network from collapse rather than protecting the receiver.
Unlike flow control, which reacts to the receiver’s buffer, congestion control reacts to the state of the network between sender and receiver, inferred indirectly through signals like packet loss, duplicate ACKs, or explicit congestion notification (ECN) marks. Classic TCP begins with slow start, growing the congestion window exponentially until it hits a threshold or detects loss, then switches to congestion avoidance, growing more conservatively (roughly linearly) to probe for more capacity without overwhelming the path. On packet loss, the algorithm reacts differently depending on the signal: three duplicate ACKs trigger fast retransmit and typically halve the window (fast recovery), while a retransmission timeout is treated as a severe signal and resets the window back to slow start. The actual amount the sender can transmit is always the minimum of the congestion window and the flow-control receive window, so both limits work together even though they solve different problems.
- Prevents many senders from collectively overwhelming shared network links
- Adapts sending rate dynamically to available path capacity
- Recovers gracefully from transient loss via fast retransmit/fast recovery
- Falls back conservatively (slow start) after a severe timeout signal
AI Mentor Explanation
TCP congestion control is like a captain gradually increasing how aggressively the team runs between wickets as the outfield proves it can handle the pace, but instantly calling for extreme caution the moment a run-out signals the outfield is congested and cannot keep up. Early on, the captain doubles the running tempo each over it goes well (slow start), then eases into smaller, steadier increases once things feel closer to the limit (congestion avoidance). A single close call trims the tempo back moderately, but a genuine run-out resets the team all the way back to cautious running. This mirrors exactly how TCP grows the congestion window and slashes it on loss.
Step-by-Step Explanation
Step 1
Slow start
The congestion window starts small and roughly doubles each round-trip until a threshold (ssthresh) or loss is hit.
Step 2
Congestion avoidance
Growth switches to a conservative, roughly linear increase to probe for remaining capacity without overload.
Step 3
Loss detected via duplicate ACKs
Fast retransmit resends the missing segment and fast recovery halves the window rather than resetting fully.
Step 4
Loss detected via timeout
A retransmission timeout is treated as severe congestion, resetting the window and restarting slow start.
What Interviewer Expects
- Correct definition: protects the network path, distinct from receiver-focused flow control
- Names slow start and congestion avoidance and how cwnd grows in each
- Explains the difference in reaction to duplicate ACKs vs a timeout
- Knows the effective send limit is min(cwnd, rwnd)
Common Mistakes
- Confusing congestion control with flow control
- Thinking cwnd grows the same way in slow start and congestion avoidance
- Not knowing timeouts are treated more severely than duplicate-ACK loss
- Forgetting the actual send window is the minimum of cwnd and rwnd
Best Answer (HR Friendly)
“TCP congestion control is how a sender avoids overwhelming the shared network itself, not just the receiver. It starts sending cautiously, ramps up quickly while things go well, then grows more slowly as it nears the limit, and if it detects packet loss, it backs off — sharply for a serious timeout, more moderately for a few dropped packets — so the whole network stays stable even with many connections sharing it.”
Code Example
# Check which congestion control algorithm is active (Linux)
cat /proc/sys/net/ipv4/tcp_congestion_control
# cubic
# List available congestion control algorithms
cat /proc/sys/net/ipv4/tcp_available_congestion_control
# Inspect live congestion window / ssthresh for a connection
ss -tin dst example.comFollow-up Questions
- How do slow start and congestion avoidance differ in how cwnd grows?
- What is the difference between fast recovery and a full retransmission timeout reset?
- What is TCP CUBIC and how does it differ from classic Reno?
- How does ECN allow congestion signaling without dropping packets?
MCQ Practice
1. What does TCP congestion control primarily protect?
Congestion control adapts the sending rate to protect the network path itself, unlike flow control which protects the receiver.
2. During slow start, how does the congestion window typically grow?
Slow start grows cwnd exponentially (roughly doubling per round-trip) until a threshold or loss is reached.
3. What is the effective maximum amount of unacknowledged data a TCP sender can have in flight?
The sender is bounded by whichever is smaller — the congestion window (network-focused) or the receive window (receiver-focused).
Flash Cards
What is TCP congestion control? — Sender-side algorithms that adjust the congestion window based on inferred network congestion, protecting the shared path.
How does cwnd grow in slow start? — Roughly exponentially, doubling each round-trip, until a threshold or loss occurs.
Duplicate-ACK loss vs timeout loss? — Duplicate ACKs trigger fast retransmit/recovery (halve window); a timeout resets cwnd and restarts slow start.
Effective TCP send limit? — The minimum of the congestion window (cwnd) and the receiver’s advertised window (rwnd).