4.3.20 · D5Computer Networks
Question bank — TCP reliability — seq - ack numbers, retransmission, cumulative ACK
Before we start, one shared vocabulary so nothing below uses a word you haven't been handed:
True or false — justify
TCP guarantees the receiving application gets every byte in the exact order sent.
True — those are precisely TCP's two promises (no loss, in-order). It buys them on top of an unreliable IP that may drop, reorder, or duplicate.
Sequence numbers start at 0 for every new connection.
False — each side picks a random Initial Sequence Number (ISN) at handshake time, so a stale segment from an old connection on the same IP/port can't masquerade as fresh data.
TCP numbers packets, so a retransmitted segment keeps the same packet number.
False — TCP numbers bytes, not packets. A resend can be a different size or be split/merged; only the byte positions are permanent identities.
An ACK of value means the receiver got exactly byte .
False — it means the receiver got everything below contiguously and now expects byte next. ACK is "next wanted", not "last received".
A cumulative ACK tells the sender which specific segments after a gap arrived.
False — that is exactly what cumulative ACK cannot say. It only reports the contiguous prefix; bytes past a hole are invisible to it, which is why Selective ACK (SACK) was added.
If one ACK is lost on the way back, that data must be retransmitted.
False — a later ACK carries an even larger cumulative number that covers the same (and more) data. A lost ACK is self-healing; that robustness is a headline feature of cumulative ACK.
The SYN and FIN flags consume no sequence number since they carry no data.
False — each is treated as one "phantom byte" and consumes one sequence number, which is why the ACK to a SYN with ISN is .
Three duplicate ACKs always mean a segment was lost.
False — they strongly suggest loss but could be caused by heavy reordering. TCP accepts that small risk: 3 dups is the agreed threshold that reordering rarely reaches, so fast retransmit fires.
RTO is set to the measured RTT exactly.
False — RTO is the smoothed RTT plus a safety margin (). Setting it to bare RTT would trigger false retransmissions on any jitter above the mean. See RTT estimation / Jacobson's algorithm.
Spot the error
"The receiver ACKs the highest byte number it has stored in its buffer, even across gaps."
Error: it ACKs the highest contiguous byte + 1, ignoring anything past a hole. Buffered-but-non-contiguous bytes (like a segment C sitting past a missing B) do not raise the ACK.
"On the 3rd duplicate ACK for value , the sender retransmits the segment ending at ."
Error: it retransmits the segment starting at SEQ — the one the receiver is stuck waiting for. is the next-expected byte, so the missing segment begins there.
"Each timeout, RTO stays the same so retransmits keep pace."
Error: RTO is doubled on each timeout (exponential backoff). If the network is congested, hammering it at a fixed rate would make things worse; backoff eases the pressure.
"Fast retransmit waits for the RTO timer, it just triggers a bit earlier."
Error: fast retransmit fires on 3 duplicate ACKs without waiting for RTO at all. Its whole purpose is to skip the slow timer when duplicate ACKs already reveal the loss.
"To be safe, ACK the last byte received rather than +1."
Error: ACK must be last-contiguous-byte + 1. Omitting the +1 tells the sender that byte is still wanted, so it resends it forever — a permanent stall.
"When the lost segment B finally arrives, the ACK creeps up by just B's length."
Error: the ACK leaps over B, C, D at once. Filling the single hole connects everything already buffered, so the cumulative ACK jumps to cover the whole newly-contiguous prefix.
Why questions
Why number the byte stream instead of the packets?
Because a byte has one permanent identity regardless of how it's later packetized. Resends, splits, and merges then all stay consistent — a segment simply claims a byte range.
Why is the Initial Sequence Number random rather than a fixed constant?
To stop a delayed segment from an old connection (same IP/port pair) being accepted as new data, and to make blind sequence-guessing injection attacks much harder.
Why does the receiver re-send the same ACK number when out-of-order data arrives?
Because the highest contiguous byte hasn't changed — the hole is still open — so "next expected" is still the same value. Buffering the later segment doesn't advance the contiguous prefix.
Why add to the smoothed RTT instead of a fixed margin?
Because the safe waiting time should scale with how jittery the path is. On a bursty link RTTVAR is large, so we wait proportionally longer before declaring loss and avoid needless retransmits.
Why use an exponentially-weighted moving average for RTT rather than the latest sample?
A single RTT sample is noisy; one spike would wreck the estimate. The EWMA (SRTT) smooths samples while still tracking gradual trends in the path's delay.
Why is cumulative ACK described as both robust and imprecise?
Robust because a lost ACK is repaired by the next larger one and one number summarizes a whole prefix; imprecise because it can't report "got C and D but not B", which can force extra resending.
Why does 3 duplicate ACKs — not 1 or 2 — trigger fast retransmit?
One or two dups are commonly just mild reordering that resolves itself. Three is the agreed line reordering rarely crosses, so it's a confident loss signal without waiting on RTO.
Edge cases
If a segment of length 0 (pure ACK, no data) arrives, does the receiver's ACK number change?
No — with zero data bytes there is nothing new to make contiguous, so the next-expected byte is unchanged. Only bytes (or the phantom SYN/FIN byte) advance the ACK.
The very first data byte after a SYN with ISN — what SEQ does it carry?
SEQ , because the SYN consumed sequence number as a phantom byte. The peer's first ACK is therefore also .
A segment arrives that is entirely a duplicate of already-acknowledged data — what does the receiver do?
It discards the duplicate data but still sends an ACK for the current next-expected byte. IP can duplicate packets, so TCP must silently absorb re-arrivals without corrupting the stream.
The last segment of a transfer is lost and no later segment follows to trigger duplicate ACKs — how is it recovered?
Only the RTO timer can save it here; with no subsequent segments there are no duplicate ACKs, so fast retransmit never fires. This is exactly the case where the timeout mechanism is essential.
A segment arrives that partially overlaps already-received bytes plus some new ones — what happens?
The receiver keeps only the genuinely new bytes to extend its contiguous prefix and drops the overlapping part. Byte-level numbering makes this trimming unambiguous.
The sender's window is full and no ACK advances it — what does cumulative ACK's stall look like?
Progress halts until the missing byte is delivered, because the ACK can't climb past the hole to free window space. This stall is one motivation for Selective ACK (SACK) and relates to Sliding window flow control.
Recall One-line self test before you leave
"SEQ says where I START, ACK says what I WANT NEXT, and a duplicate ACK means later data arrived but the hole is still open." ::: If you can say that sentence and explain each clause, you've cleared the traps on this page.