Summary

  • RFC 6298 restarts the retransmission timer when an ACK acknowledges new data, not merely whenever an ACK arrives.
  • The same algorithm starts an idle timer when data is sent, stops it when nothing remains outstanding, and retransmits the earliest unacknowledged segment when the timer expires.

One clock for a moving frontier

A TCP sender can have several segments in flight, yet RFC 6298 describes a single control question: when should the retransmission deadline move? The answer begins when a packet containing data is sent. If the timer is idle, the sender starts it for the current RTO. Sending more data while it already runs does not, by itself, start a fresh interval.

That restraint matters because the timer is protecting data that is already outstanding. If every later send reset the clock, older unacknowledged bytes could wait behind a deadline repeatedly moved by newer transmissions. The RFC instead keeps the existing timer running until acknowledgment progress changes the recovery frontier.

New acknowledgment changes the deadline

Rule 5.3 supplies the decisive condition. When an ACK acknowledges new data, the sender restarts the timer for the current RTO. The ACK has advanced what the receiver is known to possess, so the earliest remaining unacknowledged segment has changed. The recovery clock may now begin again from that new state.

An ACK that repeats the old boundary does not satisfy that wording. Duplicate acknowledgments can carry operational meaning elsewhere in TCP, but under this timer rule they do not earn an endless sequence of fresh deadlines. That is an inference from the condition in the standard, not a claim that duplicate ACKs are generally useless.

When all outstanding data has been acknowledged, the timer is turned off. If the timer instead expires, the sender retransmits the earliest segment that remains unacknowledged. Together, the rules bind one clock to a changing frontier: start when exposure begins, reset when verified progress moves the frontier, stop when exposure ends, and act on the oldest unresolved data when time runs out.

The normative boundary

RFC 6298 says an implementation must never retransmit a segment less than one RTO after its previous transmission. It presents the start-stop-restart sequence as the recommended algorithm for satisfying timer management. Those terms are not interchangeable: the timing invariant is mandatory, while the listed lifecycle is the recommended realization.

The source does not establish how every present TCP stack organizes its timers or how often duplicate-ACK handling is implemented incorrectly. It also does not make rule 5.3 a discussion of RTT sampling, delayed acknowledgments, fast retransmit or congestion control. Those mechanisms may meet at the same ACK stream, but they answer different questions.

Sources