JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Reliable Delivery: ARQ and the Sliding Window

The last guide taught the receiver how to catch a corrupted frame. Now we close the loop: how does the sender find out, and how do we get every frame across a leaky link in order, without crawling? Meet acknowledgements, timers, and the sliding window that keeps the pipe full.

Detection is only half the job

In the previous guide we gave the receiver a superpower: with a checksum or a cyclic redundancy check, it can look at an arriving frame and tell, almost always, whether the bits got mangled in transit. But knowing a frame is bad is not the same as fixing the conversation. The receiver can silently drop the broken frame, yet the sender, sitting at the other end of the wire, has no idea anything went wrong. It already moved on to the next frame.

So the real goal of this guide is reliable delivery: every frame the sender hands over arrives at the receiver, exactly once, in the right order, even though the link underneath quietly corrupts some frames and drops others entirely. There are two broad ways to fight loss. One is to send so much redundancy that the receiver can repair damage on its own, forward error correction with codes like the Hamming code from the last rung. The other, far more common on data links, is to detect the problem and ask for the data again. That second approach is called automatic repeat request, or ARQ.

Stop-and-wait: the simplest honest conversation

The most basic ARQ scheme works exactly like a careful phone call where you say one sentence and wait for the other person to say "got it" before continuing. The sender transmits one frame, then stops and waits. The receiver checks the frame; if it passes the CRC, it sends back a tiny acknowledgement, an ACK, meaning "received, keep going." Only when the ACK arrives does the sender release the next frame. This is stop-and-wait, and it is beautifully simple.

But what if a frame, or its ACK, gets lost entirely? Then the sender waits forever. To break the deadlock, the sender starts a retransmission timer the moment it sends a frame. If the ACK does not arrive before the timer expires, the sender assumes the worst and retransmits. This single mechanism, a timer plus a retransmit, is the heartbeat of every reliable protocol you will ever meet, including TCP up at the transport layer.

There is a subtle trap. Suppose the frame arrived fine but its ACK got lost. The sender's timer fires and it resends the frame, so the receiver now gets the same frame twice and might count it twice, a duplicate. The fix is a one-bit sequence number: label frames 0, 1, 0, 1, and let ACKs name the number they are acknowledging. Now a duplicate frame 0 is recognised as a repeat and discarded, while its ACK is sent again. One bit of numbering turns a fragile scheme into a correct one.

The sliding window: keep the pipe full

The cure is to stop sending one frame at a time. Instead the sender is allowed a window, a fixed number of frames it may have in flight without yet being acknowledged. Picture a row of numbered frames and a frame that slides along over them: everything inside the frame may be sent now, everything to the left is already acknowledged and done, everything to the right must wait its turn. As ACKs come back from the left edge, the window slides rightward to expose new frames. This is the sliding window.

How big should the window be? Just big enough to keep the link busy until the first ACK returns. That magic number is the bandwidth-delay product: the link's data rate multiplied by the round trip time, which is how many bits fit "in the pipe" at once. For our 1 Gbps link with a 20 ms round trip, that is 1 Gbps times 0.02 s, about 2.5 megabytes, or roughly 1700 frames of 1500 bytes. Size the window to that and the sender never has to stop; it is always feeding new frames in as old ACKs flow back.

acknowledged | ------ window (in flight) ------ | not yet sent
  ... 4  5  6 [ 7   8   9   10  11  12 ]  13  14 ...
               ^ base                ^ next-to-send

ACK 7 arrives -> window slides one step right:
  ... 5  6  7 [ 8   9   10  11  12  13 ]  14  15 ...
               ^ base now 8; frame 13 becomes sendable
The window is the band of frames allowed in flight; each ACK at the left edge slides it right and frees a new frame to send.

Notice the sliding window quietly does two jobs at once. It keeps the link full for speed, and it also caps how much unacknowledged data is outstanding, which is a form of flow control: a slow receiver can shrink the window so a fast sender does not bury it. The same window machinery, scaled up to bytes instead of frames, is exactly what TCP uses far above us at the transport layer. Learn it here and you have already met a third of how TCP works.

When a frame is lost: go-back-N versus selective repeat

A window lets many frames fly at once, but it raises a hard question: when frame number 8 goes missing while 9, 10, and 11 already arrived safely, what do we do? There are two classic answers, and the difference between them is the difference between a blunt instrument and a scalpel.

Go-back-N is the blunt instrument. The receiver insists on perfect order and refuses to buffer anything out of sequence, so when 8 is missing it simply discards 9, 10, and 11 even though they arrived intact. Its ACKs are cumulative: "ACK 7" means "I have everything up through 7." When the sender's timer for frame 8 fires, it goes back and resends 8, 9, 10, 11, and everything else in the window, the whole tail. It is dead simple at the receiver (no buffering, no bookkeeping) but it can throw away good work and re-send frames that already made it.

Selective repeat is the scalpel. The receiver buffers the out-of-order frames 9, 10, and 11, and ACKs each frame individually. When the sender learns that only 8 is missing, it resends only frame 8. Once 8 finally arrives, the receiver slots it in front of the buffered three and delivers all four in order. This wastes far less bandwidth on a lossy link, at the cost of buffers and more careful bookkeeping at both ends, including per-frame timers.

Walking one frame through a loss

Let us trace the whole machine once, for a single dropped frame under selective repeat, so the pieces lock together. Watch how detection, the ACK, the timer, the sequence number, and the window all play their parts in one short story.

  1. The sender's window allows frames 8 through 13 in flight. It sends frame 8, starts a timer for it, then immediately sends 9, 10, and 11 without waiting, each with its own timer.
  2. Frame 8 is corrupted by noise on the link and fails its CRC at the receiver, so the receiver drops it. Frames 9, 10, and 11 arrive intact and pass their checks.
  3. The receiver buffers 9, 10, and 11 (it cannot deliver them yet, because 8 is still missing) and sends back ACK 9, ACK 10, ACK 11, each naming exactly which frame it holds.
  4. No ACK 8 ever comes back, so the sender's timer for frame 8 expires. It resends only frame 8, leaving 9, 10, and 11 alone since their ACKs already arrived.
  5. The resent frame 8 arrives clean. The receiver now has 8, 9, 10, 11 in a row, delivers all four upward in order, slides its window forward, and sends ACK 8. The gap is healed with one retransmission, not four.

That is the entire idea of reliable delivery in one trace. Notice nothing here is magic: a number on each frame, an acknowledgement that names it, a timer that fires when an answer is overdue, and a window that decides how many frames may be unanswered at once. Master this small set of moving parts and you have the mental model for TCP, for reliable links inside Wi-Fi, and for any protocol that promises to get your data across a world that keeps dropping it.