The central problem
Match sending to receiving.
A sender can produce bytes faster than the receiving application can read them. The receiver therefore advertises a receive window: the amount of additional data it can accept without overflowing its buffer.
As the application consumes data, the receiver acknowledges progress and can advertise a larger window. As the buffer fills, the window shrinks. A zero window tells the sender to pause until capacity returns.
Build the model
Four useful signals
Receive window
Advertises how much data can be accepted.
Buffer
Temporarily holds data while the application reads it.
Backpressure
Signals that the sender must slow down.
Acknowledgement
Confirms which data has arrived.
Separate the limits
The sender respects the receiver and the path.
The receive window describes endpoint capacity: how much data the receiver can buffer. The congestion window describes an estimate of what the shared path can carry safely. TCP's in-flight data is limited by the smaller of these two windows.
Loss, increasing delay, or repeated retransmissions can indicate congestion. The sender then reduces its sending rate and probes again gradually. This protects routers and links from a growing queue; it is different from a zero receive window, which means the endpoint itself has no room.
Mini experiment
Follow the receive window
Select the receiver state and observe what the sender is allowed to do.
The receiver has room for eight more units. The sender may keep transmitting within that advertised limit.
The receiver can accept more data without overflowing.
Knowledge check
Test your model
Answer five questions.