A sender uses Stop-and-Wait ARQ over a satellite link with 600ms round-trip time. The link bandwidth is 1 Mbps and each packet is 1,000 bits. Approximately what is the maximum achievable throughput?
A1 Mbps — Stop-and-Wait uses the full bandwidth since only one packet is in flight at a time
B500 Kbps — the protocol is exactly 50% efficient due to ACK overhead
CApproximately 1.7 Kbps — one packet (1 ms transmission time) per 601 ms round trip
DApproximately 2 Mbps — Stop-and-Wait doubles throughput by interleaving send and receive
Stop-and-Wait sends one packet and then waits for an ACK before sending the next. Sending 1,000 bits at 1 Mbps takes 1 ms, then the sender waits 600 ms for the round trip. So only 1 packet is sent per 601 ms — about 1,000 bits / 0.601 s ≈ 1,664 bps. The vast majority of the link capacity sits idle. This illustrates why Stop-and-Wait is catastrophically inefficient on high-bandwidth-delay product links.
Question 2 Multiple Choice
A Go-Back-N ARQ sender has window size N=8. Packets 1 through 8 are all transmitted. Packet 4 is lost; packets 5, 6, 7, and 8 arrive intact at the receiver. What does the receiver do with packets 5–8?
ABuffers them and sends individual ACKs, then requests only packet 4 to be retransmitted
BDiscards them and sends a NAK for packet 4 — Go-Back-N receivers only accept in-order packets
CAcknowledges them with cumulative ACKs, signaling to the sender that no retransmission is needed
DStores only packet 5 and discards 6–8 to conserve buffer space
Go-Back-N receivers are intentionally simple: they only accept packets in order. Any out-of-order packet (5–8, which cannot be delivered until 4 arrives) is discarded. The sender must then retransmit packet 4 AND all subsequent packets (5–8), even though those arrived correctly. This waste of bandwidth is the key disadvantage of Go-Back-N versus Selective Repeat, which buffers out-of-order packets and only requests the specific missing one.
Question 3 True / False
ARQ protocols achieve reliable delivery over an unreliable channel using error detection combined with retransmission — they do not require error correction codes.
TTrue
FFalse
Answer: True
Error correction (like Hamming codes or Reed-Solomon) embeds enough redundancy to reconstruct corrupted bits without retransmission. ARQ takes a different approach: just detect that something went wrong (using a checksum or CRC), discard the bad packet, and ask for a retransmission. This is simpler to implement and wastes no bandwidth on correction redundancy when errors are rare. The tradeoff is that errors cause retransmissions (latency) rather than inline repair (complexity).
Question 4 True / False
In Selective Repeat ARQ, the receiver discards correctly received out-of-order packets to keep implementation simple, relying on the sender to retransmit the entire window from the lost packet onward.
TTrue
FFalse
Answer: False
That describes Go-Back-N, not Selective Repeat. Selective Repeat receivers buffer correctly received out-of-order packets and only request retransmission of the specific missing packets. This is more complex for the receiver (requires buffer space and reordering logic) but far more efficient when errors are rare, because correct packets are never needlessly retransmitted. The naming reflects the key distinction: Go-Back-N 'goes back' to the lost packet and retransmits everything; Selective Repeat selectively retransmits only what was lost.
Question 5 Short Answer
Why does Stop-and-Wait ARQ perform poorly on high-bandwidth, high-latency links, and what fundamental change do sliding-window protocols make to address this?
Think about your answer, then reveal below.
Model answer: Stop-and-Wait lets only one packet be in flight at a time. On a high-bandwidth, high-latency link, the round-trip time is long relative to the packet transmission time, so the sender spends most of its time idle waiting for ACKs — the 'pipe' is nearly empty. Sliding-window protocols allow the sender to transmit multiple packets before receiving any acknowledgment, keeping the pipe full. The window size is chosen to match the bandwidth-delay product: window ≥ bandwidth × round-trip time.
The metric that captures this inefficiency is the bandwidth-delay product: if a 1 Gbps link has a 100 ms round trip, you could have 100 Mb = 12.5 MB of data in transit simultaneously. Stop-and-Wait keeps at most one packet in flight, wasting nearly all of that capacity. A window size of at least bandwidth × RTT = 1 Gbps × 0.1 s / (packet size) packets is needed to fully utilize the link. This is why TCP's window size is a critical performance parameter on intercontinental connections.