Receiver-Based Control

In the previous page, we established that flow control exists to prevent receiver buffer overflow. But a critical question remains: who decides the transmission rate? In TCP's design, the answer is unequivocal—the receiver dictates how fast the sender may transmit.

This receiver-centric architecture is not an arbitrary design choice but a principled decision rooted in information asymmetry. Only the receiver knows its own buffer state, processing capacity, and application consumption rate. The sender, isolated on the other side of the network, has no direct visibility into these conditions. TCP's elegance lies in letting the party with the best information make the decision.

This page examines receiver-based control in depth: how it works, why it's designed this way, and the precise mechanisms by which receivers communicate their capacity to senders.

The fundamental reason TCP flow control is receiver-based lies in information asymmetry—the receiver possesses critical knowledge that the sender cannot obtain.

What the Receiver Knows

The receiver has perfect, real-time knowledge of:

1. Receive buffer size: The total buffer allocated for this TCP connection
2. Data awaiting application: Bytes received but not yet read by the application
3. Available buffer space: Remaining capacity for incoming data
4. Application consumption rate: How fast the application is reading data
5. Local resource constraints: Memory pressure, CPU availability, I/O bottlenecks

What the Sender Cannot Know

The sender, by contrast, is fundamentally limited:

1. No direct buffer visibility: The sender cannot see the receiver's buffer state
2. No application awareness: The sender doesn't know how fast the receiver's application consumes data
3. Network delay: Any information the receiver shares is delayed by network latency
4. State changes between updates: Receiver state may change between window advertisements

This asymmetry leads to a clear design principle: the party with the information should make the decision.

Why Not Sender-Based Control?

One might wonder: why not have the sender estimate receiver capacity and self-regulate? This approach fails for several reasons:

1. No reliable estimation method: The sender cannot measure receiver processing speed
2. Changing conditions: Receiver capacity varies with application behavior, system load, and memory pressure
3. Conservative estimates waste capacity: If the sender underestimates, throughput suffers
4. Aggressive estimates cause overflow: If the sender overestimates, data is lost
5. Feedback loop delays: Even with feedback, network latency introduces instability

Sender-based flow control would require the sender to guess what only the receiver knows—a fundamentally flawed approach.

In TCP's receiver-based flow control, the receiver is not a passive data sink but an active participant in controlling the data flow. This active role manifests in several ways:

1. Window Advertisement

The receiver calculates and advertises its available buffer space in every ACK segment. This 16-bit field (or 30-bit with window scaling) tells the sender exactly how much more data the receiver can accept.

2. Dynamic Adjustment

The receiver continuously recalculates the window based on:

• Data arriving from the network
• Data consumed by the application
• System memory availability
• Policy decisions (e.g., limiting window for QoS purposes)

3. Rate Governance

By controlling the window size, the receiver effectively controls the sender's maximum transmission rate. A smaller window constrains the sender; a larger window permits faster transmission.

4. Pause and Resume

The receiver can pause transmission entirely by advertising a zero window, then resume by opening the window when ready. This gives the receiver complete control over data flow timing.

The code above illustrates how the receiver actively computes and advertises its window. Every incoming segment triggers a window recalculation, and every ACK carries the current window advertisement. The receiver is not passively accepting data—it is actively governing the flow.

The window advertisement is the communication channel through which the receiver exercises control. Understanding its mechanics is essential:

Location in TCP Header

The window field occupies 16 bits (bytes 14-15) of the TCP header. With optional window scaling (discussed later), this expands to effectively 30 bits. The field specifies the number of bytes the receiver can accept, relative to the acknowledgment number.

Semantics of the Window Value

When the receiver advertises a window of W bytes with acknowledgment number A, it means:

"I have successfully received all bytes up to A-1. I can accept bytes A through A+W-1."

This defines a window of acceptable sequence numbers: [A, A+W-1]. The sender must not send bytes with sequence numbers at or beyond A+W.

Piggybacking on ACKs

Every TCP segment with the ACK flag set carries a window advertisement. This piggybacking is efficient—no additional overhead is required for flow control. The window field is always present; it simply reflects current receiver capacity.

The Window as a Sliding Constraint

The advertised window creates a sliding constraint on the sender. As acknowledgments arrive, the left edge of the window advances (bytes are confirmed received). As window advertisements change, the right edge moves (more or less space is advertised).

The sender tracks two pointers:

• Window left edge: The first unacknowledged byte (SND.UNA)
• Window right edge: SND.UNA + SND.WND (last byte sender may transmit)

Critically, the right edge does not always move forward. If the receiver's window shrinks (less space available), the right edge may stay fixed or even appear to move backward. TCP senders must handle this "window shrinking" gracefully.

The receiver's flow control behavior can be modeled as a state machine driven by two event types: data arrival (network events) and application reads (local events).

States

