Table of Contents
Introduction
Flow control is a Transport layer function that keeps a fast sender from overwhelming a slower receiver. It is about how much data can be sent before the sender must wait, not about where to send it, or about fixing lost packets. Those other topics belong to routing and reliability, which are covered in different chapters. Flow control works together with reliability and congestion control, but it has a very specific role: match the sender’s rate to the receiver’s ability to process and store data.
The Core Idea of Flow Control
In any communication, the receiver has limited resources. It has a receive buffer in memory and a CPU that must process incoming data. If the sender transmits too much too quickly, one of two bad things happens. Either the receiver’s buffer overflows and data is lost, or the receiver becomes so busy that it cannot keep up with new data.
Flow control introduces a simple rule. The sender can only have a certain amount of unacknowledged data “in flight” at any time. The receiver tells the sender how much it is currently willing to accept. The sender then respects this limit.
A helpful mental image is a pipe filled with water. The pipe can only hold a certain volume at once. Flow control limits how much water you can have in the pipe before you must wait for some to exit. In networking, the “water” is bytes, and the “pipe limit” is a number that represents the receive window.
Flow Control vs Congestion Control
Flow control is about the receiver’s capacity. Congestion control is about the network’s capacity. They often act together but solve different problems.
Table: Flow control vs congestion control
| Aspect | Flow Control | Congestion Control |
|---|---|---|
| Main goal | Protect the receiver from overload | Protect the network from overload |
| Who signals | Receiver tells sender how much it can handle | Network conditions indirectly signal sender |
| Typical signal | Advertised window size from receiver | Packet loss, increasing delays, timeouts |
| Scope | One sender–receiver pair | Many flows sharing the same network links |
In this chapter we stay focused on flow control, especially as used by TCP.
How Flow Control Works in TCP
TCP is the main protocol where flow control is visible and important. It is connection oriented and reliable, and it must not overflow the receiver’s buffer. TCP uses a sliding window mechanism for flow control, guided by a numeric value called the receive window.
Receive Window Concept
On each side of a TCP connection there is a receive buffer. As segments arrive, they are stored in this buffer until the application reads them. The larger this buffer, the more data the receiver can hold temporarily.
The receiver regularly informs the sender how much free space remains in its buffer. This value is called the advertised receive window, often written as rwnd. It is carried in every TCP segment header sent from the receiver to the sender.
The rule for the sender is simple: the total number of bytes sent but not yet acknowledged must never exceed the advertised receive window.
Rule: TCP Flow Control
The sender must ensure:
$$\text{Unacknowledged bytes in flight} \leq \text{Advertised receive window (rwnd)}$$
If the sender would exceed rwnd, it must stop and wait for a larger window to be advertised.
This rule keeps the sender in sync with the receiver’s current capacity.
Sliding Window Behavior
Although the details of the sliding window algorithm belong to the TCP overview and reliable transmission topics, we need a small part of it here to see how flow control operates.
Consider a sender and receiver that have established a TCP connection. The receiver starts by advertising a window size, for example 10,000 bytes. The sender can now transmit up to 10,000 bytes without waiting for new permission. As the receiver gets data, it sends acknowledgments. These acknowledgments do two things at once. They confirm which bytes have been correctly received, and they include a fresh window size that tells the sender how many more bytes it can send now.
If the application on the receiving side reads data from the buffer quickly, the buffer frees up and the receiver can keep advertising a large window. If the application is slow to read, more of the buffer becomes occupied. The receiver then advertises a smaller window, which makes the sender slow down.
Over time, the window “slides” forward over the byte sequence. As earlier bytes are acknowledged and removed from “in flight” status, new bytes can be sent as long as the sum of in flight bytes does not exceed rwnd. Flow control is implemented by the constant adjustment of this advertised window.
Window Size and Buffer Space
Flow control depends on a direct relationship between buffer space and window size. The receive window tells the sender how much unused space is left in the buffer. That is why the window size must change as the buffer fills and empties.
For a beginner, it is useful to link these ideas.
- The receiver reserves some memory space as a buffer, for example 64 KB.
- The buffer fills as network data arrives and empties as the application reads.
- The receiver tracks how many bytes in that buffer are currently used.
- It computes free space as:
$$\text{Free space} = \text{Total buffer size} - \text{Bytes currently stored}$$
- The free space value becomes the basis for the advertised receive window.
The receiver does not have to expose its exact internal buffer size, but the advertised window is chosen to avoid overflow. If almost all the buffer is used, the advertised window shrinks. If the buffer is mostly free, the window grows.
Zero Window and Window Updates
Sometimes the receiver may run temporary out of space in its buffer. In that case it can advertise a zero window. This is a special signal that says “do not send me any more data right now.”
When the sender sees a zero window in the TCP header, it must stop sending data, although it still sends control segments if needed. The sender does not want to wait forever, so it will occasionally send a small probe segment to check if the window size has increased. This probe is known as a zero window probe. When the receiver has again some free space, it will advertise a new, larger window in its acknowledgments. At that moment the sender can resume normal sending within the new limit.
Zero window situations are not ideal, because they interrupt data flow. They usually indicate that the receiving application is slow or blocked. However, they prevent buffer overflow and data loss at the receiver.
Flow Control and Application Speed
Flow control directly reveals whether an application on the receiving side is fast or slow. If the application reads data from the TCP buffer quickly, the buffer does not stay full for long. The receiver keeps advertising a large window, which allows the sender to send more data without interruption. The overall connection can then run at a high data rate, limited mainly by the path and congestion control.
If the application is slow to read data, the buffer fills up. The receiver’s advertised window shrinks, sometimes down to zero. The sender must pause often, which reduces throughput. From the sender’s point of view, the receiver becomes the bottleneck, even if the network path itself is fast.
So flow control is also a way to respect the speed of the receiving application, not only the hardware buffer.
Interaction with TCP Options
The original TCP header has a limited field size for the window. In order to support larger windows for high-speed networks and long paths, TCP uses a window scale option, which is negotiated when the connection is established. The exact details belong in more advanced TCP topics, but one principle is important here. The effective receive window can be larger than the basic field in the header, which means flow control can operate with large buffers and high throughput without losing precision.
The sender always applies the effective advertised window after any scaling is considered. The same fundamental rule still holds. At all times, unacknowledged bytes in flight must not exceed the effective receive window.
Summary
Flow control at the Transport layer exists so that a sender does not drown a slower receiver in data. It does this by using a window based system where the receiver announces how much data it is ready to accept, and the sender obeys that limit. TCP implements this with an advertised receive window in the header of each segment and a sliding window algorithm that tracks bytes in flight. When the receiver is fast and its buffer is mostly free, the window is large and the sender can transmit quickly. When the receiver is slow, the window shrinks or becomes zero, and the sender must slow down or pause. This keeps data transfer safe and reliable from the receiver’s point of view, and it forms one of the key responsibilities of the Transport layer.