Summary

  • A zero receive window is a valid instruction that the receiver currently has no capacity for new bytes. It is not proof that the peer, path or application has failed.
  • Because a pure ACK carrying a reopened window is not reliably retransmitted, the sender must occasionally probe even while the advertised window is zero. The reply restores an observable current window without granting permission for a normal data flight.
  • As long as probes are acknowledged, TCP must allow the connection to remain open; RFC 6429 nevertheless preserves application and operating-system authority to reclaim local resources and abort explicitly.

The deadlock began with two correct silences

Imagine a sender with more bytes queued and a receiver whose application has stopped reading. The receive buffer fills. The receiver advertises a window of zero. The sender obeys and stops transmitting new data.

Later the application consumes some buffered bytes. The receiver sends an ACK with a nonzero window. If that packet arrives, work resumes. If it is lost, neither endpoint has violated TCP. The sender still holds a valid zero-window report and has no ordinary data permission. The receiver has already announced new capacity and may have no new data to acknowledge. Two correct silences can therefore preserve the wrong shared fact forever.

RFC 1122 states the danger directly: ACK-only segments are not reliably transmitted. Without zero-window probing, loss of the window-opening ACK can leave a connection hung indefinitely. Reliability therefore required more than retransmitting unacknowledged payload. It required a way to recover permission itself.

The window was permission, not a diagnosis

RFC 813 described the receive window as a flow-control tool. The receiver reports, approximately, how much buffer capacity it is prepared to accept. The sender derives a usable window after subtracting data already in flight.

That number has a narrow authority. Zero means no new bytes may be sent under the ordinary window. It does not say why capacity vanished. A process may be slow, paused, back-pressured or waiting for a human. The host and network may be functioning perfectly.

The standards' durable example is mundane: a printer runs out of paper, so the printer application stops taking data. The pause can last minutes, hours or days. Treating zero as a transport failure would convert an application condition into a connection verdict without evidence.

Nor is the receive window the congestion window. One expresses how much the endpoint can accept; the other limits how much the path should be asked to carry. A receiver can have no space on an uncongested path, or ample space while the network is congested. Combining those signals would give the wrong layer authority over the wrong condition.

One exceptional octet asked for current truth

RFC 793 supplied the original machinery, and the consolidated RFC 9293 preserves it. A sender with a zero window regularly transmits at least one octet of new data if available, or retransmits, to probe the receiver. The receiver answers with an ACK showing its next expected sequence number and current window.

The exception is easy to misdescribe. The probe does not revoke the receiver's control or authorize a window's worth of traffic. It sends a bounded question that the zero-window receiver must answer. If capacity is still zero, the ACK confirms zero. If capacity has reopened, the ACK carries the new permission that the earlier lost update failed to deliver.

The first probe should follow after the window has remained zero for one retransmission-timeout period. Later probes should use exponential backoff. That timing responds quickly to a single lost update without turning a long legitimate pause into constant polling. The standards intentionally avoid one universal maximum interval.

An answered zero was evidence of presence

RFC 1122 permits a TCP to keep its offered receive window closed indefinitely. As long as the receiver continues acknowledging probes, the sender's TCP must allow the connection to stay open.

This rule does not promise progress. It preserves the meaning of the evidence. An acknowledged probe shows that a peer TCP and a return path responded with a current report. It does not show that the application is healthy, that a human will add paper, or that the sender can afford to retain its queue forever.

The distinction matters operationally. A missing response raises uncertainty about the peer or path. An ACK reporting zero is affirmative evidence that the peer remains present while withholding capacity. Applying the same timeout verdict to both would discard information the protocol worked to recover.

Persistence did not create a right to memory

The indefinite-language rule was later misread as a ban on local resource reclamation. RFC 6429 corrected that interpretation without changing the transport contract. An application or operating system may request that a connection be aborted, including one in the persist condition, and TCP must comply.

The document showed why the distinction is necessary. Many clients can request large responses, stop reading, advertise zero windows and keep acknowledging probes. A server then retains queued response data and connection state for peers that are cheap to maintain remotely but expensive locally. Enough such connections can exhaust TCP buffers and control blocks.

A universal hidden transport timeout is not the answer. It cannot know whether the connection is a legitimate print job, a contractual long-running transfer or a hostile resource hold. The layer that knows the service commitment, tenant, queue cost and deadline must own the abort decision. TCP keeps the shared conversation coherent; local policy decides whether continuing it remains worthwhile.

Reopening too little created another trap

Reliable reopening is not sufficient if the receiver releases capacity in unusably small pieces. RFC 813 documented Silly Window Syndrome, a stable pattern in which small window increments generate small segments, more acknowledgments, higher CPU cost, loss and retransmission. The memo reported severe field cases, but those measurements are examples rather than universal performance constants.

Receiver-side avoidance deliberately withholds tiny increases until a useful amount can be announced. Sender-side avoidance resists transmitting tiny pieces merely because the right edge moved slightly. RFC 9293 requires both forms and treats Nagle's algorithm as complementary: Nagle addresses small application writes, while SWS avoidance addresses small movements of permission.

Persist and SWS avoidance therefore protect opposite boundaries. The receiver should not chatter every time it frees a handful of bytes. Once it announces a meaningful reopening, however, the sender must be able to rediscover that fact if the announcement vanishes.

The smallest shared mechanism preserved local choice

The history runs from a mechanism in RFC 793, through the performance analysis of RFC 813, the host requirements of RFC 1122, the resource-authority clarification of RFC 6429 and the consolidated rules of RFC 9293. The enduring design was not a timer value. It was a division of responsibility.

The receiver controls current capacity. The sender's TCP maintains a sparse method for learning when that capacity changes. The sending application and operating system decide how much state, time and money they will commit while waiting.

This is why TCP learned to persist at zero without promising to wait at any cost. A protocol can make permission recoverable without turning the grantor into the owner of another machine's resources.

Sources and limits

The evidence set is RFC 793, RFC 813, RFC 1122, RFC 6429 and RFC 9293. These documents establish semantics and stated risks, not current defaults for every operating system, present attack prevalence or the health of any specific application.