TCP Reliability: RTT Estimation, Timeouts, and Fast Retransmit

Reliable Data Transfer

TCP implements reliable data transfer over unreliable, best-effort IP. It uses timeout retransmission to ensure ordered, intact data reception.

First, suppose A sends B a segment with sequence 92 and 8 data bytes. A waits for a segment acknowledging 100. B receives the data, but its ACK is lost. A times out and retransmits the same segment; B discards the duplicate.

Second, A sends two segments consecutively: sequence 92 with 8 bytes, then sequence 100 with 20 bytes.

Both arrive intact at B, which sends acknowledgments 100 and 120, but neither ACK arrives before the timeout.

When timeout occurs, A retransmits the first segment, sequence 92. If the second segment's ACK arrives before the new timeout, the second segment need not be retransmitted.

Third, A sends two segments. The first segment's ACK is lost, but the second ACK arrives before timeout. Cumulative acknowledgment tells A that B received all preceding segments, so no retransmission is needed.

RTT Estimation and Timeouts

A fixed timeout that is too short causes unnecessary retransmissions; one that is too long delays recovery. Let $E$ be EstimatedRTT, $D$ DevRTT, and $S$ the current SampleRTT. This lesson updates deviation using the old estimate first:

Common parameters are $\alpha=1/8$ and $\beta=1/4$. The teaching calculation uses raw timeout $E_{new}+4D_{new}$. RFC 6298 also considers clock granularity and recommends rounding a computed RTO up to at least 1 second. The lab shows both the raw result and that floor, distinguishing the formula from full implementation details.

After timeout, RTO backs off exponentially. Without timestamps or another way to remove ambiguity, an acknowledgment of retransmitted data is not directly used as an RTT sample (Karn's rule), because it does not identify the original or retransmitted send.

Fast Retransmit

Timeout-based retransmission has a drawback: the timeout interval may be long. When a segment is lost, the sender must delay retransmission, increasing end-to-end latency.

The sender can often detect loss before timeout by observing duplicate ACKs. Sending many segments means that one lost segment is likely to generate many duplicate ACKs.

Once the sender receives three duplicate ACKs, it considers the segment lost and performs fast retransmit, retransmitting before that segment's timeout.