Stop-and-Wait ARQ: Working Principle and Protocol Diagram
ARQ protocols improve reliability by detecting lost/corrupted frames and retransmitting them. A classic ARQ strategy is the Stop-and-Wait ARQ protocol: the sender transmits a single frame and then pauses until it receives a positive acknowledgment (ACK) or a timeout triggers retransmission.
Key idea: at any time, the sender has at most one outstanding unacknowledged frame, so the protocol is simple but can be inefficient on high-delay links.
Conceptual timeline (Stop → wait → repeat)
The receiver uses checksum/FCS (or equivalent) to decide whether a frame is valid; if valid, it replies with an ACK for that frame; otherwise it effectively discards the frame and does not acknowledge it.
Because the sender may retransmit, the protocol commonly uses a 1-bit sequence number (e.g., 0/1 alternating) so the receiver can distinguish a new frame from a duplicate retransmission.
Stop-and-Wait ARQ typically assumes:
- the receiver can detect errors (corruption) in frames,
- ACKs may be lost (so timeouts are needed at the sender),
- the sender retransmits after timeout,
- the alternating sequence bit prevents incorrect acceptance of duplicates.
Note: “Stop-and-Wait” is named because the sender stops sending new data until the current one is confirmed.
Footnotes
-
Stop-and-Wait ARQ - Wikipedia - Defines the Stop-and-Wait ARQ concept and core behavior (send one frame, wait for ACK, retransmit on timeout). ↩
-
Automatic repeat request (ARQ) - Wikipedia - Background on ARQ reliability via acknowledgments, retransmissions, and sequence numbering to handle duplicates. ↩
Working of Stop-and-Wait ARQ (Sender + Receiver)
- 1Step 1
Sender transmits a single DATA frame tagged with a sequence number (often 0/1) and then starts a timer.
- 2Step 2
Receiver uses a checksum/FCS to detect corruption. If corruption is detected, the receiver discards the frame (no ACK).
- 3Step 3
If the frame is valid: if its sequence number matches what the receiver expects, receiver delivers it to the upper layer and sends ACK(seq). If it is a duplicate, receiver re-ACKs the last correctly received sequence to help the sender recover.
- 4Step 4
If the sender receives ACK(seq) before the timer expires, it stops the timer, advances the sequence number (e.g., toggles 0↔1), and sends the next DATA frame.
- 5Step 5
If the timer expires (e.g., DATA was lost, ACK was lost, or ACK was corrupted), sender retransmits the same DATA frame with the current sequence number.
- 6Step 6
Because retransmissions may arrive after ACK loss, the receiver uses the sequence bit to avoid delivering the same data twice; it only delivers when it sees the expected sequence number.
Why the protocol needs a sequence number
Without a sequence number, a receiver can’t always tell whether a retransmitted DATA frame is “new” or merely a duplicate of the last correctly received one. With a 1-bit alternation, the receiver knows whether it has already delivered that DATA payload and can respond accordingly.
This is essential under these failure modes (explicitly handled by Stop-and-Wait):
- Lost DATA frame: sender times out and retransmits; receiver accepts and ACKs.
- Lost/garbled ACK: sender times out and retransmits even though the receiver may have already accepted the frame; receiver recognizes duplicate and re-ACKs without re-delivering.
- Corrupted DATA frame: receiver discards; sender times out and retransmits.
Footnotes
-
Stop-and-Wait ARQ - Wikipedia - Defines the Stop-and-Wait ARQ concept and core behavior (send one frame, wait for ACK, retransmit on timeout). ↩
-
Automatic repeat request (ARQ) - Wikipedia - Background on ARQ reliability via acknowledgments, retransmissions, and sequence numbering to handle duplicates. ↩
Pro Tip: Choose the timeout carefully
"The sender’s timeout should exceed the typical round-trip time (RTT) plus enough margin to avoid premature retransmissions. Too small a timeout increases duplicate traffic; too large slows recovery from actual losses. (Protocol designers often estimate RTT or use adaptive timers.)"
Footnotes
-
Transmission Control Protocol (TCP) - Retransmission timers (overview) - RFC 6298 reference context - Discusses RTT estimation and retransmission timeouts, relevant to why timeouts must be set carefully. ↩
Warning: Stop-and-Wait can be inefficient on high-latency links
"Since the sender waits for an ACK before sending the next frame, the maximum utilization is limited when propagation delay is large. Pipelining (e.g., Go-Back-N or Selective Repeat) improves throughput by allowing multiple outstanding frames."
Footnotes
-
ARQ families throughput intuition (Go-Back-N, Selective Repeat) - Wikipedia - Compares ARQ schemes and motivates why pipelining improves throughput compared to Stop-and-Wait. ↩
Stop-and-Wait ARQ (Message Life Cycle)
Send DATA(seq=i)
t0Sender transmits exactly one DATA frame and starts a timer."
Receiver validates
t1Receiver checks integrity and decides whether to accept or discard; ACK decision follows."
ACK handling at sender
t2If ACK(seq=i) arrives before timeout, stop timer and toggle sequence bit."
Timeout & retransmit
t3If ACK doesn’t arrive in time, retransmit the same DATA(seq=i). Receiver uses the sequence bit to avoid duplicate delivery."
Relationship to throughput (intuition)
Stop-and-Wait’s throughput depends on RTT relative to transmission time. A common way to reason: the sender can’t send the next frame until it gets ACK, so useful work is punctuated by waiting for confirmation. This makes the protocol throughput lower than pipelined ARQ methods when RTT is large.
You can view Stop-and-Wait as “one in flight,” whereas more advanced ARQ schemes allow multiple outstanding frames. This is why Stop-and-Wait often appears in introductory reliability discussions and small/simple systems.
Footnotes
-
ARQ families throughput intuition (Go-Back-N, Selective Repeat) - Wikipedia - Compares ARQ schemes and motivates why pipelining improves throughput compared to Stop-and-Wait. ↩ ↩2
Common questions and edge cases
Knowledge Check
In Stop-and-Wait ARQ, what does the sender do after transmitting a DATA frame?