After a TCP sender retransmits a segment and an ACK covering it arrives, why must it not take an RTT sample from that ACK, and what keeps the timeout sane instead?
answer
- which copy was acknowledged?
- error in both directions
- skip the sample, keep the penalty
- doubling until clean data is acknowledged
- an echoed clock value
basics
~20 sThe ACK cannot say which copy it acknowledges, so the RTT is ambiguous; Karn's algorithm discards such samples. The RTO, doubled on each timeout, is kept until new data is acknowledged without retransmission. The timestamp option removes the ambiguity.
solid answer
~50 sAn ACK for retransmitted data is ambiguous: it may answer the original, which was only delayed, or the retransmission. Timing from the original's send overstates the RTT; timing from the retransmission can understate it, even to near zero if the original's ACK was already on its way, which shrinks the RTO and invites more spurious timeouts. **Karn's algorithm**, a MUST in RFC 6298 and RFC 9293, says: take no RTT sample from a retransmitted segment. Alone that would freeze the estimate when the path really slowed, so it pairs with **exponential backoff**: each expiry doubles the RTO (RFC 6298 rule 5.5), and the backed-off value is kept until new data is sent and acknowledged without retransmission, then recomputed from that clean sample. With the **timestamp option** (RFC 7323), the echoed `TSval` identifies which transmission was acknowledged, so samples can be taken even across retransmissions.
go deeper
Recall that an ACK does not say which copy of a resent segment it answers, so TCP ignores its timing, and that each timeout doubles the wait.
Explain both ways the ambiguous sample goes wrong, why Karn's rule needs backoff alongside it, and when the backed-off RTO is recomputed.
Trace a path whose RTT jumps above the RTO: how backoff finds a working timeout, how timestamps shortcut it, and when R1 and R2 end the attempt.
Weigh conservative backoff and long R2 against application deadlines: when a service should impose its own shorter limit rather than rely on transport-level give-up.
## The retransmission ambiguity A TCP sender measures **round-trip time (RTT)** by noting when a segment was sent and when the acknowledgment (ACK) covering it arrives. Those samples feed the **retransmission timeout (RTO)** estimator of RFC 6298. The measurement breaks down as soon as a segment has been sent twice. A plain TCP ACK carries only a cumulative acknowledgment number; it does not say *which transmission* of the data it answers. Two very different histories produce the same ACK: | What really happened | If timed from the original | If timed from the retransmission | |---|---|---| | Original lost, retransmission delivered | Too long: includes the whole RTO wait | Correct | | Original only delayed, its ACK arrives just after the retransmission | Correct | Far too short, possibly near zero | Either guess can be badly wrong. Guessing "original" inflates the estimate after every real loss. Guessing "retransmission" is worse: a near-zero sample drags `SRTT` down, the RTO shrinks, more timers fire early, more segments are retransmitted, and the estimator can spiral into a state where most retransmissions are unnecessary. ## Karn's algorithm The fix, published by Karn and Partridge and required by RFC 1122, RFC 6298 §3 and RFC 9293 §3.8.1 (MUST-18), is simple: - **Do not take an RTT sample from any segment that was retransmitted.** Its ACK is ambiguous, so it is discarded as a measurement. - Keep taking samples from segments that were sent exactly once. RFC 6298 still requires at least one measurement per round trip whenever Karn's rule allows one. ## Why Karn alone is not enough: exponential backoff Suppose the path's RTT genuinely jumps above the current RTO. Every segment then times out and is retransmitted, and by Karn's rule none of them yields a sample, so the estimator never learns the path has slowed. The companion rule, also mandatory (RFC 1122; RFC 9293 MUST-19), is **exponential backoff**: 1. Each time the retransmission timer expires, set `RTO = RTO * 2` (RFC 6298 rule 5.5). 2. Keep the backed-off value; do not recompute it from old estimates. 3. When new data is sent and acknowledged **without** retransmission, take that clean sample and recompute the RTO normally. This can "collapse" the RTO back down in one step. 4. After several backoffs, an implementation MAY discard `SRTT` and `RTTVAR` altogether and re-initialise them from the next sample, since they are probably stale. Backoff also protects the network: a sender facing a dead or congested path retransmits ever more slowly instead of hammering it. ## A dead path, traced With an RTO of 1 s and no maximum reached: | Event | Time | RTO armed next | |---|---|---| | Original sent | 0 s | 1 s | | Retransmission 1 | 1 s | 2 s | | Retransmission 2 | 3 s | 4 s | | Retransmission 3 | 7 s | 8 s | | Retransmission 4 | 15 s | 16 s | | Retransmission 5 | 31 s | 32 s | | Retransmission 6 | 63 s | 64 s | RFC 6298 lets an implementation cap the doubling, provided the cap is at least 60 seconds. RFC 9293 §3.8.3 then decides when to stop: at threshold **R1** (SHOULD be at least 3 retransmissions) TCP gives negative advice to IP and SHOULD warn the application; at **R2** (SHOULD correspond to at least 100 seconds) it closes the connection. An application MUST be able to set R2 for its connection. ## Timestamps remove the ambiguity The **timestamp option** of RFC 7323 lets a sender put a clock value, `TSval`, in each segment; the receiver echoes it back in `TSecr`. Because the echo names the transmission it answers, RFC 6298 §3 states that timestamps are the one case where samples may safely be taken from retransmitted segments. RFC 7323's rules add safeguards: a `TSecr` is used for RTT measurement only when the ACK advances the left edge of the send window (`SND.UNA`), and when a retransmission fills a hole the receiver MUST echo that latest segment's `TSval`. Timestamps also make convergence faster on long paths: RFC 6298 notes that a connection whose RTT exceeds the 1 s initial RTO can still obtain a valid sample despite the spurious retransmission it suffers. ## Misconceptions - In RFC 6298 and RFC 9293, Karn's algorithm names the sampling rule; exponential backoff is a separate requirement that works alongside it. - Backoff is not undone by any ACK; it ends with a clean sample from data that was not retransmitted. - TCP does not retransmit forever by default; R2 bounds it, unless the application sets it to infinity.
- If retransmitted segments never yield samples, how does a TCP sender without timestamps learn that the path's RTT really grew?Through backoff. The RTO keeps doubling until it exceeds the new RTT, at which point a segment is delivered and acknowledged before its timer fires. The next new data sent and acknowledged without retransmission gives a clean sample reflecting the slower path, and the estimator updates from it.
- How long does TCP keep retransmitting the same segment before it gives up on the connection?RFC 9293 §3.8.3 defines two thresholds. At R1, which SHOULD be at least 3 retransmissions, TCP passes negative advice to IP and SHOULD inform the application. At R2, which SHOULD correspond to at least 100 seconds, it closes the connection. The application MUST be able to set R2, even to infinity.
saying these in an interview costs you the question
- Retransmitted segments give the best RTT samples because they are the newest
- Karn's algorithm lets TCP take RTT samples from retransmitted segments
- After a timeout, the RTO returns to its old value as soon as any ACK arrives
- With timestamps enabled, samples from retransmitted segments must still be discarded
- TCP retransmits a segment forever unless the application closes the socket