ARQ Sender Timeout: What to Do When ACK for Frame 5 Isn’t Received
In most reliable data-link mechanisms that use Automatic Repeat reQuest (ARQ) with a timeout interval, if the sender transmits frame 5 and does not receive its acknowledgement (ACK) before the timer expires, the sender must assume that the frame or its ACK was lost and therefore retransmit frame 5 rather than advancing. This is the standard rationale behind ARQ: the receiver only confirms correct delivery by sending an ACK, and a missing ACK within the timeout implies uncertainty about frame delivery, so the safest action is to repeat the transmission of the unacknowledged frame.2
Key terms:
- ARQ
- timeout interval
- ACK
- retransmission
- unacknowledged frame
Footnotes
-
"Automatic Repeat reQuest (ARQ) - Wikipedia" (https://en.wikipedia.org/wiki/Automatic_repeat_request) - Overview of ARQ reliability via retransmissions after failure to get acknowledgement. ↩
-
"Stop-and-wait ARQ - Wikipedia" (https://en.wikipedia.org/wiki/Stop-and-wait_ARQ) - Explains timeout behavior and retransmission of the current frame when ACK is not received. ↩
ARQ / Stop-and-Wait Retransmission (Timeout Leads to Retransmit)
Multiple-choice decision
Given: “The sender transmits frame 5 but does not receive its ACK within the timeout interval. Assume the frame or its acknowledgement has been lost.”
The sender should do:
- (i) Retransmit frame 5
Why the other options are incorrect:
- (ii) Move directly to frame 6: would risk the protocol delivering data out of order or skipping a frame that may not have been received.
- (iii) Discard all previously transmitted frames: discarding breaks reliability because the sender still needs to ensure frame 5 is eventually acknowledged.
- (iv) Restart the entire connection: ARQ protocols are designed to avoid connection restart; they retransmit the missing/uncertain frame(s) instead.
Sender behavior on timeout (unacknowledged frame)
- 1Step 1
When frame 5 is transmitted, the sender starts a timeout timer to wait for its ACK.
- 2Step 2
If the ACK for frame 5 is not received within the timeout interval, the sender treats the event as a loss of either the frame or the ACK.
- 3Step 3
Retransmit the same frame (frame 5) because reliability requires making delivery confirmed by a subsequent ACK.
- 4Step 4
Once an ACK is eventually received for frame 5, normal progress to later frames resumes according to the specific ARQ variant.
Where this fits in ARQ variants (conceptually)
Even though full behavior differs between protocols (e.g., Stop-and-Wait, Go-Back-N, Selective Repeat), the core logic triggered by “ACK not received within timeout” is:
- Stop-and-Wait
- Go-Back-N
- Selective Repeat
- cumulative ACK
In the question’s wording, it’s explicitly “frame 5” that was sent and whose ACK was not received; hence frame 5 is the unacknowledged frame, so retransmitting it is the correct action.2
Footnotes
-
"Automatic Repeat reQuest (ARQ) - Wikipedia" (https://en.wikipedia.org/wiki/Automatic_repeat_request) - Overview of ARQ reliability via retransmissions after failure to get acknowledgement. ↩
-
"Stop-and-wait ARQ - Wikipedia" (https://en.wikipedia.org/wiki/Stop-and-wait_ARQ) - Explains timeout behavior and retransmission of the current frame when ACK is not received. ↩
Choice Evaluation (Correct action after timeout)
Why options differ under standard ARQ timeout logic
Pro Tip
When a protocol’s reliability depends on acknowledgements, “ACK not received before timeout” almost always means “retransmit the unacknowledged frame,” not “skip ahead.”
Common Exam Trap
If you instinctively “advance” on a missing ACK, you’ll violate reliability. The sender can’t know whether frame 5 arrived—only the ACK reveals it.
FAQ
Knowledge Check
A sender sends frame 5 but does not receive its ACK within the timeout interval (frame or ACK may be lost). What should it do?