1. FLOWING: Normal state; window is non-zero, data flows freely
2. THROTTLED: Window is very small but non-zero; sender is constrained
3. ZERO_WINDOW: Window is zero; sender has halted
4. OPENING: Window was zero, now opening; may send window update

Transitions

• FLOWING → THROTTLED: When buffer fills and window shrinks significantly
• THROTTLED → ZERO_WINDOW: When buffer becomes completely full
• ZERO_WINDOW → OPENING: When application reads data and space becomes available
• OPENING → FLOWING: After window update is sent and normal flow resumes
• THROTTLED → FLOWING: When application reads data faster than arrival

Event Handling in Each State

FLOWING State

• Data arrival: Buffer data, ACK with updated window
• Application read: Window opens further (already open, no special action)

THROTTLED State

• Data arrival: Buffer data cautiously, ACK with small window
• Application read: Transition to FLOWING if sufficient space opens

ZERO_WINDOW State

• Data arrival: Cannot accept data; sender should not be sending
• Application read: Transition to OPENING; prepare window update
• Persist probe: Respond with current (zero) window status

OPENING State

• Window update sent: Transition to FLOWING
• Data arrival: May transition to THROTTLED depending on arrival volume

The receiver bears several specific responsibilities in TCP flow control. These are not merely suggestions—they are protocol requirements that ensure interoperability and prevent pathological behavior.

Responsibility 1: Accurate Window Reporting

The receiver MUST report an accurate window. Advertising more space than available leads to buffer overflow and data loss. Advertising less space than available artificially throttles throughput.

Responsibility 2: Timely Window Updates

When the application reads data and window opens, the receiver SHOULD send a window update promptly. Delays leave the sender unnecessarily stalled. RFC 1122 specifies: send an update when window increases by at least one MSS or half the buffer, whichever is smaller.

Responsibility 3: Avoiding Silly Window Syndrome

The receiver SHOULD NOT advertise tiny window increases that provoke the sender to send tiny segments. This "silly window syndrome" wastes bandwidth on header overhead. The receiver should wait until a reasonable window is available before advertising.

Responsibility 4: Responding to Persist Probes

When the receiver has advertised a zero window, the sender will periodically send persist probes. The receiver MUST respond to these probes with its current window status, even if the window is still zero.

Responsibility 5: Handling Out-of-Order Segments

Out-of-order segments consume buffer space (if buffered for reassembly) but cannot be delivered to the application until gaps are filled. The window calculation must account for this buffered out-of-order data.

TCP's receiver-based flow control design offers significant advantages over alternative approaches:

Advantage 1: Perfect Information

The receiver has perfect knowledge of its own state. There is no estimation, no guessing, no inference from indirect signals. The receiver knows exactly how many bytes it can accept because it knows exactly how many bytes it has buffered.

Advantage 2: Real-Time Responsiveness

As the application reads data, the receiver can immediately increase its window advertisement. As memory pressure increases, the receiver can immediately decrease it. This responsiveness is limited only by ACK transmission delays, not by feedback loops.

Advantage 3: Decoupled Sender Logic

The sender's job becomes simple: don't exceed the advertised window. The sender doesn't need complex algorithms to estimate receiver capacity—it just follows the receiver's instructions. This simplifies sender implementation and reduces corner cases.

Advantage 4: Heterogeneous Network Support

Receiver-based control works regardless of network topology, latency, or bandwidth. Whether the receiver is across a local network or across the planet, the same mechanism applies. The receiver advertises based on its capacity, not on network characteristics.

Advantage 5: Application-Aware Pacing

The receiver's window naturally reflects application behavior. A paused video player causes the window to shrink; a resumed player causes it to grow. The flow control mechanism automatically adapts to application-level events without explicit coordination.

While receiver-based control is elegant, it is not without challenges. Understanding these edge cases is essential for protocol implementers and network engineers:

Challenge 1: Stale Window Information

The sender acts on window advertisements that may be stale by the time the sender receives them—at least one-half RTT in the past. In high-latency networks, the receiver's state may have changed significantly.

Mitigation: Receivers should not shrink the right edge of the window. Increasing window is safe even with stale info (receiver can handle more data); decreasing is risky.

Challenge 2: Lost Window Updates

If a window update ACK is lost, the sender may remain stalled indefinitely, believing the window is still zero.

Mitigation: The sender's persist timer periodically probes a zero-window receiver. The receiver responds with current window, ensuring eventual recovery.

Challenge 3: Malicious Receivers

A malicious receiver could advertise a large window, accept data, then discard it without acknowledging. This wastes sender resources.

Mitigation: This is a form of denial-of-service. Senders typically trust receivers; explicit mitigation requires application-layer authentication.

Challenge 4: Memory Exhaustion Attacks

An attacker could open many connections, each advertising a large window, exhausting the sender's send buffer memory.

Mitigation: Senders should limit total memory across connections. Per-connection buffer limits prevent single connections from dominating resources.