Receive Window

While the sender pushes data into the network, the receiver faces a different challenge: accepting that data reliably, buffering it appropriately, and delivering it to the application in order—all while providing feedback that prevents the sender from overwhelming its capacity.

The receive window is the receiver's tool for this task. It represents the receiver's current capacity to accept data and is advertised to the sender in every ACK. When the application reads slowly, the window shrinks. When it catches up, the window expands. This dynamic feedback creates a self-regulating system that adapts to application behavior.

This page examines receive window mechanics in exhaustive detail: how the receiver manages its buffer, calculates its available capacity, advertises the window, and handles edge cases like out-of-order arrival and zero window conditions.

Just as the sender maintains state for transmission, the receiver maintains state for reception and window advertisement. RFC 793 specifies these variables:

The Receive Sequence Space:

Understanding RCV.NXT:

RCV.NXT is the cornerstone of receive-side TCP. It represents:

1. Next expected byte: The receiver expects a segment with this sequence number next
2. Cumulative acknowledgment: All bytes before RCV.NXT have been received without gaps
3. In-order delivery point: Bytes up to RCV.NXT - 1 can be delivered to the application
4. ACK value: The ACK number in outgoing segments equals RCV.NXT

The receive window boundaries:

Acceptable sequence numbers: [RCV.NXT, RCV.NXT + RCV.WND)

• Bytes with sequence numbers < RCV.NXT are duplicates (already received)
• Bytes with sequence numbers ≥ RCV.NXT + RCV.WND are beyond the window (rejected)
• Bytes in the acceptable range are buffered, even if out of order

The receive buffer is the memory region that holds incoming data between network arrival and application consumption. Its management is central to receive window behavior.

Buffer organization:

The receive buffer is logically organized into regions:

Window calculation:

The receive window advertised to the sender is calculated based on available buffer space:

RCV.WND = Buffer_Size - (Bytes_Buffered_Not_Yet_Read_By_App)

More precisely:

RCV.WND = Buffer_Size - (Highest_Sequence_Received - Last_Sequence_Read_By_App)

This includes both in-order and out-of-order data. If the application reads slowly, buffered data accumulates, and RCV.WND shrinks. If the application reads quickly, buffer space frees, and RCV.WND grows.

Buffer size configuration:

The receive buffer size is configured at the socket level, often with OS defaults that may need adjustment for high-performance scenarios:

Auto-tuning:

Modern operating systems implement TCP receive buffer auto-tuning:

1. Start with a small buffer
2. Observe actual usage patterns (RTT, throughput)
3. Grow buffer as needed up to a maximum
4. Shrink if memory pressure requires

This balances performance with memory efficiency across diverse connections.

The Internet provides no ordering guarantees. Packets can take different paths, experience different delays, and arrive out of order. The receiver must handle this gracefully.

RFC 793's original guidance:

The original TCP specification suggested that receivers could discard out-of-order segments. The sender would eventually retransmit, and hopefully the retransmission would arrive in order. This is correct but inefficient.

Modern receiver behavior:

Modern TCP implementations buffer out-of-order segments:

1. Accept if within window: Any segment with sequence number in [RCV.NXT, RCV.NXT + RCV.WND) is accepted
2. Buffer in reassembly queue: Out-of-order segments are stored in a data structure (often a list or tree of sequence ranges)
3. Coalesce when possible: When the missing gap arrives, merge contiguous ranges
4. Deliver to application: Only contiguous data from RCV.NXT can be delivered

Reassembly data structures:

Implementations typically use one of these data structures for out-of-order segment management:

The linked list approach is common for connections with infrequent reordering. Trees scale better for connections with persistent reordering.

The receiver communicates its capacity to the sender through the Window field in the TCP header. This 16-bit field (extended by window scaling) indicates how many bytes beyond the acknowledged byte the receiver can accept.

When to advertise:

The receiver includes a window value in every segment it sends, particularly:

1. ACK segments: Every acknowledgment carries a window update
2. Data segments: If the receiver is also sending data, it includes window information
3. Window updates: Pure window update segments (ACK with no new data, just updated window)

Computing the advertised value:

Advertised_Window = min(RCV.WND, Maximum_Representable_Value)

With window scaling, Maximum_Representable_Value = 65535 × 2^scale_factor. Without scaling, it's just 65535.

Window shrinking considerations:

