Windows — Flow Control and Window Scaling
Manja Arena releases a 200 MB pack of festival kite skins. The content server is in Mumbai, and a player in Singapore on 100 Mbit/s fibre watches the download crawl along at under 1 MB a second. Neither the server nor the fibre is slow. The limit is a single field in the TCP header.
The rule
Throughput ≤ window ÷ round-trip time.
TCP's receive window is its flow control. In every segment, each side advertises how many more bytes it can buffer, and the sender may have at most that many unacknowledged bytes in flight. If the receiver's buffer fills up, perhaps because the player's disk is busy, it advertises a window of 0 and the sender pauses, checking back now and then until space opens up.
So in each round trip the sender can push at most one window of data before it must wait for acknowledgments. That is the whole rule.
The window field is 16 bits, so on its own it can never exceed 65,535 bytes. For the player in Singapore, with a 70 ms round trip, that means 65,535 ÷ 0.07 ≈ 936,000 bytes a second: under 1 MB/s, about 7.5 Mbit/s, however fast the fibre is.
The fix is the window scale option. Both sides offer it in the SYN and SYN-ACK, each naming a shift count from 0 to 14, and from then on the window field is multiplied by 2 to that power. With a shift of 7, a field value of 8,192 means 8,192 × 128 = 1,048,576 bytes. Because it is agreed only during the handshake, a connection where either side left it out runs without scaling for its whole life.
A related handshake option, timestamps, has each segment carry a time value that the other side echoes back. That lets the sender measure the round trip precisely, and on very fast links it stops old segments with wrapped-around sequence numbers from being mistaken for new ones.
The receive window is not TCP's only brake. TCP also holds back to avoid overloading the network in between, called congestion control, which you meet again in the UDP section.
The shortcut
To find TCP's ceiling on a path, divide the window by the RTT in seconds. To find the window a path needs, run it backwards: window needed = target rate × RTT.
Find the ceiling
Without scaling: 65,535 bytes ÷ 0.07 s ≈ 0.94 MB/s. That is the crawl the player sees.
Drills
Answer fast — trust the rule.
Without window scaling, what is the largest receive window TCP can advertise?
The window is 65,535 bytes and the RTT is 50 ms. What is the most TCP can deliver per second?
A segment's window field says 1,000, and the connection agreed a scale shift of 7. What is the real window?
A player's receive buffer is full, so their side advertises a window of 0. What does the server do?
When is the window scale factor agreed?
Remember
- Throughput ≤ window ÷ round-trip time.
- Window needed = target rate × RTT; the scale option lifts the 64 KB cap.
- Trap: blaming the line or the server when the window is the real ceiling on a long path.