RFC 2988
SUPERSEDEDComputing TCP's Retransmission Timer
V. Paxson, M. Allman · November 2000 · original status: Proposed Standard · current status: Obsoleted (Proposed Standard, historic interest)
obsoleted by: RFC 6298
Obsoleted by RFC 6298 (2011). The formulas survived intact; the headline change is the initial RTO dropping from 3 s to 1 s, plus clarified clock-granularity guidance. Timer lessons compute with RFC 6298 and show the 2988 deltas.
This module teaches BOTH the historical problem and today's rules
This document
- RFC 2988 §2 — SRTT/RTTVAR computation (α=1/8, β=1/4)
- RFC 2988 §5 — managing the timer, backoff
Where the current rules live
- RFC 6298 §2 — initial RTO lowered 3 s → 1 s; same SRTT/RTTVAR arithmetic
- RFC 6298 §5 — timer management (unchanged in substance)
Computing TCP's Retransmission Timer (2988 → 6298)
New to these ideas? Switch to the beginner level for a from-zero concept primer.
The problem this document answered
TCP measures each round trip and keeps two running numbers: SRTT (a smoothed average) and RTTVAR (how much the samples wobble). The timer is SRTT + 4·RTTVAR — the average plus a generous allowance for variability — floored at one second. Stable paths get a tight estimate; jittery paths automatically get more slack.
Historical context
Jacobson's 1988 paper introduced the mean-and-deviation estimator; Karn & Partridge (1987) solved the retransmission-ambiguity problem. RFC 2988 (November 2000) standardised the algorithm; RFC 6298 (June 2011) obsoletes it, lowering the initial RTO from 3 s to 1 s and clarifying clock-granularity handling.
Current practice
RFC 6298 is current and universal. Real stacks add refinements — F-RTO and Eifel to detect spurious timeouts, RACK-TLP (RFC 8985) to use time-based loss detection instead of dup-ACK counting — but SRTT/RTTVAR remains the foundation.
Interactive laboratory
⏱️ RTO calculator — step through the estimator
| # | event | R | SRTT | RTTVAR | computed RTO | applied RTO | backoff |
|---|---|---|---|---|---|---|---|
| 1 | first sample | 40 | 40 | 20 | 120 | 1000 ⌃floor | — |
| 2 | RTT sample | 40 | 40 | 15 | 100 | 1000 ⌃floor | — |
| 3 | RTT sample | 40 | 40 | 11.3 | 85 | 1000 ⌃floor | — |
| 4 | RTT sample | 40 | 40 | 8.4 | 73.8 | 1000 ⌃floor | — |
| 5 | RTT sample | 40 | 40 | 6.3 | 65.3 | 1000 ⌃floor | — |
RTTVAR = ¾·old + ¼·|SRTT−R|; SRTT = ⅞·old + ⅛·R. Computed 65.3 ms, clamped to 1000 ms.
RTO = SRTT + max(G, 4·RTTVAR), clamped to [1000 ms, 60000 ms]. Note how often the floor — not the formula — decides the timer on fast paths. The 2988/6298 difference shows only BEFORE the first sample: try the cold-start preset and switch models.
Guided walkthroughs — coached, packet by packet
Watch it on the wire
Four request/response exchanges over a rock-steady 40 ms path. Watch SRTT lock onto 40 ms while RTTVAR decays toward zero — and the RTO sit stubbornly at its 1-second floor.
The same steady path, but one response is delayed by 400 ms. Watch a single outlier widen RTTVAR sharply — the estimator buying safety margin exactly when the path proves unpredictable.
A segment is lost, the timer fires and doubles, and the retransmission is finally acknowledged — but that ACK is AMBIGUOUS (which copy did it answer?), so Karn's rule throws the sample away instead of poisoning SRTT.
Identical loss, but the pre-2011 rules: with no measurement yet, the first timer is 3 seconds instead of 1. Compare how long the connection sits blind before it acts.
The same loss under today's rules: the first timer is 1 second, so recovery starts two seconds sooner. This single constant is the headline change from RFC 2988.
Compare correct vs historic / naive behaviour
Original RFC vs current standard
Initial RTO before any measurement
- Original behaviour
- RFC 2988 §2.1: 3 seconds.
- Current behaviour
- RFC 6298 §2.1: 1 second.
- What changed
- The pre-measurement constant dropped by two seconds.
- Why it changed
- Paths got dramatically faster; a 3 s blind wait was a large, visible penalty on the very first segments of every connection.
📷 In a capture: A lost first segment retransmitted after ~1 s (modern) versus ~3 s (pre-2011). Compare the two traces side by side.
Minimum RTO
- Original behaviour
- RFC 2988 §2.4: SHOULD be rounded up to 1 second.
- Current behaviour
- RFC 6298 §2.4: unchanged at 1 second (with the same conservative rationale).
- What changed
- Nothing — and that surprises people, since it means a 40 ms LAN still arms a 1 s timer.
- Why it changed
- Spurious retransmissions are costlier to the network than a slow recovery is to one connection. Some stacks use lower floors internally; the standard does not.
📷 In a capture: On a fast LAN the first retransmission still lands ~1 s after the loss, not ~100 ms.
Clock granularity
- Original behaviour
- RFC 2988 mentioned granularity but left its use partly implicit.
- Current behaviour
- RFC 6298 makes G explicit: RTO = SRTT + max(G, 4·RTTVAR).
- What changed
- The coarse-clock case is specified rather than assumed.
- Why it changed
- Stacks with 500 ms tick granularity otherwise computed nonsensically tight timers.
📷 In a capture: Not visible on the wire — an implementation-side detail.
Common misconceptions
- ✗“The RTO is just double the RTT” — it's SRTT + 4·RTTVAR, so a jittery path gets far more slack than a steady one at the same average.
- ✗“A timeout means the estimator was wrong” — a timeout is not a measurement at all; SRTT and RTTVAR are deliberately left untouched, and only the backoff multiplier changes.
- ✗“Lower RTO = faster recovery = better” — under-estimating causes spurious retransmissions that add load to an already-struggling path; that's the collapse mechanism from RFC 896.
- ✗“The 1-second floor is a legacy wart” — it's a deliberate safety margin: a spurious retransmit harms the shared network, a slow recovery harms only this flow.
- ✗“Karn's rule is obsolete with timestamps” — timestamps make samples unambiguous when both sides negotiated them; without them, Karn still applies.
Glossary terms used here
Knowledge check
1/4 · First-ever RTT sample on a connection: R = 40 ms. What are SRTT, RTTVAR and the computed RTO?
2/4 · A retransmission timer fires. What happens to SRTT and RTTVAR?
3/4 · Why must an ACK that covers a retransmitted segment not update SRTT?
4/4 · Troubleshoot: a LAN application sees ~1 second stalls whenever a single packet is lost, though the RTT is 0.5 ms. Is the stack broken?