Flow Control vs Congestion Control

Two Problems That Sound Similar, But Aren't

Flow control and congestion control both slow down a sender - but they respond to two completely different problems, and confusing them is a common source of misunderstanding.

Flow Control: Protecting the Receiver

As covered in an earlier note, flow control exists purely to stop a fast sender from overwhelming a slow receiver's buffer. It's a conversation between exactly two endpoints, and has nothing to do with the state of the network in between them.

Congestion Control: Protecting the Network Itself

Congestion control exists to stop a sender from overwhelming the network path in between - the routers and links data must cross - even if the receiver itself is perfectly capable of handling the data.

Flow control:        Sender  <---- receiver's buffer status ---->  Receiver
Congestion control:  Sender  <---- signals from the network path ---->  Receiver

Side-by-Side Comparison

Flow ControlCongestion Control
ProtectsThe receiver's bufferThe shared network path
Signal usedReceiver's advertised window sizePacket loss, delay, or explicit congestion signals
Who is "slow"The specific receiverSome router or link along the path

Why TCP Needs Both, Simultaneously

A receiver could be perfectly fast, but a router three hops away could still be overloaded by other traffic entirely unrelated to this connection. TCP constantly balances both signals together, sending at whichever rate is currently limited by the more restrictive of the two.

Written by Lorens Mishra

Software Engineer Notes Management System Administrator

Discussion

0 comments
Sign in to join the discussion.

No comments yet. Be the first to say something.