Stop-and-Wait ARQ Retransmission Conditions: Sender Behavior Under ACK, Window, and Timeout Events

Stop-and-Wait ARQ is an error-control and flow-control scheme where the sender transmits one frame at a time and then waits for an ACK before sending the next frame.2 The sender’s retransmission behavior is therefore tightly linked to whether it has safely received confirmation (ACK) that the frame was received correctly.

In particular, the sender retransmits a frame when:

• (iii) Timeout occurs — if the ACK is not received before the timer expires, the sender retransmits the same frame.2
• (ii) Window is full — this is not the relevant trigger in Stop-and-Wait, because the sender window is effectively of size 1 (only one outstanding frame), so it does not “fill” in the same way as sliding-window ARQ schemes.

And the sender does not retransmit in:

• (i) ACK is received — receiving a valid ACK means the sender can advance and send the next frame, rather than retransmitting the current one.2
• (iv) Buffer is empty — Stop-and-Wait retransmission is driven by error/confirmation absence (e.g., timeout), not by whether the sender’s buffer has more data to send. If the buffer is empty, there is simply nothing new to send, but retransmission of the already-sent frame may still occur if its ACK has not been received.2

Mermaid model of sender-state logic (conceptual):

Key terms used below:

• Stop-and-Wait ARQ
• ACK
• Timeout
• Window size

Why (iii) Timeout is the retransmission trigger

Stop-and-Wait ARQ explicitly relies on a timeout at the sender: after sending a frame, the sender starts a timer and retransmits the same frame if the ACK does not arrive in time.2 The timeout typically covers lost data frames, lost ACKs, or excessively delayed delivery.

This matches the core textbook description: after each frame, the sender waits for ACK; if the ACK does not reach the sender before a certain time (timeout), the sender sends the same frame again.

Why (i) ACK received does not cause retransmission

In Stop-and-Wait, the sender’s role is to stop transmitting new frames until it receives the ACK for the current frame.2 Therefore:

• If the sender receives the correct ACK before timeout, it advances (sends the next frame).
• Retransmission happens only when the ACK does not arrive by the timeout (or when a NAK is received, depending on variant).

This is directly consistent with descriptions stating: “After sending each frame, the sender does not send any further frames until it receives an acknowledgement (ACK). If the ACK does not reach the sender before timeout, the sender sends the same frame again.”

Why (ii) “Window is full” is not a Stop-and-Wait retransmission trigger

“Window full” is a hallmark of sliding-window protocols where multiple frames can be outstanding and the sender may need to pause when its window cannot accept more frames.

Stop-and-Wait is a special case where the sender window is effectively one outstanding frame, so the sender does not build up a multi-frame backlog that could become “full” in the sliding-window sense. Instead, Stop-and-Wait retransmission is governed by lack of ACK confirmation (timeout).2

Why (iv) Buffer is empty does not imply retransmission

If the sender’s buffer is empty, that only means there is no new data waiting to be transmitted. It does not change the correctness condition for retransmission: if the sender has already transmitted a frame and is awaiting an ACK, the relevant event is whether the ACK arrives before timeout—not whether additional frames are buffered.

Stop-and-Wait retransmits because reliability requires getting an ACK for the last transmitted frame; timeout triggers retransmission even if there is no new buffered data.2