= Solution
The decisive difficulty is that a <TCP> <receive window> update is not itself delivered by a reliable notification channel. The receiver can advertise a newly nonzero <receive window>, but the <packet> carrying that advertisement can be lost. With the sender stopped and the receiver expecting more data, neither side need send anything else. The sender can then wait forever despite available receiver space.
A <TCP> <acknowledgement> containing only an updated <receive window> does not occupy new sequence space that would make its loss trigger normal <data retransmission>. Requiring an <acknowledgement> of every such notification would introduce a separate reliability rule; that new <acknowledgement> can itself be lost. Some participant still needs a timer and retry rule. Reordering can also deliver stale advertisements, so <transport sequence number> and <acknowledgement> checks are needed in addition to merely sending a notification.
The <persist timer> assigns the repeated enquiry to the side that has data waiting: the sender periodically sends a <zero-window probe>, eliciting an <acknowledgement> with the receiver's current <receive window>. If one enquiry or response is lost, a later attempt can succeed. Receiver window updates remain useful for prompt resumption; probes provide recovery when those updates disappear.<Requirements for Internet Hosts - Communication Layers (RFC 1122)>[§4.2.2.17: zero-window probing prevents indefinite hangs when a reopening ACK is lost]{ref}
One could instead specify repeated receiver notifications, a response and suitable timers, but that replaces the recovery mechanism rather than eliminating its purpose. Therefore
$$
\boxed{\text{a lost reopening notification can deadlock the exchange; timed retries are needed}.}
$$
Back to article page
