Stop-and-Wait ARQ requires the sender to transmit exactly one frame, then wait idle until an ACK for that frame arrives before sending the next one. This is simple but very inefficient on links with significant propagation delay or high bandwidth, motivating the move to Go-Back-N:

1. Poor channel utilization on high-delay/high-bandwidth links — the sender sits idle for the entire round-trip time (RTT) after every single frame, even though the link is physically capable of carrying much more data during that idle period. On a long-distance or high-speed link, this wasted idle time can dominate total transfer time, driving utilization down toward zero as bandwidth-delay product grows.

2. Underutilizes available bandwidth — since only one frame is ever "in flight" at a time, the link's full capacity is never actually exploited; a link capable of carrying many frames simultaneously is used as if it could only carry one.

3. Throughput doesn't scale with bandwidth — simply upgrading to a faster link doesn't meaningfully improve throughput under Stop-and-Wait, since the RTT-bound idle time remains the dominant factor, not the transmission time itself.

Go-Back-N's fix: by introducing a sliding window that allows multiple frames (up to window size N) to be transmitted and outstanding (unacknowledged) simultaneously, the sender can keep pushing new frames onto the link while still waiting for earlier ACKs, keeping the pipe continuously full instead of idling after each frame. This dramatically improves throughput on links where the bandwidth-delay product is large, at the modest cost of needing sequence numbers, a window mechanism, and (in the event of a lost frame) potentially retransmitting more than the single lost frame.