Moving from Stop-and-Wait ARQ to Go-Back-N ARQ: Reasons and Performance Implications

Stop-and-wait ARQ (stop-and-wait ARQ ) is correct and simple, but it can be inefficient on real links with non-trivial propagation delay. The core reason is that after sending a frame, the sender is idle while it waits for the ACK to return—meaning the channel can’t stay fully utilized. Wikipedia notes that stop-and-wait throughput is reduced because the time between successfully received data and the next transmission is about twice the transit time when turnaround is negligible.

Go-Back-N ARQ (Go-Back-N ARQ ) addresses this by using a sliding window: the sender can transmit multiple frames without waiting for an ACK after each one. Specifically, Go-Back-N is a sliding-window protocol with transmit window size $N$ and receive window size $1$, allowing the sender to send $N$ frames before requiring an ACK.

A helpful way to visualize the difference:

Key learning terms for this section: throughput , pipeline , sliding window , cumulative ACK , retransmission.

1) Stop-and-wait wastes link capacity due to ACK turnaround time

In stop-and-wait ARQ, the sender sends exactly one frame, then blocks until it receives the corresponding ACK (or a timeout occurs and it retransmits). Wikipedia emphasizes that this makes stop-and-wait inefficient because time spent waiting for ACK reduces the fraction of time the channel is actually used.

GeeksforGeeks similarly states the low efficiency comes from waiting for acknowledgments before transmitting the next frame, which leads to poor utilization—especially on high bandwidth and high delay links (the bandwidth–delay product effect).

Throughput/efficiency intuition (why pipelining helps)

Go-Back-N’s sliding-window pipelining reduces the “idle fraction” by allowing the sender to transmit multiple frames during what stop-and-wait would use as waiting time. Go-Back-N is explicitly described as more efficient because the connection remains utilized while packets are being sent instead of idling for each ACK.

2) Go-Back-N increases “in-flight” frames using a sender window

Stop-and-wait has effectively a sender window size of 1; Go-Back-N increases the sender window to $N$, enabling multiple frames to be transmitted before the first required ACK event.

Wikipedia: Go-Back-N can transmit $N$ frames before requiring an ACK, and it is a sliding-window instance with transmit window size $N$ and receive window size $1$.

GeeksforGeeks adds implementation behavior: the sender maintains a sliding window of size $N$, can transmit up to $N$ frames without waiting for individual ACKs, and advances (“slides”) the window when ACKs arrive.

This matters because many networks are latency-limited: even if the link can transmit frames quickly, stop-and-wait forces a stop after each frame, preventing utilization from reaching its potential.

3) Efficiency gains can be expressed mathematically (window size vs delay ratio)

A common textbook-style efficiency result for Go-Back-N (ignoring processing/queuing/ACK transmission delay) is:

where $a = \frac{T_p}{T_t}$ is the propagation-to-transmission delay ratio. GeeksforGeeks states the same form for ideal conditions and also discusses adding extra delay terms for non-ideal cases.

For stop-and-wait, many treatments derive a baseline efficiency of:

Scaler Topics provides this stop-and-wait formula and the Go-Back-N one as a direct comparison.

Why this is the practical reason to move: as $N$ grows, the numerator increases linearly, improving efficiency (hence throughput) on links where $a$ is significant (i.e., propagation delay isn’t negligible).

4) Go-Back-N uses cumulative ACKs to reduce control overhead

Another performance reason is acknowledgment strategy.

GeeksforGeeks notes that Go-Back-N uses cumulative ACKs, where a single ACK confirms receipt of all frames up to a particular sequence number. This reduces ACK traffic compared with schemes that must acknowledge each frame independently (like selective repeat).

So moving to Go-Back-N typically improves:

• data-to-control ratio (fewer ACKs needed to convey “how far we got”),
• effective throughput under realistic workloads.

5) Trade-off: Go-Back-N may retransmit more data after a loss

The above improvements come with a known cost: when a frame is lost (or its ACK is lost), Go-Back-N “goes back” and retransmits the unacknowledged frame and all subsequent frames in the window, even if some arrived correctly.

Wikipedia explicitly states this downside: if any frame was lost/damaged or the ACK acknowledging them was lost/damaged, then that frame and all following frames in the send window are re-sent.

GeeksforGeeks provides the concrete receiver-side rule: the receiver discards out-of-order frames and expects the next exact sequence number; then on timeout, the sender retransmits from the missing frame onward.

Therefore, the “reason to move” is contextual

• On high-delay paths or where stop-and-wait would leave the sender idle, pipelining improves utilization substantially.
• On high-error-rate paths, Go-Back-N’s extra retransmissions can reduce the net gain; selective repeat often performs better there (but is more complex).