Retransmission After Packet Loss

Timers, duplicate ACKs, and how TCP refuses to lose data

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Follow a lost segment from drop to recovery
▸Read a duplicate ACK as the receiver reporting a gap
▸Verify that a retransmission reuses the original sequence number
▸Recognise RTO exponential backoff in packet timestamps

Before this lesson — it builds directly on:

When a packet is lost, nothing announces it. No router sends an apology, no error comes back, and the sender's write() already returned successfully. The sender simply never hears anything. So TCP's entire reliability mechanism has to be built on the only evidence available — the ABSENCE of an acknowledgement. That is genuinely hard: absence could mean the data was lost, or the acknowledgement was lost, or the network is just slow today. TCP handles all three with one rule: keep a copy of everything until it's acknowledged, and if the acknowledgement doesn't come in time, send it again.

✗ Common misunderstanding: A duplicate ACK always means a packet was lost.

Why that's wrong: It means data arrived OUT OF ORDER. Reordering on the path produces the same signal, which is why TCP waits for three duplicates before concluding loss.

Correct model: One or two duplicate ACKs mean 'something arrived early'. Three mean 'it's probably genuinely gone'.

The packets prove it: The three-duplicate threshold in the congestion-control lesson exists precisely because one or two are not trustworthy evidence.

✗ Common misunderstanding: The acknowledgement number identifies the packet being acknowledged.

Why that's wrong: It names the next BYTE the receiver wants. It frequently corresponds to no packet boundary at all, and one ACK can cover many packets.

Correct model: Read every ACK as a sentence: “I have everything before this number; send me this byte next.”

The packets prove it: After a 43-byte request, the server's ACK is ISN+1+43 — a byte position. In the SACK lesson one ACK jumps across eight segments at once.

Watch these fields in the lab: tcp.sequenceNumber · tcp.ackNumber

RTO — retransmission timeoutglossary: The deadline the sender sets when it transmits data. If the acknowledgement hasn't arrived by then, the data is assumed lost and resent. It is derived from measured round-trip times, not fixed.
RTT — round-trip time: How long a packet takes to reach the peer and its acknowledgement to come back. The RTO is built from a running average of RTT plus a margin for variation — so a stable path gets a tight RTO and a jittery one gets a loose one.
Duplicate ACKglossary: An acknowledgement carrying the same acknowledgement number as the previous one. It is generated when data arrives that is NOT the next expected byte — the receiver can only repeat what it's still waiting for.
Exponential backoffglossary: Doubling the timeout after each failed attempt: 1 s, 2 s, 4 s, 8 s. It stops a sender from making a congested network worse by hammering it, and it's why a blackholed connection takes so long to give up.
Go-back-N: A recovery policy: on timeout, resend the lost segment AND everything after it. Simple and safe, but it re-sends data the receiver may already have. SACK (lesson on RFC 2018) exists to avoid exactly that waste.

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

A receiver has bytes 1000–1499 and 2000–2499, but is missing 1500–1999. What acknowledgement number does it send?

A sender transmits its last segment of the day and it is lost. Why can't duplicate ACKs rescue it?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.