Summary

  • TCP's 16-bit Window field states how many data octets, beginning at the acknowledgment number, the segment sender is currently willing to accept.
  • The field creates a moving right edge of acceptable sequence space; it does not state total buffer memory or the sender's congestion window.
  • TCP tracks which segment supplied the latest window update so stale traffic cannot simply replace newer receiver credit.

A quantity attached to a frontier

RFC 793 defines the Window field in one sentence with unusually dense consequences. It is a 16-bit count of data octets, beginning with the octet indicated by the acknowledgment field, that the sender of the segment is willing to accept. RFC 9293 preserves the definition.

The two fields therefore work together without meaning the same thing. The acknowledgment number identifies the next sequence position expected from the peer. The Window value extends forward from that point. Their sum describes the advertised right edge: the farthest ordinary new data position currently covered by the receiver's grant.

This is a moving boundary. When the receiver accepts more data and its acknowledgment frontier advances, a later advertisement can move the acceptable range with it. A Window value of 4,000 is not a permanent capacity label. It is credit measured from the frontier carried in that segment.

Permission, not a memory inventory

The wording “willing to accept” matters. The field is an operational permission sent by the receiving side of one data direction. It need not equal all memory allocated to the connection, all free application buffer space or the amount the application has consumed. Those implementation facts may influence the advertisement, but the wire field states the resulting sequence-space allowance.

It is also separate from the congestion window. The advertised receive window protects the receiver from being sent more data than it is prepared to accept. The congestion window belongs to the sender's response to network conditions. Actual sending is constrained by both, but one value cannot stand in for the other.

The original 16-bit width limited the directly encoded count. RFC 9293 notes that the value is shifted when Window Scale is used. That extension changes range, not the base meaning of a grant beginning at the acknowledgment frontier.

A moving grant needs ordering

Window advertisements travel in packets that can be delayed, duplicated or reordered. If a sender accepted every arriving Window value as the newest truth, an older segment could overwrite a later grant.

RFC 793's transmission-control-block variables expose the defense. SND.WND records the send window, while SND.WL1 and SND.WL2 remember the sequence and acknowledgment numbers of the segment used for the last window update. Incoming advertisements are evaluated against that ordering context. The field is therefore not just a number; it participates in a stateful rule for deciding which grant is current.

This also explains why a zero value does not itself end the connection. It says the receiver grants no ordinary new-data credit at that moment. Recovery from a lost reopening advertisement is the separate Persist mechanism; policies for avoiding inefficient tiny advertisements are the separate Silly Window Syndrome problem.

What the field cannot certify

An advertised window does not prove end-to-end bandwidth, application progress or durable delivery. It reports a receiver-side transport allowance at one point in the connection's evolving state. Network congestion may impose a tighter limit, and implementation policy may change the next advertisement.

The historical achievement is narrower and more durable. TCP represented flow-control authority as a numbered boundary that could advance, contract or temporarily close without changing the connection identity. By anchoring a quantity to the acknowledgment frontier and ordering updates, the protocol made receiver permission travel with the same sequence-space evidence that located it.

Sources