Worked examples — TCP reliability — seq - ack numbers, retransmission, cumulative ACK

This page is a drill. We take the machinery from the parent topic — sequence numbers, cumulative ACKs, timeouts, fast retransmit — and hit every case class you could be asked about: clean delivery, single loss, multiple loss, reordering, duplicate segments, ACK loss, wraparound, and the RTO arithmetic.

Every symbol used here is defined first. If you have not seen it, read the callout, then the figure, then the steps.

---

The scenario matrix

Every TCP-reliability question is one of these cells. Click any example link to jump to its worked steps. The 🖼 marks the cells whose dynamics are drawn as a figure.

#	Case class	What is being tested	Jump
C1	Clean, in-order delivery 🖼	plain SEQ→ACK arithmetic	Ex 1
C2	Single loss, later segments arrive 🖼	duplicate ACKs, buffering	Ex 2
C3	Fast retransmit trigger (3 dup ACKs) 🖼	the "3 dup" rule + ACK leap	Ex 3
C4	Timeout retransmit (RTO expiry)	when no dup ACKs come	Ex 4
C5	RTO arithmetic (Jacobson/Karels)	SRTT, RTTVAR, RTO numbers	Ex 5
C6	Reordering (no loss) — degenerate "false alarm"	why dup ACK ≠ loss	Ex 6
C7	Lost ACK self-heals	robustness of cumulative ACK	Ex 7
C8	Duplicate segment received twice	idempotent ACKs, discard-and-reACK	Ex 8
C9	SYN/FIN phantom byte (+1 edge case)	handshake sequence math	Ex 9
C10	Sequence-number wraparound (limiting value, 32-bit)	modular arithmetic edge	Ex 10
C11	Word problem / exam twist	multi-loss, pick the mechanism	Ex 11

---

Example 1 — Clean in-order delivery (C1)

This is the "clean staircase" panel of the figure above — the water level rises one full step per arrival, never hitting a wall.

Steps

1. Segment 1: SEQ $=5000$, covers $[5000,5200)$. Why this step? By definition SEQ is the first byte; adding the length $L=200$ gives the half-open interval.
2. Each following segment starts where the last ended: $5200,5400,5600$. Why? "Next segment in order starts at SEQ+L." No gaps, so we just keep adding 200.
3. ACK after each = last contiguous byte $+1$ = end-of-interval:
   • after Seg1: $5200$
   • after Seg2: $5400$
   • after Seg3: $5600$
   • after Seg4: $5800$ Why? The end of a half-open interval $[a,b)$ is exactly "next expected byte", so ACK equals the upper bound $b$.

Verify: Segment 4 covers $[5600,5800)$; highest contiguous byte $=5799$; $5799+1=5800$. ✓ Matches. Total bytes $=4\times 200=800$, and $5800-5000=800$. ✓

---

Example 2 — Single loss, later segments buffered (C2)

This is the middle panel of the staircase figure. Read that panel like this: the water level climbs to 1100 when A lands, then hits the orange wall at the missing B. C and D arrive past the wall, so they sit in the buffer (the faded violet bricks) but the level cannot rise — it stays pinned at 1100. That flat stretch is exactly the repeated ACK 1100 you compute below. What to notice in the figure: the level line is horizontal for three arrivals in a row — a horizontal ACK line always means "stuck behind a hole."

Steps

1. A arrives $[1000,1100)$ → ACK $1100$. Why? Contiguous up to 1099, next wanted = 1100.
2. C arrives $[1200,1300)$ but 1100–1199 is missing → gap → receiver re-sends ACK $1100$. Why? Highest contiguous (no-gap) byte is still 1099. C is buffered but cannot count.
3. D arrives $[1300,1400)$ → still a gap → ACK $1100$ again. Why? Same reason: the hole at B has not been filled.

Verify: ACK sequence $=1100,1100,1100$. Only one distinct value appears (1100), repeated 3 times — a "dup ACK" storm. The end of A's interval is $1100$, confirming the stuck value. ✓

---

Example 3 — Fast retransmit fires (C3)

This is the right panel of the staircase figure: after the flat stretch, the level leaps vertically in one move once B is delivered — that single tall jump is what you are computing.

Steps

1. Sender counts duplicate ACKs for 1100: dup #1, dup #2, dup #3. Why? Three dups (four identical ACKs total) is the agreed threshold that means "loss, not mere reorder."
2. On the 3rd dup, sender fast-retransmits the segment at SEQ $=1100$ (i.e. B) — without waiting for RTO. Why? The stuck ACK value 1100 literally names the byte the receiver is missing.
3. B arrives → receiver now holds B,C,D contiguously → ACK leaps to 1400. Why? Cumulative ACK reports the whole contiguous prefix at once; filling the single hole connects all buffered data.

