Two engineers argue about whether a link "uses credits" or "uses a window". Both describe a sender that may send a limited amount ahead and must then wait to hear back. They are describing two different mechanisms that obey the same law, and the difference matters as soon as a packet is lost.
What is a sliding window, and how is it different from credits?
It is tempting to treat "window" and "credits" as two names for one idea, since both cap the data in flight. But they count different things and are freed by different events. Credits count free slots in the receiver's buffer and come back when a slot empties. A window counts data sent but not yet acknowledged and slides forward when acknowledgements arrive. Conflating them leads to systems that either overflow (a window that slides on acknowledgements while the receiver's buffer is still full) or stall (credits withheld for data that was lost and will never arrive).
In window flow control the sender may have at most W units sent but not yet acknowledged. Each acknowledgement covers some data and lets the window slide forward, allowing that much new data. The receiver acknowledges data when it has received it correctly, which is why windows sit naturally alongside reliability (Part 10): the same acknowledgements that confirm delivery also release the window.
The throughput law is the same as for credits. Each unit of window can be used at most once per acknowledgement round trip:
Set the window and the acknowledgement round trip, then step through 32 packets. To see what a window does when a packet is lost, pick a packet to lose: its acknowledgement never arrives, the window fills and stops, and after a timeout the sender goes back and resends from the lost packet (go-back-N, lesson 10.12).
Loading sliding window…
Credits | Window | |
|---|---|---|
Counts | Free slots in the receiver's buffer | Data sent but not yet acknowledged |
Released when | A slot empties (the consumer took the data) | An acknowledgement arrives (the data was received) |
Protects against | Receiver buffer overflow | Too much data outstanding (for replay buffers, sequence numbers, or the network) |
Usual scope | One hop | End to end, or one link's reliability layer |
If data is lost | Its credit is never returned unless the protocol handles it | It is never acknowledged; a timeout or NAK replays it, and the window waits |
Sizing law | B ≥ bandwidth × credit RTT | W ≥ bandwidth × acknowledgement RTT |
Many links use both. A reliable link layer has a window (bounded by its replay buffer and sequence numbers, lesson 10.10), and the receiver's buffers are protected by credits. The window answers "how much might I have to resend?"; the credits answer "how much room does the receiver have?".
Use | Choose | Because |
|---|---|---|
Protect a receiver's buffer on a lossless hop | Credits | Exact, and released by the event that matters (a slot freeing) |
Bound data that might need resending | A window | Released by acknowledgements, which reliability needs anyway |
End-to-end flow over a lossy network | A window, with the receiver advertising how much it can take | No per-hop control is available end to end |
Protocol | Window or credits |
|---|---|
PCI Express | Both, at different layers: credits at the transaction layer protect receiver buffers; the data link layer's replay mechanism limits unacknowledged packets with its sequence numbers and replay buffer (lesson 10.11). |
TCP over Ethernet | An end-to-end window: the receiver advertises how much it can accept, and the sender keeps no more than that unacknowledged. |
A link sizes its replay window for the acknowledgement round trip but forgets that the receiver's buffers are smaller than the window (illustrative). The receiver acknowledges each packet when it arrives intact, but its buffer is full because its consumer is slow. The window keeps sliding on acknowledgements, packets keep arriving, and the receiver must drop them, which triggers replays, which arrive at a still-full buffer. Acknowledging correct receipt is not the same as having room; the fix was credits on the receive buffer alongside the window.
32/64 = 50% of the link.
Its window is released by acknowledgements, which a reliable protocol sends anyway to confirm delivery; and the unacknowledged data is exactly what must be kept for possible replay.
Not the window, which slides on acknowledgement. The receive buffer needs its own flow control, such as credits.
A window limits data sent but not yet acknowledged; acknowledgements slide it forward.
Credits count receiver slots freed by consumption; windows count data freed by acknowledgement. Both obey throughput ≤ amount / round trip.
Reliable links often need both: a window for replay, credits for the receiver's buffers.