What is a Retransmission Timeout
RTO (Retransmission Timeout) is how long TCP waits before resending data that wasn't acknowledged. If the sender doesn't receive an ACK within the RTO period, it assumes the packet was lost and retransmits it.
How is RTO calculated?
TCP measures the round-trip time (RTT) of each acknowledged packet — how long between sending data and receiving the ACK. From these measurements, it calculates two values:
- SRTT (Smoothed RTT) — a weighted average that smooths out variation.
- RTTVAR (RTT Variance) — how much the RTT fluctuates.
The RTO is then set to SRTT + 4 * RTTVAR, with a minimum of 1 second (per RFC 6298). This formula gives enough headroom for normal variation without waiting too long when packets are genuinely lost.
What happens when it's wrong?
If the RTO is too short, TCP retransmits packets that were actually just delayed — wasting bandwidth and potentially making congestion worse. These are called spurious retransmissions.
If the RTO is too long, TCP sits idle waiting to retransmit while the application stalls. On high-latency links (satellite, intercontinental), an overly conservative RTO can add seconds of delay.
What is exponential backoff?
When a retransmission itself isn't acknowledged, TCP doubles the RTO and tries again. This is called exponential backoff — the timeout grows from 1 second to 2, then 4, then 8, and so on. This prevents a sender from flooding a congested or unreachable network with retransmissions. After enough timeouts (typically 15 retries), TCP gives up and closes the connection.
Why it matters
RTO is the safety net of TCP reliability. Fast retransmissions (triggered by duplicate ACKs) handle most packet loss, but when those mechanisms fail — when an entire window of packets is lost, or the network goes dark — the retransmission timeout is what eventually recovers the connection. Getting the RTO right is a balancing act between responsiveness and restraint.