Go-Back-N keeps the pipe full. Instead of one frame at a time, the sender may have a whole window of up to N unacknowledged frames in flight — this pipelining is what fixes Stop-and-Wait's idle link. The trick is a deliberately dumb receiver: it accepts frames strictly in order and discards anything that arrives early.
How it runs
1Sender fires off frames 0,1,2,… up to its window size N without waiting for individual ACKs.
2Receiver delivers frames in order and replies with a cumulative ACK: ACK 3 means 'everything through frame 3 arrived'.
3Each ACK slides the window forward, letting new frames enter.
4If a frame is lost, the receiver discards every later frame (they're out of order) and keeps re-acking the last good one.
5When the sender's timer for the lost frame expires, it goes back and resends that frame and all frames after it in the window.
Receiver window = 1
Go-Back-N's receiver buffers nothing out of order — its window is exactly 1 (the next frame it expects). That's why a single loss is expensive: frames that already arrived fine get thrown away and retransmitted just because they came *after* the gap.
Sender window ≤ 2^m − 1
With m-bit sequence numbers there are 2^m numbers, but the sender window must stay ≤ 2^m − 1. If it were the full 2^m, a window of all-duplicate retransmissions could look identical to a window of brand-new frames, and the receiver couldn't tell them apart.
The result: fast on a clean link (the window keeps it busy), but wasteful when frames are lost, because every loss drags its successors back with it.
OperationTimeSpace
On one lost frame · receiver discards out-of-order; cumulative ACKsresend up to N framessender N · receiver 1
Check yourself
Frame 2 is lost but frames 3, 4, 5 reach the receiver fine. What does Go-Back-N do?