Verify: After B fills $[1100,1200)$, the contiguous run is $[1000,1400)$, highest byte $1399$, so ACK $=1399+1=1400$. ✓ It does not climb in steps.

---

Example 4 — Timeout retransmit, no dup ACKs (C4)

Steps

1. No further data → receiver never sees an out-of-order arrival → zero duplicate ACKs. Why? Fast retransmit needs 3 dup ACKs, which need later segments to arrive. There are none.
2. So only the timer can rescue this. Sender started the RTO clock at $t=0$. Why? Timeout is the fallback when the ACK-based hint is unavailable.
3. At $t=600$ ms with no ACK covering byte 8000, RTO expires → retransmit segment at SEQ $8000$, and double RTO to $1200$ ms (exponential backoff). Why double? If the network is congested, backing off avoids hammering it.

Verify: Retransmit time $=600$ ms (one RTO). Mechanism $=$ timeout, not fast retransmit (impossible here). New RTO after backoff $=2\times 600=1200$ ms. ✓

---

Example 5 — RTO arithmetic, Jacobson/Karels (C5)

Recall the smoothing formulas (each new value is mostly the old estimate plus a small pull toward the fresh sample): $\text{SRTT}\leftarrow (1-\alpha )\text{SRTT}+\alpha R$ $\text{RTTVAR}\leftarrow (1-\beta )\text{RTTVAR}+\beta |{\text{SRTT}}_{\text{old}}-R|$ $\text{RTO}=\text{SRTT}+4\cdot \text{RTTVAR}$

Steps

1. RTTVAR first, using the old SRTT (this is the standard order): $\text{RTTVAR}=0.75\times 20+0.25\times |100-140|=15+0.25\times 40=15+10=25$ ms. Why old SRTT? The variance measures how far the sample strayed from the previous estimate.
2. SRTT next: $\text{SRTT}=0.875\times 100+0.125\times 140=87.5+17.5=105$ ms. Why? $\frac{1}{8}$ weight nudges the average gently toward the fresh 140.
3. RTO: $\text{RTO}=105+4\times 25=105+100=205$ ms. Why $4\times$RTTVAR? Jittery links get a wider safety margin so we don't retransmit good data.

Verify: SRTT $=105$, RTTVAR $=25$, RTO $=205$ ms — closer to 200 than 300. ✓ (Units all ms, consistent.)

---

Example 6 — Reordering, no loss (degenerate false alarm) (C6)

Steps

