RTT Estimation: The Foundation of TCP Timeout Calculation

Imagine you're sending a letter to a friend across the country. How long should you wait before assuming the letter was lost and sending another copy? Wait too long, and you waste precious time. Resend too soon, and you might flood the postal system with duplicate letters just as the original was about to arrive.

This is precisely the challenge that TCP faces with every segment it transmits. TCP must decide: How long should I wait for an acknowledgment before retransmitting? This seemingly simple question exposes one of the most sophisticated adaptive mechanisms in computer networking—the Retransmission Timeout (RTO) calculation, which begins with accurately estimating the Round-Trip Time (RTT).

Round-Trip Time (RTT) is fundamentally the time elapsed between sending a data segment and receiving its acknowledgment. While this definition appears simple, RTT encapsulates the entire journey of data through the network—a journey with many stages and countless variables.

The Anatomy of RTT

When a TCP sender transmits a segment, that segment embarks on a complex journey:

The RTT Formula

Conceptually, RTT can be expressed as:

RTT = T_send + T_propagate_forward + T_queue_forward + T_process_receiver + T_ack_generate + T_propagate_return + T_queue_return + T_receive

In practice, most of these components are bundled together, but understanding them individually reveals why RTT varies so dramatically. A TCP connection from New York to Tokyo will have a fundamentally different baseline RTT than one between two computers in the same data center—primarily due to propagation delay. But even on the same path, RTT can fluctuate wildly based on queuing delays that change moment to moment.

If RTT were constant, timeout calculation would be trivial—simply set the timeout slightly higher than the known RTT. But networks are living, breathing systems where RTT varies across multiple dimensions:

Spatial Variation

Different TCP connections experience vastly different RTTs based on their endpoints:

• Local Area Network (LAN): RTT typically 0.1-1ms
• Same City (Metropolitan): RTT typically 2-10ms
• Cross-Country (Continental): RTT typically 20-80ms
• Intercontinental: RTT typically 100-300ms
• Satellite Links: RTT can exceed 600ms for geostationary satellites

Temporal Variation

Even for a single connection, RTT changes over time due to:

The Scale of Variation

Research has shown that RTT variance can be substantial. A connection with a mean RTT of 100ms might routinely see individual samples ranging from 80ms to 200ms, with occasional spikes to 500ms or more. This variance (often quantified as RTT jitter) is precisely what makes timeout calculation challenging.

If you set the timeout to the average RTT:

• Half your segments will trigger spurious timeouts — because their actual RTT exceeded the average
• Spurious retransmissions waste bandwidth and can worsen congestion
• Congestion response is triggered incorrectly — because TCP interprets timeout as a sign of congestion

Conversely, setting the timeout too high means:

• Actual losses take longer to detect — reducing throughput
• The connection becomes unresponsive — to genuine network problems

TCP must measure RTT using the data it already has—transmitted segments and their acknowledgments. This sounds straightforward, but several complications arise:

The Basic Measurement

The simplest RTT measurement works as follows:

1. Record timestamp T₁ when sending a data segment with sequence number S
2. Receive ACK that acknowledges sequence number S (or beyond)
3. Record timestamp T₂ when ACK arrives
4. Calculate sample RTT = T₂ - T₁

This gives us a sample RTT (often denoted SampleRTT or RTT_sample)—a single observation of the round-trip time.

Practical Measurement Challenges

While the basic algorithm seems simple, real-world TCP implementations face several challenges:

Challenge 1: Cumulative ACKs

TCP uses cumulative acknowledgments—an ACK for byte 1000 means all bytes up to 999 have been received. If the sender transmits segments at times T₁, T₂, T₃ and receives a single cumulative ACK, which segment should be used for the RTT sample?

Common approach: Use the oldest unacknowledged segment that is now being acknowledged. This reflects the actual round-trip for that specific data.

Challenge 2: Delayed ACKs

Receivers often implement delayed acknowledgments—waiting up to ~200ms to see if they can piggyback the ACK on outgoing data. This means the measured RTT includes artificial receiver-induced delay.

Impact: RTT samples may be inflated by delayed ACKs. TCP timestamps (RFC 7323) help address this by including timing information in the segments themselves.

Challenge 3: ACK Compression

In some network scenarios, ACKs may be bundled or delayed by intermediate devices, arriving in bursts rather than individually. This can distort RTT measurements.

Mitigation: Using multiple samples and smoothing algorithms helps filter out measurement noise.

