Stop-and-Wait ARQ

Send one frame, wait for its ACK, then send the next — the simplest reliable protocol, but slow on long links.

Stop-and-Wait is the simplest ARQ (Automatic Repeat reQuest) scheme: send a single frame, then stop and wait for the receiver's ACK before sending anything else. Only one frame is ever in flight. If the ACK doesn't return before a timer expires, the sender assumes loss and retransmits.

The loop

1Send frame 0 and start a retransmission timer.
2Receiver gets it, delivers it, and replies ACK 0.
3Sender gets the ACK, stops the timer, and sends frame 1.
4If the timer fires first (frame or ACK was lost), resend the same frame.

You need sequence numbers — even just one bit

If an ACK is delayed and the sender times out, it resends a frame the receiver already has. A 1-bit sequence number (alternating 0,1,0,1…) lets the receiver spot and discard the duplicate, and lets the sender match each ACK to the frame it acknowledges. Without it, a lost ACK silently duplicates data.

Why it's slow on a long link

After sending a frame, the sender does nothing until the ACK returns — roughly one round-trip time (RTT) later. With transmission time Tframe and one-way propagation Tprop, useful work happens only for Tframe out of every Tframe + 2·Tprop. Writing a = Tprop / Tframe, efficiency is `1 / (1 + 2a)`.

Plug in numbers: a 1 ms frame on a link with 20 ms one-way propagation gives a = 20, so efficiency = 1 / (1 + 40) ≈ 2.4%. The link sits idle ~97% of the time. That single fact is why pipelined windows (Go-Back-N, Selective Repeat) exist.

OperationTimeSpace

Link efficiency · a = Tprop / Tframe; one frame outstanding at a time1 / (1 + 2a)1 frame

Check yourself

On a high-latency link, why does Stop-and-Wait waste most of the link's capacity?