Sequence numbers and retransmission — How TCP confirms delivery
Number every single byte and check answers with 'ack number = next byte wanted.' Distinguish the two ways TCP notices loss — the retransmission timer and duplicate ACKs.
How do you verify "it should have arrived"?
As Chapter 1 showed, IP does not tell you when it loses something. Yet TCP promises "reliable delivery — noticing when it fails." The mechanism is wonderfully plain, resembling a parcel service's tracking numbers and delivery receipts.
What matters is that numbers are assigned per byte, not per packet. To TCP, data is a "flow of bytes," and a segment (the unit placed in a packet) is merely a convenient slice of that flow. The starting number was agreed in the previous chapter's handshake, so both sides count bytes with the same ruler from the start. In the examples below, we make the starting number 1000 for readability, so the first data byte is 1001.
A 500-byte segment with seq = 1001 carries bytes 1001–1500, and the ACK points at 1501, 'the next one wanted.' The protagonist of the numbering is the byte, not the segment.
ack number = the number of the next byte wanted
The single most critical point in reading captures is how to interpret the ack number. It points at 'where I want you to continue from next,' not 'how far I have received.' If you received 500 bytes starting at seq = 1001, the last byte that arrived is number 1001 + 500 − 1 = 1500. So the ack you return is 1501.
The other critical point is the property of cumulative acknowledgment. An ACK can only express 'I have received up to here contiguously, with no gaps.' Even if 4001–5000 arrives while 3001–4000 is missing, the only ack you can return is still 3001. The data that did arrive is kept in the receive buffer, and the instant the gap is filled, the ack leaps all the way to 5001. This 'store and reorder' behavior is precisely the substance of promise number 2, "in order."
Practice 3-1 — Hand-calculating seq and ack
This calculation is the foundation of all capture reading. Write the byte ranges on paper and check them.
Q1. The sender transmitted 500 bytes of data in a segment with seq = 1001. What ack number does the receiver return after receiving it?
This segment carries the 500 bytes numbered 1001–1500 (1001 + 500 − 1 = 1500). The ack number is 'the number of the next byte wanted,' so the receiver returns 1501, the number after 1500. Not 'the last number received' but 'the next number wanted' — internalizing this off-by-one is the first step in reading captures.
Q2. The receiver has received everything contiguously up to byte 3000. Then a segment carrying 4001–5000 arrives, skipping over the missing 3001–4000. What ack number does the receiver return?
TCP's ACK is cumulative. It can only say 'I have received everything up to here contiguously, with no gaps,' so even with 4001–5000 in hand, it cannot advance past the missing 3001. The received 4001–5000 is kept in the receive buffer, and ack = 3001 is returned. This 'repeating the same ack' behavior foreshadows the duplicate ACKs later in this chapter.
Q3. What is the advantage of TCP assigning sequence numbers 'per byte' rather than 'per segment (packet)'?
What TCP carries is a flow of bytes, not a sequence of packets. Segments may be re-bundled on retransmission or split by the path, so segment boundaries can change — but with byte-level numbering, 'how far has arrived' stays uniquely determined no matter how the flow is recut. This 'bytes, not segments, are the protagonist' view also connects directly to Chapter 6's framing problem.
Noticing method 1 — silence (the retransmission timer)
When no ACK comes back, how long should you wait before deciding "it was lost"? Too short, and useless retransmissions strain the network; too long, and users are kept waiting. TCP keeps measuring the round-trip time (RTT: from sending to the ACK's return) on every send, and computes the retransmission timeout (RTO) dynamically from its average and variance. A few milliseconds within the same building, hundreds of milliseconds across continents — the ruler adapts to the line.
When the RTO expires, the missing segment is retransmitted and the RTO is doubled before the next wait (exponential backoff). The most likely reason an ACK is not returning is congestion, so each retry spaces itself out further, avoiding piling on.
Noticing method 2 — cries for help (duplicate ACKs) and fast retransmit
There is a faster way than waiting out the silence. If bytes up to 8000 arrived, 8001–9000 was lost, and only the later segments keep arriving, the receiver can do nothing but return ack = 8001 on each arrival. From the sender's viewpoint, ACKs with the same number keep coming in — these are duplicate ACKs.
Each duplicate ACK says 'the later data got here, but the hole starting at 8001 is still open.' After the third identical one, the sender waits no longer. It reasons: later segments are arriving = the path is alive = probably exactly one segment is missing, and retransmits just the segment at seq = 8001 without waiting for the RTO. This is fast retransmit.
When you find retransmissions in a capture, check which kind they are. Duplicate-ACK-driven means a light, isolated loss; timeout-driven means a serious state where nothing is coming back at all — the same word "retransmission," but opposite readings.
Practice 3-2 — How TCP notices something did not arrive
TCP has no notification saying 'it did not arrive.' It reasons from two pieces of indirect evidence: silence and repetition.
Q4. Which description of the retransmission timer (RTO) is correct?
The RTO is the threshold 'if no ACK arrives within this long, treat it as lost,' computed dynamically from RTT measurements and their fluctuation. Short for nearby peers, long for distant ones. If an ACK still does not arrive after retransmitting, the wait doubles each time (exponential backoff), avoiding piling onto an already congested network. The receiver cannot report 'it did not arrive' — you cannot notice the absence of something you never received.
Q5. The sender keeps receiving ACKs with the same ack number (duplicate ACKs). What is happening at the receiver?
This is a consequence of cumulative acknowledgment. With bytes received up to 8000 and 8001–9000 missing while later data (9001–, 10001–, ...) keeps arriving, the receiver can only return ack = 8001 each time. A duplicate ACK is thus the receiver crying out: 'everything beyond this point is arriving — only this piece is missing.' A full buffer is communicated by advertising window 0 (Chapter 4), which is a different thing.
Q6. After the third identical duplicate ACK, the sender retransmits the missing segment without waiting for the timeout (fast retransmit). What justifies not waiting?
A duplicate ACK is generated each time a subsequent segment arrives. Three of them means at least three later segments got through safely — the path is alive, and probably just one segment is missing. Then waiting out the RTO (hundreds of milliseconds to seconds of silence) is a waste. Timeout retransmission is inference from silence; fast retransmit is inference from evidence of delivery. Which kind of retransmission appears in an incident log changes your reading of the network's condition (Chapters 5 and 7).
Key takeaways from this chapter
- Numbers are per byte. A 500-byte segment at seq = 1001 carries bytes 1001–1500
- ack number = the number of the next byte wanted. And it is cumulative — it cannot advance past a gap
- Two ways to notice loss: silence (RTO expiry, exponential backoff) and cries for help (3 duplicate ACKs → fast retransmit)
- Duplicate-ACK retransmissions signal a mild condition; timeout retransmissions signal a severe one
The machinery for "reliable delivery, in order" is now complete. The next chapter covers the first half of promise 3 — the sliding window that adapts to the peer. The star is a number that rides along on ACKs: "how many more bytes can I accept?"