the retransmission timeout
When you send a letter and expect a reply, you wait a sensible while before assuming it got lost and writing again. Wait too short and you pester someone who simply replied slowly; wait too long and you waste days on a letter that truly vanished. The retransmission timeout, or RTO, is TCP's answer to exactly this dilemma: how long to wait for an acknowledgment before concluding a packet was lost and resending it.
TCP cannot use a fixed timer, because round-trip times vary wildly — milliseconds across a room, hundreds of milliseconds across an ocean, and changing minute to minute as queues build. So it computes the RTO adaptively from its own RTT measurements: roughly the smoothed average RTT plus a generous margin proportional to how much the RTT has been fluctuating (the RTT variance). The classic formula is RTO = SRTT + 4 x RTTVAR, where SRTT is the smoothed RTT. The margin matters: setting RTO only a hair above the average would fire on every slightly-slow packet, so it is kept comfortably above to avoid false alarms.
Two further details make RTO robust. First, exponential backoff: each time the timer fires and the retransmitted packet ALSO goes unacknowledged, TCP doubles the RTO — 1 s, 2 s, 4 s, 8 s — so that during a severe outage it backs off rather than hammering a dead path. Second, a timeout is treated as the strongest congestion signal there is: when the RTO fires, TCP crashes the congestion window all the way down to one packet and re-enters slow start, far more drastic than the gentle halving used for a triple-duplicate-ACK loss. Silence, TCP assumes, means something is badly wrong.
Suppose SRTT settles at 100 ms with RTTVAR 20 ms; then RTO = 100 + 4 x 20 = 180 ms. A packet goes out and nothing comes back within 180 ms, so TCP resends it, drops cwnd to 1, and starts slow start. If that resend also times out, RTO doubles to 360 ms, then 720 ms, and so on — exponential backoff while the path stays silent.
RTO adapts to measured RTT plus a variance margin, doubles on repeated loss, and triggers the harshest cwnd reset.
A timeout is far more punishing than a fast retransmit: it sends cwnd to 1 and reruns slow start, whereas a triple-dup-ACK loss only halves the window via fast recovery. That is why TCP works hard to detect losses via duplicate ACKs and treats the timeout as a last resort — and why even one timeout can badly dent throughput on a long transfer.