Summary

  • Zero-window probing prevents a lost window-opening update from leaving both TCP peers waiting forever.
  • Persist keeps transport state recoverable; the operating system and application still decide when waiting has become too costly.

Imagine a receiver whose application has stopped reading. Its buffer fills, so TCP advertises a receive window of zero. The sender obeys and stops transmitting ordinary data. Later, the application drains the buffer and the receiver sends an acknowledgement carrying a larger window. If that acknowledgement disappears, the receiver believes it has announced new capacity while the sender still believes no capacity exists. Neither side has a new data segment it is naturally compelled to send. A flow-control pause has become a knowledge failure.

TCP's answer is the zero-window probe. Even while the window is closed, the sender periodically transmits or retransmits enough to make the receiver answer. That acknowledgement restates both the next expected sequence number and the current receive window. The probe does not create buffer space, and it does not overrule the receiver's advertised limit. It supplies another opportunity for the sender to learn that the limit has changed.

The idea was present in TCP's original specification. RFC 793 required a sending TCP to retransmit regularly even when the window was zero and required a receiver with a zero window to acknowledge an arriving segment with its current window. The document explained the control purpose directly: reopening the window had to be reported reliably. Its suggested interval belonged to the early specification; the durable mechanism was the forced restatement of state.

RFC 1122 made the requirement sharper in 1989. Zero-window probing had to be supported because acknowledgement-only segments are not reliably transmitted in their own right. Without a probe, losing the acknowledgement that reopens a window can leave a connection hung forever. The host requirements recommended sending the first probe after one retransmission-timeout period and increasing the interval between later probes exponentially. This made the recovery attempt prompt enough to repair a lost update while limiting how aggressively a long pause consumed network attention.

The same text exposed an important boundary. A receiving TCP may keep its offered window closed indefinitely. As long as it continues acknowledging probes, the sender must permit the connection to remain open, subject to the application's user-timeout policy. The classic example was mundane rather than malicious: a printer daemon might stop consuming data because the printer had run out of paper. Transport could preserve the connection until the external problem was fixed, instead of mistaking lack of buffer space for proof that the peer had failed.

That sender state became commonly known as the persist condition. RFC 6429 revisited it in 2011 because indefinite protocol patience can also hold memory, queued response data and connection state indefinitely. A peer can advertise zero and keep acknowledging probes, leaving a busy sender responsible for resources that make no application progress. The clarification did not replace persist with a protocol-authored deadline. It stated that operating systems and applications could still reclaim resources or close such connections by ordinary policy.

RFC 9293 carries the arrangement into the consolidated current TCP specification. Zero-window probing remains mandatory. The receiver still acknowledges a probe with its next expected sequence number and present window; the sender should begin after an RTO interval and increase later intervals exponentially. The modern specification also retains the resource-management qualification. What survived was not a promise to wait forever under every policy, but a rule that flow-control state must remain recoverable while the connection is kept.

The mechanism therefore turns an unreliable control update into a repeatable observation. A window advertisement may be lost, but the sender does not have to infer a permanent zero from silence. It can elicit another sequence-space-consistent statement of the receiver's current state—protocol evidence, not endpoint authentication and not evidence that the receiving application is healthy.