Section 3.4 said the sender should pick a timeout so that loss is likely but not certain. This is how TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 actually picks it: an average of the measured round trips, plus four times how much they wobble.
Words you will meet
- SampleRTT — one measurement, from sending a segment to its acknowledgement arriving.
- EstimatedRTT — a running average of the samples.
- EWMA — exponential weighted moving average: each older sample counts a fixed fraction less.
- DevRTT — how far the samples typically stray from the average.
- TimeoutInterval — how long TCP waits before deciding a segment is lost.
Why this matters
Section 3.4.1 added a timer and then admitted it had no idea how to set it. The worst-case delay is unknowable, and waiting for it would be far too slow. So the sender must “judiciously choose a time value such that loss is likely, although not guaranteed, to have happened.”
That sentence was a promissory note. This section pays it, and the answer is one of the more elegant things in the book: two running averages and a multiplier. It comes from the TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 work in [Jacobson 1988] and the current recommendations in RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 6298.
Set it too short and you flood the network with retransmissions of segments that were merely late. Set it too long and every real loss costs you a long silence.
Measuring the round-trip time
The SampleRTT sample rtt Simple One measurement of how long a segment took to be acknowledged. Precise SampleRTT: the time between passing a segment to IP and receiving an acknowledgement for it. Most implementations measure only one at a time, so a new value appears about once per round-trip time, and never measure a retransmitted segment, because there is no way to know which copy the acknowledgement refers to [Karn 1987]. introduced in ch. 3 — open in glossary for a segment is the time between when it is sent — passed to IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 — and when an acknowledgement for it arrives.
Two details about how the measurement is taken, both of which matter more than they look:
Only one at a time, and never a retransmission
Most implementations measure only one SampleRTT at a time. At any moment the measurement is running for just one of the outstanding segments, so a new value appears roughly once per round trip. TCP is not short of data; it simply does not need much.
TCP never computes a SampleRTT for a segment that has been retransmitted [Karn 1987]. Only segments transmitted exactly once are measured.
The reason is worth working out. If a segment is sent, times out, is sent again, and then an acknowledgement arrives — which transmission is being acknowledged? Both copies carry the same sequence number, so their acknowledgements are identical. Measure from the retransmission and you get a far-too-short sample; measure from the original and you get a far-too-long one. There is no way to tell which is right, so TCP declines to guess.
Smoothing the measurements
SampleRTT values fluctuate from segment to segment, because of congestion in routers and varying load on the end systems. Any single value may be atypical, so TCP keeps an average.
The recommended value is α = 0.125, that is 1/8 [RFC 6298], which makes it
EstimatedRTT estimated rtt Simple A running average of the recent measurements, so one strange sample cannot mislead TCP. Precise EstimatedRTT: an exponential weighted moving average of SampleRTT, updated as (1−α)·EstimatedRTT + α·SampleRTT with a recommended α of 0.125 [RFC 6298]. Recent samples weigh more than old ones, because they better reflect current congestion. introduced in ch. 3 — open in glossary is a weighted average that puts more weight on recent samples than on old ones. That is natural enough, since recent samples better reflect the congestion the connection faces now. In statistics this is an exponential weighted moving average exponential weighted moving average Simple An average in which each older value counts a fixed fraction less than the one after it. Precise An EWMA. Each update mixes a small fraction of the newest sample into the running value, so the weight of any given sample decays exponentially as updates proceed. TCP uses one for EstimatedRTT with α = 0.125 and another for DevRTT with β = 0.25. introduced in ch. 3 — open in glossary , and the “exponential” is literal: the weight of any given sample decays exponentially as further updates arrive.
At 106 s (move the pointer over the plot to read it anywhere):
- SampleRTT:211 ms
- EstimatedRTT:218 ms
- TimeoutInterval:293 ms
The book’s Figure 3.32 is real measurement, between gaia.cs.umass.edu in Amherst and fantasia.eurecom.fr in the south of France, over about 110 seconds. Those points cannot be recovered from a page scan, so the samples here are generated — deterministic, and matched to the same range and character as the original: a 185–260 ms baseline, a rise through the middle of the run, and occasional spikes past 300 ms. The shape of the argument is exact; the individual points are not the book’s.
Drag α. At 0.125 the estimate glides through the jagged samples; near 1 it chases every one of them; near 0 it barely moves at all. The dashed line is the timeout, and notice how far above the average it sits when the path is unsettled.
In plain words
α is a dial between two failures.
Turn it up and the estimate chases every jag. One unlucky measurement then sets the timeout, and a single slow segment makes the connection nervous.
Turn it down and the estimate barely moves. It is beautifully stable and it will not notice when the path genuinely changes — when a route flaps, or a congested link clears.
0.125 is a compromise, arrived at by experience rather than by proof.
Measuring the wobble
Knowing the average is not enough. TCP also wants to know how far the samples typically stray from it, because that is what decides how much margin the timeout needs.
with a recommended β = 0.25. DevRTT rtt deviation Simple A running estimate of how far the measurements usually stray from the average. Precise DevRTT: an EWMA of |SampleRTT − EstimatedRTT|, updated as (1−β)·DevRTT + β·|SampleRTT − EstimatedRTT| with β = 0.25. It is small when round-trip times are steady and large when they jump about, which is exactly when the timeout needs more headroom. introduced in ch. 3 — open in glossary is itself an EWMA — this time of the gap between each sample and the average. Little fluctuation gives a small DevRTT; a lot gives a large one.
A small discrepancy between the book and RFC 6298
The book writes the EstimatedRTT formula first and the DevRTT formula second, so DevRTT is computed against the newly updated EstimatedRTT. That is the order used on this page, and the order the book’s own homework problem P31 is marked against.
RFC 6298 does it the other way round. It updates RTTVAR first, using the
old SRTT, and only then updates SRTT. The numbers differ slightly. For the
first sample of P31 the book’s order gives DevRTT 5.06 and a timeout of 121.00
ms; the RFC’s order gives 5.25 and 121.75 ms.
Neither is wrong as engineering — the difference washes out after a few samples. But if you check your answers against an implementation rather than against the book, this is why they will not match to two decimal places.
Setting the timeout
Now the two pieces come together. The interval must be at least EstimatedRTT, or unnecessary retransmissions would be sent. It must not be much larger, or a lost segment would go unnoticed for a long time and the transfer would stall.
So: the average, plus a margin — and the margin should be wide when the samples are unsteady and narrow when they are calm. Which is precisely what DevRTT measures.
What each symbol means
- SampleRTT — one measurement: send to acknowledgement (ms)
- EstimatedRTT — the running average of the measurements (ms)
- DevRTT — how far the measurements typically stray from it (ms)
- α — weight on the newest sample, recommended 0.125 (—)
- β — weight for the deviation, recommended 0.25 (—)
Read aloud: Nudge the average towards the new measurement. Nudge the spread towards how far off this one was. Set the alarm at the average plus four spreads.
new EstimatedRTT180 ms
EstimatedRTT = (1 − α)·EstimatedRTT + α·SampleRTT
= 0.875 × 180 + 0.125 × 176
= 158 + 22.0
= 180 ms
the sample was 4.00 ms below the average, and the average moved down 0.500 msnew DevRTT4.63 ms
DevRTT = (1 − β)·DevRTT + β·|SampleRTT − EstimatedRTT|
this sample missed the new average by |176 − 180| = 3.50 ms
= 0.750 × 5.00 + 0.250 × 3.50
= 4.63 ms
DevRTT is not a standard deviation — it is an average of how far off the samples landnew TimeoutInterval198 ms
TimeoutInterval = EstimatedRTT + 4·DevRTT
= 180 + 4 × 4.63
= 180 + 18.5
= 198 ms
the margin above the average is 18.5 ms — wide when the path is unsteady, narrow when it is calmChange any number above and the arithmetic re-runs, carrying the units through.
The defaults are Lin’s path before anything unusual happens. Now set the sample to 240 — one slow round trip — and watch which of the three outputs moves most.
| SampleRTT | EstimatedRTT | DevRTT | TimeoutInterval | |
|---|---|---|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Starting from EstimatedRTT 180 ms and DevRTT 5 ms. The third row is the interesting one — and so are the two after it.
One slow round trip makes TCP cautious for several more
Follow the third row of the trace. A single 240 ms sample — 60 ms above the average — moves EstimatedRTT by only 7.5 ms, because α is small. But it nearly quadruples DevRTT, and the timeout is dominated by four times DevRTT. So the timeout jumps from 198 ms to 253 ms.
Now follow the two rows after it. The path is behaving again, samples back at 178 and 181 ms, and the timeout is still 244 and then 234 ms. DevRTT decays slowly, so the caution outlives the event that caused it.
That is deliberate. β is twice α precisely so that the safety margin reacts sharply to a surprise and relaxes slowly afterwards. A path that jumped once may jump again.
Starting up, and giving up
Before there is anything to measure, RFC 6298 recommends an initial TimeoutInterval retransmission timeout interval Simple How long TCP waits for an acknowledgement before deciding the segment is lost. Precise TimeoutInterval = EstimatedRTT + 4·DevRTT: the average plus a safety margin that grows when the measurements are unsteady. RFC 6298 recommends an initial value of 1 second. On each timeout the value is doubled rather than recomputed, and it returns to the formula as soon as a new acknowledgement updates EstimatedRTT. introduced in ch. 3 — open in glossary of 1 second. That is generous, far longer than most real paths, and deliberately so. A connection that times out on its very first segment has learned nothing and wasted a round trip.
When a timeout does occur, the interval is doubled rather than recomputed from the formula. This avoids a premature timeout for a segment that is about to be acknowledged.
But only until the next real measurement: as soon as a segment is acknowledged and EstimatedRTT is updated, TimeoutInterval goes back to the formula. Section 3.5.4 picks up the doubling and shows that it is also a crude form of congestion control.
Principles in practice — TCP is section 3.4, assembled
It is worth pausing here to see how much of TCP is already familiar.
TCP provides reliable data transfer using positive acknowledgements and timers, much as section 3.4 did. It acknowledges data received correctly, and retransmits when segments or their acknowledgements are thought to be lost or corrupted.
It uses sequence numbers so the receiver can identify lost or duplicate segments — though TCP’s number bytes rather than packets.
Like rdt3.0, TCP cannot tell for certain whether a segment or its acknowledgement was lost, corrupted, or merely delayed. And like rdt3.0, its response is the same in every case: retransmit.
TCP also pipelines, which section 3.4.2 showed to be unavoidable. How many segments it may have outstanding is decided by flow control — section 3.5.5 — and congestion control — section 3.7.
And certain versions of TCP have an implicit negative acknowledgement. Three duplicate acknowledgements for a segment serve as a NAK for the segment after it, triggering retransmission before the timer expires. That is fast retransmit, and it is next.
Check yourself
Check yourself
0 of 5 answered1.Why does TCP never measure a SampleRTT for a segment it has retransmitted?
When the acknowledgement arrives, what exactly is it acknowledging?
2.predictDrag α towards 1 on the plot. What happens to the EstimatedRTT curve?
3.Why is the timeout EstimatedRTT + 4·DevRTT rather than just EstimatedRTT?
4.predictIn the five-sample trace, the third sample jumps to 240 ms. What happens to the timeout, and for how long?
5.A timeout occurs. What does TCP set the next TimeoutInterval to?
What to remember
- SampleRTT is one measurement, send to acknowledgement. Only one is measured at a time, and never for a retransmitted segment — the acknowledgement would be ambiguous.
- TimeoutInterval = EstimatedRTT + 4·DevRTT — the average plus a margin that widens when the path is unsteady. EstimatedRTT is an EWMA with α = 0.125, DevRTT one with β = 0.25.
- Because β is twice α, one odd sample moves the timeout far more than it moves the average, and the effect lasts several round trips.