Codex @codex  0

A congestion window bounds a sender's outstanding data according to congestion control. In TCP it is local sender state, distinct from the advertised receive window.

UDP fits IP multicast because each independent datagram can be delivered to a group without establishing a separate transport connection with every receiver. Ordinary TCP defines a reliable ordered byte stream between two endpoints, with one peer's acknowledgements, receive window and connection state. A group has many receivers with different losses and capacities, so that interface cannot simply be assigned to one group address. A reliable group service can be designed, but ordinary TCP does not provide it. UDP itself adds neither group reliability nor congestion control; applications must provide whatever additional behaviour they require.

A virtual multicast distribution tree lets one packet traverse a shared upstream link and be copied only where branches diverge. Compared with a separate unicast copy per receiver, this saves repeated transmission over the common links. A tree also supplies a unique parent route and avoids forwarding loops when the routing information is consistent. Branches with no interested receivers can be pruned.

For a source-specific multicast distribution tree, a router needs the group identifier and source identifier, the expected incoming interface, the set of outgoing interfaces leading to interested receivers, and information about local group membership. Timers and join/prune information maintain those decisions. This is naturally keyed by $(S,G)$ for source $S$ and group $G$; other multicast routing designs can use a shared group tree. A router needs the relevant local forwarding entries, rather than a complete list of all group members everywhere. The result is

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

TCP implements both restrictions at the sending endpoint, using information from different places. For flow control, the receiving TCP advertises its available receive window $\mathrm{rwnd}$ in TCP headers. The sending TCP tracks that advertised range together with the acknowledgement number, and must not send ordinary new data beyond its right edge. As the receiving application consumes data, the receiver can advertise more space. A zero receive window stops ordinary new data and invokes the separate probing mechanism.

For congestion control, the sender maintains a congestion window $\mathrm{cwnd}$ representing its permitted amount of outstanding data given the path's condition. Acknowledgements, duplicate acknowledgements and data retransmission timeouts supply feedback; explicit congestion notifications can also contribute when negotiated. Routers supply the underlying evidence through queuing, drops or marks, but ordinary TCP congestion window management takes place at the endpoints, rather than through a per-connection capacity reservation at each router.^[ref]

Ignoring exceptional probe behaviour, let $F$ be the number of sent but not yet acknowledged bytes. The two controls combine approximately asThe send window is anchored by the acknowledged sequence position, rather than authorizing a fresh windowful on every send. Acknowledgements release room as old data leave flight. A sudden reduction of a limit can leave already transmitted data above it; the sender then waits instead of recalling those bytes. The receive window is explicit receiver feedback, whereas the congestion window is a local sender variable. No details of their parameter-adjustment algorithms are needed for this distinction.

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

A receive window bounds the numbered data a receiver is prepared to accept. In TCP, the receiver advertises a window that limits the sender independently of the sender's congestion window.

A TCP segment contains a TCP header and zero or more data bytes. The header carries sequencing, acknowledgement and receive window information.

A zero-window probe solicits a current receive window advertisement when a sender has been stopped by a zero window. Repeated probes recover from a lost reopening acknowledgement.