Introduction
TCP does more than just guarantee delivery - it also actively regulates how much data is in flight at any moment. It does this through two related but distinct mechanisms: flow control, which protects the receiver, and congestion control, which protects the network. Confusing the two is one of the most common mistakes when learning TCP.
Cricket analogy: TCP doesn't just guarantee every ball is bowled and counted, it also actively manages the pace: flow control is like the non-striker watching the striker's fatigue (the receiver's buffer) while congestion control is like the umpire managing over-rate for the whole match (the shared network), and confusing the two is a rookie commentator's mistake.
Explanation
Flow control is receiver-driven: it exists to prevent a fast sender from overwhelming a slow receiver's buffer. Each TCP segment's header includes a receive window (rwnd) field, which the receiver uses to advertise how much buffer space it currently has available. The sender must never have more unacknowledged data in flight than the receiver's advertised rwnd. This is often called the sliding window mechanism - as the receiver's application reads data out of its buffer, the window 'slides' forward and the receiver can advertise more room, allowing the sender to transmit more.
Cricket analogy: Flow control is receiver-driven like a wicketkeeper signaling the bowler to slow down because the scorer's book (buffer) is falling behind; as the scorer catches up and clears space, the keeper signals for more deliveries, sliding the window forward just like TCP's advertised rwnd.
Congestion control is network-driven: it exists to prevent the sender from overwhelming the network itself (routers and links between sender and receiver), independent of how much buffer space the receiver has. The sender maintains its own internal estimate of network capacity called the congestion window (cwnd), and the actual amount of data the sender may transmit is the minimum of rwnd and cwnd. TCP congestion control typically proceeds through two main phases: slow start, where cwnd grows exponentially (roughly doubling each round-trip time) until it hits a threshold or packet loss is detected; and congestion avoidance, where growth becomes linear/additive - increasing cwnd by about one segment per round-trip time - following an Additive-Increase, Multiplicative-Decrease (AIMD) pattern where a detected loss event causes cwnd to be cut sharply (e.g., halved).
Cricket analogy: Congestion control is network-driven like a captain pacing the team's aggression based on pitch conditions rather than the keeper's readiness: starting cautiously (slow start) then doubling scoring rate each over until a wicket falls (loss), after which the captain sharply reins in the scoring rate (AIMD), which is the cwnd being cut.
Example
# Illustrative (not literal) trace of congestion window growth
# Slow start: cwnd grows exponentially each RTT
# RTT 1: cwnd = 1 segment
# RTT 2: cwnd = 2 segments
# RTT 3: cwnd = 4 segments
# RTT 4: cwnd = 8 segments <- ssthresh reached, or loss detected
# Congestion avoidance: cwnd grows linearly (AIMD) after ssthresh
# RTT 5: cwnd = 9 segments
# RTT 6: cwnd = 10 segments
# RTT 7: cwnd = 11 segments <- packet loss detected!
# RTT 8: cwnd = 5 segments (multiplicative decrease, e.g. halved)
# Actual sending rate = min(cwnd, rwnd)
cwnd = 11
rwnd = 6 # receiver's advertised window from the TCP header
allowed_in_flight = min(cwnd, rwnd) # = 6, receiver is the bottleneck hereAnalysis
In the example, even though the sender's congestion window (cwnd) has grown to 11 segments, the receiver has only advertised room for 6 (rwnd), so the sender is capped at 6 segments in flight - flow control is the limiting factor here. Had the situation been reversed, with a large rwnd but a small cwnd (e.g., early in slow start), congestion control would have been the limiting factor instead. This is precisely why the two mechanisms must be kept conceptually separate: flow control responds to the receiver's buffer state (a local, receiver-side constraint), while congestion control responds to inferred network conditions such as packet loss or increasing delay (a shared, network-wide constraint). The sender always transmits no more than min(cwnd, rwnd), so both limits apply simultaneously.
Cricket analogy: Even though the batting side's ambition (cwnd) has grown to attempt 11 runs an over, the ground's boundary rope situation only safely allows 6 (rwnd), capping the over at 6; had it been reversed, with plenty of boundary room but early-innings caution (small cwnd), that caution would have been the limiting factor instead.
Key Takeaways
- Flow control is receiver-driven and uses the advertised receive window (rwnd) to prevent overwhelming the receiver's buffer.
- Congestion control is network-driven and uses the congestion window (cwnd) to prevent overwhelming the network.
- The sender's actual allowed data in flight is min(cwnd, rwnd).
- Slow start grows cwnd exponentially each RTT; congestion avoidance grows cwnd linearly (AIMD) after a threshold or loss.
- Detected packet loss triggers a multiplicative decrease in cwnd, while successful delivery triggers additive increase.
Practice what you learned
1. What is the primary purpose of TCP flow control?
2. Which window is used by TCP congestion control to estimate safe network capacity?
3. How does cwnd typically grow during TCP's slow start phase?
4. What determines the actual amount of unacknowledged data a TCP sender is allowed to have in flight?
Was this page helpful?
You May Also Like
TCP vs UDP
Compare TCP and UDP across reliability, ordering, connection state, overhead, and typical use cases.
The TCP Three-Way Handshake
Trace how TCP establishes a reliable connection using the SYN, SYN-ACK, and ACK exchange.
Network Performance Concepts
Understand how bandwidth, throughput, latency, jitter, and packet loss differ and how they interact to determine real-world network experience.
Ports and Sockets
Understand port number ranges and how a socket, the pairing of an IP address and port, identifies a network endpoint.