A subtle issue: should the receiver ever shrink the window's right edge? Consider:

1. Receiver advertises window = 10000, starting at ACK = 5000
2. Sender's window covers bytes 5000-14999
3. Receiver's buffer fills; available space drops to 3000
4. Should receiver advertise window = 3000?

This would move the window right edge from 15000 to 8000—a dangerous backward movement. The sender may have already transmitted bytes 8000-14999, which the receiver now says it can't accept.

RFC 793 advises against shrinking:

The standard recommends the receiver not shrink the right edge of the window. Instead:

• Delay sending ACKs until buffer space frees
• Or advertise the same window even if buffer is tighter

However, implementations vary, and robust senders must handle window shrinkage gracefully.

The receiver generates ACKs to inform the sender of successful reception. ACK generation strategy significantly impacts performance.

What the ACK communicates:

• ACK number: "I have received all bytes up to (ACK-1); send me byte ACK next"
• Window: "You may send up to [Window] bytes beyond byte [ACK-1]"
• SACK blocks (if enabled): "I've also received these out-of-order ranges"

Immediate vs. Delayed ACKs:

RFC 1122 allows ACKs to be delayed to improve efficiency:

RFC 1122 guidelines:

1. Delay at most 500ms: The delay should not exceed 500 milliseconds (many implementations use 40-200ms).
2. ACK at least every other segment: If two full-sized segments arrive, ACK immediately.
3. ACK out-of-order segments immediately: This triggers fast retransmit if a gap is detected.
4. ACK after timeout: Even if no new data arrives, ACK when the delay timer expires.

The duplicate ACK mechanism:

When an out-of-order segment arrives, the receiver:

1. Sends an ACK with the same ACK number as before (RCV.NXT hasn't changed)
2. This is a "duplicate ACK" from the sender's perspective
3. Multiple duplicate ACKs signal loss to the sender
4. Three duplicate ACKs trigger fast retransmit

When the receive buffer is completely full—typically because the application isn't reading data—the receiver advertises a zero window. This is a normal (if undesirable) condition that TCP handles gracefully.

How zero window arises:

1. Data arrives faster than the application reads
2. Receive buffer fills up
3. RCV.WND drops to 0
4. Receiver advertises window = 0
5. Sender stops transmitting (must respect the window)

Recovery from zero window:

1. Application reads data from buffer
2. Buffer space frees up
3. Receiver can now advertise window > 0
4. Problem: How does the receiver tell the sender?

The receiver's options for window reopening:

Window update segments:

A window update is an ACK segment with:

• ACK number = RCV.NXT (no new data acknowledged)
• Window = new, larger value
• No data payload

This segment serves only to inform the sender that the window has reopened.

Why window updates can fail:

Window updates are "pure ACKs" with no data. They are not retransmitted if lost:

• The sender never knows it was sent
• Without the update, sender waits for persist timer
• This adds latency but doesn't cause data loss

This is why the sender's persist timer is essential—it recovers from lost window updates.

Receiver behavior during zero window:

• Accept window probes (1 byte) and acknowledge them
• Continue processing data already in buffer
• Deliver in-order data to application when possible
• Update window when buffer space frees

The receiver should not simply ignore the sender; it must respond to probes to prevent permanent deadlock.

The ultimate purpose of the receive buffer is to deliver data to the application. This process affects window behavior and overall throughput.

Delivery semantics:

TCP delivers a stream of bytes to the application:

• No message boundaries (application must implement framing if needed)
• Always in order (out-of-order bytes wait for gaps to fill)
• Reliable (every byte delivered exactly once, or connection fails)
• No duplicates (even if network duplicates occurred)

The read system call:

When the application calls read() (or recv()):

1. TCP copies bytes from receive buffer to application buffer
2. Copied bytes are removed from receive buffer
3. Buffer space becomes available for new data
4. If enough space freed, receiver may advertise larger window

Push (PSH) flag handling:

The PSH flag tells the receiver to deliver buffered data to the application promptly rather than waiting for more. When TCP receives a segment with PSH set:

1. Add the data to the receive buffer (in order)
2. If contiguous data available, wake up the application
3. Deliver data immediately (don't wait for buffer to fill)

Blocking vs. non-blocking read:

In both cases, TCP delivers whatever contiguous data is available—it never delivers out-of-order or waits for more data when some is ready.