Card 05/ 11
Flow Control vs Congestion Control
Both slow a sender down; one listens to the receiver and the other guesses at the network.
Flow control and congestion control both limit how much data a TCP sender has in flight, and they protect different things. Flow control protects the receiver from being sent more than it can hold, using a number the receiver reports. Congestion control protects the network between them from being overloaded, using an estimate the sender makes for itself.
| Property | Flow control | Congestion control |
|---|---|---|
| Protects | The receiver's buffer | The network between the two ends |
| Limit set by | The receiver, which advertises it | The sender, which estimates it |
| Carried in the header | Yes, the window field in every segment | No, it exists only inside the sender |
| Signal it reacts to | The receiving program reading more slowly | Lost segments, or in some algorithms rising delay |
| A typical fault it explains | A slow program at the receiving end | A busy or lossy path |
The sender obeys whichever limit is smaller. On a fast path to a slow receiver, flow control decides how fast data moves; on a slow or busy path to a fast receiver, congestion control does.
The difference that matters most is who knows the limit. The receiver knows exactly how much room it has and says so, so the flow control window is a fact. Nobody tells the sender how much the network can carry; the congestion window is a guess, raised while things go well and cut when packets go missing.
That difference shows in diagnosis. A small advertised window is visible in a packet capture and points at the receiving program. A small congestion window is visible only as a sender that sends less than the receiver allows, which points at loss somewhere on the path.
The rule for telling them apart. Ask what the limit is protecting. If it is the program at the other end, it is flow control. If it is the network in between, it is congestion control.
← → move through sections and cards