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.[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

Articles by others on the same topic (0)

There are currently no matching articles.