Mismatch between sender and receiver rates
Flow control is needed when the sending rate exceeds the receiver's rate of acceptance or processing. The receiver may be slower because of link capacity, processor load, or a small buffer. Without a rate limit, data accumulates on the receiving side until storage is exhausted.
A server can transmit data faster than the receiving device can accept and process it. The receiver might be an older printer, a low-cost IoT sensor, or a computer busy with other tasks. If the device does not advertise available buffer space, later frames can be discarded.
This mechanism is known as Flow Control. It is a set of rules and procedures that regulates the transfer rate between two nodes. The goal is to match the sending rate to the amount of data that the receiver can store and process. At the data-link layer, the mechanism operates between adjacent nodes. At the transport layer, TCP uses an advertised receive window to limit the data sent to the destination host. Flow control describes receiver capacity, while congestion control describes load in the network as a whole. The and apply flow control at different scopes.
Receive buffers and overruns
A network interface card (NIC) has a finite amount of dedicated memory called a receive buffer. The buffer holds frames until the device retrieves them.
Reception has two stages:
- Arrival: Data frames arrive from the network link at the sender's transmission rate. The NIC places these incoming frames into the receive buffer.
- Processing: The device's main processor (CPU) is notified that new data has arrived. It then pulls the data from the buffer for further processing (e.g., checking for errors, passing it up to the next network layer).
The problem arises when the arrival rate exceeds the processing rate. If the sender transmits frames faster than the CPU retrieves them, the buffer begins to fill. Its finite capacity then produces a condition called a buffer overrun or buffer overflow.
Overrun consequence: discarded frames
When the receive buffer is full, new frames have no space and the NIC discards them. The sender may detect the loss through higher-layer mechanisms such as TCP retransmission timers and acknowledgments. Retransmissions add traffic and reduce useful throughput. Flow control limits the number of frames that reach a full buffer. In window-based protocols, the receiver can advertise the available window; a zero value pauses ordinary transmission until space is released. TCP also uses zero-window probing to discover that the window has opened again.
Two flow-control strategies
Flow-control strategies differ in how the sender and receiver coordinate. The mechanisms can use receiver feedback or impose a preconfigured transmission-rate limit.
1. Feedback-based control
The receiver reports its readiness or the size of its available window. The sender adjusts its transmission rate from that information. A report can mean "stop sending" or "you are permitted to send 8 more frames." In a sliding window, an acknowledgment releases space for additional frames, while sequence numbers preserve ordering. A window can be measured in frames or bytes, depending on the protocol. TCP, HDLC, and LLC Type 2 use feedback-based mechanisms.
2. Fixed-rate limit
The sender follows a limit negotiated when a service or connection is established, so the receiver can prepare resources for the specified traffic. The limit itself does not report the current buffer state. In ATM, the traffic contract describes source parameters and traffic conformance, while shaping keeps transmission within the selected profile. ATM also defines feedback functions, so it illustrates the use of rate parameters rather than a pure no-feedback category.
Stop-and-Wait: one frame in flight
The simplest form of feedback-based flow control is the Stop-and-Wait protocol. It limits the number of unacknowledged frames to one. A variant with acknowledgments and retransmission combines flow control with error recovery.
Stop-and-Wait procedure
- The sender transmits a single data frame.
- The sender then STOPS further transmission and WAITS. It starts a waiting timer.
- The receiver receives the frame, processes it, and if it's correct, sends a small control frame back to the sender called an acknowledgment (ACK).
- The sender receives the ACK, stops its timer, and is now permitted to send the next single frame. It then repeats the process from step 2.
- If the sender's timer expires before an ACK is received, which indicates that the data frame or ACK was lost, a reliable variant retransmits the original frame. Sequence numbers let the receiver recognize a duplicate when the original frame arrived but its acknowledgment was lost.
Stop-and-Wait: benefits and limits
- Advantage: One unacknowledged frame limits the amount of data waiting at the receiver. The mechanism is simple to implement and analyze, and its state is easy to describe with a timer and an acknowledgment.
- Disadvantage: On links with a long delay, the sender waits for an ACK instead of transmitting the next frame. The waiting period reduces channel utilization. With a large RTT, one frame occupies the link for only a short part of the cycle, while the remaining time is spent waiting.
Calculating link utilization
In a simplified model, one cycle includes frame transmission and the time from the end of that transmission until the ACK arrives. The second component is the Round-Trip Time (RTT). RTT includes the trip to the receiver and the return of the acknowledgment, plus processing delays in a practical link. The formula omits ACK transmission time and any waiting after an error.