Perhaps the most insidious challenge in RTT measurement is the retransmission ambiguity problem. Consider this scenario:

1. Sender transmits segment X at time T₁
2. Timeout expires (no ACK received)
3. Sender retransmits segment X at time T₂
4. ACK for segment X arrives at time T₃

The question: Does the ACK at T₃ acknowledge the original transmission from T₁ or the retransmission from T₂?

The problem is that standard TCP ACKs contain no information to distinguish these cases. The receiver simply acknowledges bytes; it doesn't indicate which transmission carried those bytes.

Why This Matters

Using an incorrect RTT sample can corrupt the RTO calculation:

• If you assume it's the original (when it's actually the retransmission): Your measured RTT is artificially inflated. Repeated occurrences push the RTO higher and higher, making loss recovery increasingly slow.

• If you assume it's the retransmission (when it's actually the original): Your measured RTT is artificially deflated. This can cause the RTO to shrink, potentially triggering more spurious retransmissions.

This problem was recognized early in TCP's history and led to the development of Karn's algorithm (covered in Page 3), which provides a elegant solution: don't use RTT samples from retransmitted segments at all.

Individual RTT samples are inherently noisy. Network conditions fluctuate, measurement artifacts occur, and even "normal" variation can cause significant sample-to-sample differences. Using raw samples directly for timeout calculation would result in erratic, unstable behavior.

The Evolution of RTT Estimation

TCP's approach to RTT estimation has evolved significantly:

Original TCP Specification (RFC 793)

The original TCP specification used a simple moving average:

SRTT = α × SRTT + (1 - α) × SampleRTT

Where:

• SRTT is the Smoothed RTT (the current estimate)
• SampleRTT is the newly measured sample
• α is a smoothing factor (typically 0.8-0.9)

The timeout was then set as:

RTO = β × SRTT

Where β is typically 2 (i.e., timeout set to twice the estimated RTT).

The Problem with Simple Averaging

While simple averaging worked reasonably well in early networks, it had a fundamental flaw: it didn't account for RTT variance.

The table above illustrates the problem: using a fixed multiplier of the mean RTT doesn't account for how much the RTT varies. Network B needs a much larger safety margin than Network A, but the simple approach gives them identical timeouts.

This realization led to the development of more sophisticated algorithms that track both the mean and the variance of RTT. The most influential of these is Jacobson's algorithm, which we'll explore in detail in the next page.

Modern TCP implementations incorporate several refinements to RTT estimation that go beyond the basic mechanisms:

TCP Timestamps (RFC 7323)

The most significant enhancement is the TCP Timestamps option:

Multiple RTT Samples per Window

With TCP timestamps, implementations can collect RTT samples much more frequently. The original approach (measuring one segment at a time) might yield only one sample per RTT. With timestamps, every segment-ACK pair provides timing information.

The trade-off: More samples means more data to process. Implementations must balance measurement frequency against computational overhead, though modern systems easily handle per-segment timing.

Minimum RTO Bounds

Despite sophisticated estimation algorithms, implementations typically enforce:

• Minimum RTO: Usually 200ms or 1 second (varies by implementation)
• Maximum RTO: Often 60 seconds or 120 seconds

The minimum bound prevents pathologically small timeouts that could cause retransmission storms. The maximum bound ensures connections eventually attempt retransmission even if the network seems completely unresponsive.

The quality of RTT estimation directly impacts TCP's performance and the overall efficiency of the network. Let's examine the consequences of estimation errors:

The Broader Impact

RTT estimation affects more than just timeout calculation:

• Congestion control behavior — Algorithms like BBR use RTT estimates to model network capacity
• Buffer sizing — The bandwidth-delay product (BDP = bandwidth × RTT) determines optimal buffer sizes
• Application design — Latency-sensitive applications may adapt their behavior based on measured RTT
• Network capacity planning — Understanding RTT patterns helps in network design and troubleshooting

Real-World Example: Long Fat Networks

Consider a high-bandwidth connection between continents (a "Long Fat Network" or LFN):

• Bandwidth: 10 Gbps
• RTT: 200ms (intercontinental)
• BDP: 10,000,000,000 bps × 0.2s = 2,000,000,000 bits = 250 MB

To fully utilize this connection, the sender must have 250 MB of data "in flight" at any time. Any error in RTT estimation that triggers a spurious timeout would cut the congestion window and require slow recovery—potentially dropping throughput by orders of magnitude until the window rebuilds.