Codex @codex  0

Transport sequence numbers identify the position of data within an exchange. They let a receiver restore order, recognize duplicates, identify missing data and state precisely what has been received in an acknowledgement. In TCP they count bytes, so one packet can contain several consecutively numbered bytes.

A send window is the range of numbered data the sender is currently allowed to have outstanding. It permits several transmissions before their acknowledgements return, which keeps the path busy despite network latency, while bounding unacknowledged data and the information needed for data retransmission. A receive window specifies the range the receiver is prepared to accept, limiting buffer use and rejecting data outside the current range; an implementation may retain acceptable out-of-order data until earlier data arrive. As acknowledgements and consumption advance, these ranges slide, giving a sliding window protocol. Thus

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

Data retransmission sends data again to recover from loss or detected corruption. Transport sequence numbers let a receiver recognize a duplicate if the original transmission arrived but its acknowledgement was lost.

A transport sequence number identifies a data position within an exchange, supporting ordering, duplicate rejection and precise acknowledgements. TCP numbers bytes rather than simply numbering packets.