[2.2.4] ARQ
Automatic Repeat reQuest (ARQ): ensuring data is received without error
Automatic Repeat reQuest (ARQ) is a family of communication techniques that uses feedback from the receiver to confirm whether transmitted data was received correctly. If a problem is detected or a response does not arrive in time, the sender automatically retransmits the data. ARQ works alongside error detection (e.g. parity, checksum, or CRC) and simple control messages such as ACK (acknowledgement) and NAK/NAcK (negative acknowledgement). This page focuses on the IGCSE-level idea: how ARQ establishes reliable delivery by detecting errors and requesting repeats.
Why ARQ is needed
Transmission errors are inevitable due to noise, interference, or congestion. Even with strong error detection, the sender must know whether a particular packet was accepted. ARQ provides that certainty by combining three ingredients:
- Error detection: the receiver checks each frame (data unit) using a checksum or similar method.
- Feedback: the receiver sends an ACK if the frame is correct or a NAK if it is not.
- Timeout and retransmission: if the sender does not see an ACK within a set time, it retransmits the last frame.
Stop-and-Wait ARQ (the core syllabus model)
In Stop-and-Wait ARQ, the sender transmits one frame then stops and waits for feedback. Only after receiving an ACK does it send the next frame. If a NAK arrives, or if a timer expires before any feedback is seen, it retransmits the same frame. To prevent confusion when ACKs are delayed or duplicated, frames are tagged with a tiny sequence number (commonly alternating 0 and 1) so the receiver can tell whether a frame is new or a repeat.
The ARQ control flow at a glance
- Sender computes error-detection bits and transmits a frame with a sequence number.
- Receiver checks integrity. If valid and new, it delivers data to the upper layer and replies with ACK for that sequence number.
- If the frame is corrupted or missing, the receiver discards it and sends a NAK or, in some designs, stays silent (silence triggers a timeout at the sender).
- If the sender's timer expires before an ACK arrives, it retransmits the last frame.
- Both sides toggle the sequence number (e.g. 0 → 1 → 0 → 1) when they move to the next frame.
Stop-and-Wait ARQ scenarios
The following tabs show how Stop-and-Wait ARQ behaves under different conditions. Note how the sequence number and timing avoid duplicates being accepted.
Sender transmits frame with sequence 0, including error-detection bits. Receiver checks and finds no error, delivers the data, and replies with ACK 0. The sender receives the ACK before its timer expires, toggles its sequence to 1, and proceeds to the next frame. Throughput is limited by the round-trip time because the sender waits after each frame.
Suppose the data frame is corrupted or lost in transit. The receiver either sends a NAK 0 or remains silent. The sender's timeout expires; it retransmits the same frame with sequence 0. On successful reception the receiver sends ACK 0, allowing the sender to move on. This cycle repeats until a clean copy arrives.
Assume the original ACK 0 is delayed, and the sender has already moved on to send sequence 1. If the delayed ACK 0 later arrives, the sender recognises it is stale (it expects ACK 1 now) and ignores it. Similarly, if the receiver receives a duplicate frame 0 (perhaps a retransmission after a lost ACK), it detects the duplicate using the sequence number and does not deliver the data twice; it simply resends ACK 0.
ARQ components and their roles
| Component | Purpose | Notes |
|---|---|---|
| ACK / NAK | Positive/negative feedback to accept or reject a frame | Some systems use only ACK plus timeout (no explicit NAK) |
| Timeout | Assumes loss if no ACK arrives in time | Timeout must exceed round-trip time to avoid needless repeats |
| Sequence number | Prevents duplicates and identifies which frame is being acknowledged | Stop-and-Wait usually alternates 0/1 (1-bit sequence) |
| Error detection | Allows receiver to decide whether to ACK or NAK | Techniques include parity, checksum, CRC |
Beyond basics: performance considerations
Stop-and-Wait is simple and reliable, but it underuses high-latency links because the sender is idle while waiting. More advanced variants (beyond IGCSE) such as Go-Back-N and Selective Repeat allow a window of multiple outstanding frames to increase throughput. The idea is the same: use sequence numbers, timers, and ACKs to ensure that, ultimately, the receiver obtains every frame correctly and in order.
Deep Dive: choosing a timeout value
A timeout that is too short will cause unnecessary retransmissions (the sender gives up before a valid ACK can arrive), creating congestion and reducing throughput. A timeout that is too long delays recovery from real losses. Systems often estimate the round-trip time (RTT) and add a safety margin. Even simple systems allow configuration based on the expected delay of the medium (e.g. satellite links need longer timeouts than local Ethernet).
Key terminology
- ARQ (Automatic Repeat reQuest): protocol behaviour that requests retransmission when errors or losses occur.
- ACK: acknowledgement that a specific frame was received correctly.
- NAK: negative acknowledgement indicating an error or missing frame.
- Timeout: the maximum wait for an ACK before resending.
- Sequence number: a small identifier attached to frames to track order and detect duplicates.
- Stop-and-Wait: ARQ with a window size of one; send one frame, then wait.
Key Takeaways
- ARQ uses error detection, feedback (ACK/NAK), and timeouts to ensure reliable delivery over unreliable channels.
- Stop-and-Wait ARQ sends one frame at a time and relies on a simple alternating sequence number to avoid duplicates.
- If an ACK is not received in time, the sender retransmits the last frame automatically.
- Sequence numbers allow receivers and senders to recognise repeats and ignore stale acknowledgements.
- Correct timeout choice balances fast recovery with avoiding unnecessary retransmissions.
- Windowed ARQ (Go-Back-N, Selective Repeat) improves throughput on long-delay links, but the core idea remains the same: verify and repeat as needed.