1. A arrives → ACK $1100$. Why? Contiguous to 1099.
2. C arrives (early, before B) → gap at 1100–1199 → dup ACK $1100$ (dup #1). Why? The receiver has C but the no-gap rule still points at 1100. A dup ACK means "I got something past the hole," not "data was lost."
3. B arrives shortly after → hole filled → contiguous now $[1000,1300)$ → ACK 1300 in one jump. Why? Only one dup ACK occurred (need 3 to fast-retransmit), so the sender never resends — reordering healed itself.

Verify: ACK sequence $=1100,1100,1300$. Distinct dup count $=1<3$ → no fast retransmit. Final ACK $=$ end of $[1200,1300)$ $=1300$. ✓ This is the classic proof that "dup ACK ≠ loss."

---

Example 7 — A lost ACK self-heals (C7)

Steps

1. Sender gets ACK 2100 → knows A is safe. Why? Cumulative ACK 2100 confirms all bytes $<2100$.
2. ACK 2200 is lost → sender does not learn about B yet. Why note this? A naive scheme would time out and resend B.
3. ACK 2300 arrives → it cumulatively confirms everything below 2300, i.e. A and B and C. Why? Because cumulative ACK reports the whole prefix, the later ACK subsumes the lost one. No retransmission needed.

Verify: Final ACK 2300 covers bytes $<2300$, which includes B's range $[2100,2200)$. The lost ACK 2200 became irrelevant. ✓ (This is the "robust" half of cumulative ACK.)

---

Example 8 — Duplicate segment arrives twice (C8)

Steps

1. A arrives → ACK $4100$; B arrives → ACK $4200$. Receiver's water level is now $4200$. Why? Standard clean delivery: contiguous prefix $[4000,4200)$.
2. Duplicate A (SEQ 4000, bytes $[4000,4100)$) arrives. The receiver checks: is any byte in $[4000,4100)$ still needed? Every byte $<4200$ is already delivered, so all of A's bytes are old. Why check? The receiver only cares about bytes at or above its current level. Bytes wholly below it are already delivered to the app.
3. Receiver discards the duplicate (it does not re-deliver those bytes to the app — that would corrupt the stream with repeats) and re-sends the current ACK $4200$. Why re-ACK, and why not go backward? The ACK is always "next byte wanted" = current level = $4200$. It cannot decrease. Re-sending $4200$ tells the sender "your retransmit was unnecessary; I'm already past this." ACKs are idempotent: repeating one never harms correctness.

Verify: Level before dup $=4200$; a duplicate of already-delivered bytes cannot lower it, so ACK stays $4200$ (never 4100). ✓ Bytes delivered to the app across the whole exchange $=[4000,4200)=200$ bytes, not 300 — the duplicate added zero. ✓

---

Example 9 — SYN/FIN phantom byte (+1 edge case) (C9)

Steps

1. SYN carries no data, but the SYN flag consumes one sequence number (a "phantom byte"). Why? So the handshake itself can be reliably acknowledged and retransmitted like real data.
2. Server ACK $=x+1=3001$. Why? Cumulative-ACK rule applied to the phantom byte at position $x$: next expected $=x+1$.
3. The client's first real data byte therefore starts at SEQ $=3001$. Why? Position 3000 was "used up" by the SYN; data continues from 3001.

Verify: ACK $=3000+1=3001$; first data SEQ $=3001$. ✓ (FIN behaves identically: it too consumes one sequence number, so the same $+1$ appears at connection close.)

---

Example 10 — Sequence-number wraparound (limiting value) (C10)

Steps

1. This segment covers positions starting at $4,294,967,266$ for 100 bytes; the naive end $=4,294,967,266+100=4,294,967,366$. Why? Same interval arithmetic as always — until we exceed the counter's range.
2. That value exceeds $2^{32}-1=4,294,967,295$, so we take it modulo $2^{32}$: $4,294,967,366\mathrm{mod}{2}^{32}=4,294,967,366-4,294,967,296=70$. Why modulo? The 32-bit field silently wraps: after the maximum value it rolls back to 0.
3. So the next segment's SEQ $=70$. Why does this still work? TCP compares sequence numbers using modular ("wrapped") distance, so 70 correctly reads as "just after $2^{32}-30$", not as "way back at the start."

Verify: $(4,294,967,266+100)\mathrm{mod}4,294,967,296=70$. ✓ The 30 bytes before the wrap ($2^{32}-30\dots 2^{32}-1$) plus 70 bytes after $=30+70=100$. ✓

---

Example 11 — Exam twist: multiple losses, pick the mechanism (C11)

First, the SEQ map (each segment $=160$ bytes):

Seg	SEQ	covers
S1	10000	[10000,10160)
S2	10160	[10160,10320) lost
S3	10320	[10320,10480)
S4	10480	[10480,10640) lost
S5	10640	[10640,10800)
S6	10800	[10800,10960)

Steps

1. S1 arrives → ACK $10160$. Why? Contiguous to 10159.
2. S3 arrives → gap (S2 missing) → dup ACK $10160$. S5 arrives → dup $10160$. S6 arrives → dup $10160$. Why? The first hole is at 10160; every later arrival keeps the ACK stuck there.
3. After 3 dup ACKs for 10160 → fast-retransmit S2 at SEQ 10160. Why? The stuck ACK value 10160 names the first missing byte only — it says nothing about S4.
4. (b) S2 arrives → contiguous now runs $[10000,10480)$ (S1,S2,S3) but stops at the next hole (S4). → ACK 10480. Why does it stall at 10480 instead of reaching 10960? Cumulative ACK advances only up to the first remaining gap. S5 and S6 are buffered but S4's hole is a wall between the level and them, so the water rises only to S4's start $=10480$.
5. (c) With plain cumulative ACK the receiver could never announce "I already hold S5 and S6" — it can only report the first hole (10480). So the sender is blind to what's buffered past the second hole and must run a second dup-ACK round to rescue S4, wasting a round-trip. SACK was added precisely so the receiver can list the non-contiguous ranges it already has (e.g. "I have [10640,10960) too"), letting the sender resend only S4 immediately. Why this matters: every extra hole under cumulative ACK costs another stall; SACK collapses all holes into one report.

Verify: (a) ACKs $=10160,10160,10160,10160$ (one real + three dups). (b) After S2 fills, contiguous prefix $=[10000,10480)$, so ACK $=10480$ (stalls at S4's hole, not 10960). ✓ End-of-S6 would have been $10960$, unreachable until S4 is also repaired. ✓

---

Recall Self-test: which cell is each?

A receiver keeps sending the same ACK three times while buffering later data. ::: Single loss → heading toward fast retransmit (C2/C3). One lone segment is lost with no traffic behind it. ::: Only a timeout can repair it (C4). A dup ACK appears but no retransmit happens. ::: Reordering, a false alarm (C6). The same data segment arrives twice; the ACK does not move. ::: Duplicate segment, idempotent re-ACK (C8). SEQ $2^{32}-30$ plus 100 bytes gives SEQ 70. ::: Wraparound modulo $2^{32}$ (C10). A SYN with ISN $x$ is acknowledged with $x+1$. ::: Phantom-byte +1 (C9).