Flow Control and Error Control·Lesson 2 of 7
Need for Flow Control
The Problem in Plain English
Not all devices work at the same speed. A powerful server can pump out data far faster than a small sensor or a busy phone can swallow it. When a quick sender is paired with a slower receiver, the receiver falls behind — and data starts getting lost, not because the network broke, but because the receiver simply couldn't keep up. exists to prevent exactly this: it keeps the sender's pace matched to what the receiver can handle.
The core idea
Flow control is about protecting the receiver, not the network. The question it answers is: 'Is the receiver ready for more, or will the next frame be dropped because it has nowhere to go?'
Filling a glass from a tap
Turn a tap on full blast to fill a small glass and most of the water splashes over the sides and is wasted. The glass can only hold so much at once. You naturally slow the flow to match how fast you can drink or move the glass away. A receiver's memory is that glass, the data is the water, and flow control is your hand on the tap.
Why the Receiver Can't Always Keep Up
When frames arrive, the receiver doesn't use them instantly. It first parks them in a — a small block of memory — then processes them one at a time: checking them, passing them to an application, freeing the space. Several everyday situations make that processing slower than the arrival rate, and the buffer starts to fill.
Common reasons a receiver falls behind
- The sender's hardware is simply faster than the receiver's
- The receiver's processor is busy with other work and can't drain the buffer quickly
- The receiver has only a small buffer to begin with
- Many senders are aiming data at one receiver at the same time
What Happens Without Flow Control
Picture a sender that ignores the receiver entirely and blasts frames at full speed. The buffer fills to the brim, and then every new frame has nowhere to land — so the receiver drops it. This is called . The dropped frames were still transmitted, so the effort and bandwidth spent on them is wasted, and they'll have to be sent all over again. Ironically, sending too fast can make everything slower.
Here's the difference flow control makes when a fast sender meets a slow receiver:
| Without flow control | With flow control | |
|---|---|---|
| Sending pace | Full speed, ignores the receiver | Matched to what the receiver can accept |
| Receiver buffer | Overflows and drops frames | Stays within its limit |
| Wasted bandwidth | High — dropped frames must be re-sent | Low — little to no waste |
| Overall result | Slower and unreliable | Steady and reliable |
How Flow Control Actually Paces Things
There are two broad ways to keep the sender in check. The first is , where the receiver actively signals back — 'I've got room, send more' or 'hold on.' The stop-and-wait and sliding-window protocols in this topic all work this way. The second is , where the sender is simply told a maximum speed it must not exceed, with no per-frame feedback. Feedback-based is by far the more common approach in the protocols you'll study.
A common real-world form of feedback is the receiver advertising how much free buffer space it currently has. If the receiver says 'I have room for 5 more frames,' the sender sends at most 5 before pausing for an update. When you reach the Sliding Window Protocol, this is exactly the mechanism you'll see in action.
“"Flow control means the network is too slow or congested."”
Q:Why do we need flow control if the link between two devices is fast and reliable?
A: Because a fast, reliable link says nothing about how fast the receiver can process what arrives. If the sender outpaces the receiver, the receiver's buffer fills and it starts dropping frames — which then must be re-sent, wasting bandwidth. Flow control matches the sender's rate to the receiver's capacity so the buffer never overflows, regardless of how good the link is.
Quick Revision Cheat Sheet
Why needed: A fast sender can overrun a slower receiver
The victim: The receiver's buffer — limited memory
Failure mode: Buffer overflow — new frames get dropped
Cost of no control: Wasted bandwidth and retransmissions
Two approaches: Feedback-based (signals) and rate-based (fixed speed)
Not the same as: Congestion control, which is about network load