arthrop0d

Brief articles on varied topics.

TCP Retransmission Timeout Estimation

networkingalgorithms

TCP’s retransmission-timeout (RTO) estimator chooses how long to wait for an acknowledgment before treating a TCP segment as probably lost. It continuously measures round-trip time (RTT), smooths those measurements, estimates their variation, and sets the timeout above the expected delay.

The goal is not to find the network’s single “latency” number. It is to make a decision under uncertain delay: wait long enough that normal queueing or delayed acknowledgment does not look like loss, but not so long that a genuinely lost segment stalls the connection.

The problem with a fixed timeout

A sender must retransmit data when an acknowledgment does not arrive. Without a timer, one lost segment could leave the sender waiting forever. But a fixed timeout is wrong for at least one of these situations:

TCP therefore estimates timing from the connection’s own traffic. The relevant measurement is the elapsed time between sending a segment and receiving an acknowledgment that confirms it: an RTT sample.

An RTT sample is evidence about one trip through the current path, not a promise that every future trip will take the same time.

From RTT samples to a stable estimate

Individual samples are noisy. A packet may encounter a transient queue, and an acknowledgment may be delayed. TCP keeps two related values:

The standard estimator uses exponentially weighted averages. If R is a new RTT sample, the conceptual updates are:

RTTVAR = (1 - β) × RTTVAR + β × |SRTT - R|
SRTT   = (1 - α) × SRTT   + α × R

The variation is updated before the smoothed RTT, so it compares the new sample with the previous center. The usual constants are α = 1/8 and β = 1/4. That means SRTT changes gradually, while RTTVAR reacts more quickly when measurements become erratic.

For the first valid measurement, there is no previous average. TCP initializes SRTT to the sample and initializes RTTVAR to half that sample. Later samples refine both values rather than replacing them outright.

This smoothing matters in both directions. A single unusually large RTT does not immediately make every future timeout huge. Conversely, a sudden run of large samples increases RTTVAR, giving the estimator room to adapt instead of firing timers based on an unrealistically tidy history.

Turning the estimates into an RTO

TCP calculates the retransmission timeout approximately as:

RTO = SRTT + max(clock_granularity, 4 × RTTVAR)

clock_granularity is the timer’s practical resolution: a timeout cannot be meaningfully more precise than the clock and scheduler that implement it. The factor of four is a safety margin around the measured average. When variation is high, the variation term dominates and the RTO grows. When samples are stable, the timer moves closer to SRTT but still retains a margin.

Implementations also apply protocol-defined minimum and maximum bounds. These protect against timer values that are unusably short or indefinitely large. The exact initial value and bounds depend on the TCP implementation and the applicable standards, but the important behavior is consistent: the RTO is adaptive, bounded, and based on both typical delay and uncertainty.

The sender generally runs a retransmission timer for the oldest unacknowledged data. If an acknowledgment arrives before the timer expires, the timer is stopped or restarted for the remaining outstanding data. If it expires, TCP retransmits and treats that expiration as evidence that the current timing assumption was too optimistic.

Why retransmissions are not ordinary samples

A retransmitted segment creates an ambiguity. Suppose TCP sends a segment, waits, retransmits it, and then receives an acknowledgment. Was the acknowledgment for the original transmission or the retransmission? TCP cannot reliably tell from a normal acknowledgment number.

Counting that elapsed time as a fresh RTT sample would corrupt the estimator. It might measure a timeout, a retransmission delay, and an acknowledgment delay together, then teach SRTT an invented path latency.

TCP therefore follows the Karn algorithm: do not use an acknowledgment for a retransmitted segment as an RTT sample. After a retransmission timeout, TCP also applies exponential backoff, typically doubling the RTO for the next attempt. Repeated failures consequently produce progressively longer waits rather than repeated rapid retransmissions.

Once TCP receives an unambiguous acknowledgment for data that was sent only once, normal RTT sampling resumes. This separation keeps loss recovery from feeding unreliable measurements back into the estimator.

How the balance works in practice

The estimator avoids premature retransmissions through three layers:

  1. Smoothing prevents one noisy sample from instantly changing the expected delay.
  2. RTTVAR adds a larger cushion when delay is unpredictable.
  3. Backoff slows repeated attempts after an actual timeout.

It avoids sluggish recovery in the other direction because old samples gradually lose influence. On a consistently faster path, SRTT and RTTVAR fall, bringing the RTO down. On a path that becomes slower, new samples move the estimates upward without requiring a manually tuned configuration change.

This is why an incident report may mention an “RTO,” “spurious retransmission,” or “Karn’s algorithm.” The RTO is not simply a fixed socket setting or the last observed ping time. It is a running estimate of how long an acknowledgment should take, plus a margin derived from recent uncertainty. That combination lets TCP distinguish ordinary variation from probable loss well enough to recover without needlessly duplicating healthy traffic.

← All articles