TCP Timers

TCP Timers and Their Roles

TCP must make time-based decisions when acknowledgments are delayed, segments are lost, or an idle peer stops responding. A timer supplies a bounded condition for retransmission, cleanup, or probing. The timer does not prove why a response is absent; it gives the protocol a defined event for continuing its state machine.

The internet is an asynchronous environment. Events can occur at irregular intervals, and a sender and receiver do not share a clock. A segment can take milliseconds or seconds to reach the peer, arrive out of order, or be lost entirely.

The Transmission Control Protocol (TCP) therefore uses several timers. Their values and actions cover retransmission after an unacknowledged segment, the TIME-WAIT interval after an orderly close, probing after a zero-window advertisement, and optional keep-alive checks for idle connections. These timers support reliability and resource management without making the network synchronous. A timer belongs to local connection state, and its expiration is processed together with incoming segments and application requests. Different timers have different purposes and must not be interpreted as a general measurement of network health. Implementations may combine timer events for efficiency, but the resulting actions still follow the semantics of the corresponding TCP timer.

1. Retransmission Timer and RTO

The Retransmission Timer governs the Retransmission Timeout (RTO). It prevents a connection from waiting indefinitely when a data segment or its acknowledgment is lost. When the timer expires, TCP retransmits the earliest unacknowledged data according to its retransmission rules. The timer is associated with outstanding data, and an acknowledgment that covers the retransmitted range can stop or restart it. A timeout also affects congestion-control behavior, so retransmission and sending-rate decisions are related but represent separate mechanisms. The timer does not require a fixed delay for every segment: a connection estimates its RTT and variation, then applies the current RTO to outstanding data.

Choosing the RTO from Observed RTT

TCP must choose a timeout that follows the observed round-trip delay. A connection to a nearby server can have a different RTT from a connection to Sydney, and congestion can change either value over time. A fixed value would cause avoidable retransmissions on a slow path or delayed recovery on a fast path.

• If the RTO is set too short, TCP can retransmit a segment that was delayed and not lost. This consumes bandwidth and can add load to a congested path.
• If the RTO is set too long, TCP waits longer after a genuine loss. The resulting idle period delays recovery and can reduce application performance.

TCP therefore calculates an RTO for each connection from measured Round-Trip Time (RTT). RFC 6298 specifies the estimator and requires a lower bound of one second for the computed RTO, subject to the implementation clock granularity.

Jacobson/Karels Estimator: RTT and RTO

The estimator associated with Jacobson and Karels does not use only the latest RTT measurement. It maintains a smoothed RTT and an estimate of RTT variation, then combines both values to set the retransmission timeout. The variation term is important on paths whose delay changes, because the same average RTT can produce very different timeout margins. RFC 6298 updates the variation before the smoothed RTT so that both values refer to the previous estimate when processing a sample.

1. Measuring Sample RTT ('SampleRTT')

   TCP measures the time between sending a segment and receiving the corresponding ACK. This is 'SampleRTT'. For an initial sample, RFC 6298 sets SRTT to the sample and RTTVAR to half the sample. A retransmitted segment creates ambiguity because an ACK may refer to its original transmission or its retransmission. Karn's algorithm therefore excludes measurements from retransmitted segments; TCP timestamps can identify the transmission and permit a sample when the timestamp rules apply, while an ordinary ambiguous sample is not used.

2. Calculating Smoothed RTT ('SRTT')

   A single 'SampleRTT' can be noisy. TCP maintains a Smoothed Round-Trip Time, 'SRTT', as a weighted moving average:

   $SRTT = (1 - \alpha) \cdot SRTT_{old} + \alpha \cdot SampleRTT$

   The parameter $\alpha$ (alpha) is commonly $1/8$. The new SRTT therefore gives 87.5% weight to the previous estimate and 12.5% to the newest measurement, reducing the effect of a single delay while following sustained change.

3. Accounting for Variance ('RTTvar')

   An average is not enough. A connection with an average RTT of 100 ms may produce samples of 80 ms and 120 ms. TCP therefore calculates RTT variation, 'RTTVAR', which tracks the smoothed absolute difference between a sample and the previous SRTT.

   $RTTvar = (1 - \beta) \cdot RTTvar_{old} + \beta \cdot |SRTT - SampleRTT|$

   The parameter $\beta$ (beta) is commonly $1/4$. The value is updated before SRTT uses the new sample, so the variation describes the previous estimate's deviation.

4. Calculating the Final RTO

   Finally, the Retransmission Timeout combines the smoothed RTT with a variation margin. RFC 6298 includes the clock granularity term and uses a factor of four:

   $RTO = SRTT + max(G, 4 \cdot RTTVAR)$

   The RTO is rounded up to at least one second. An implementation may impose a maximum, but that maximum must be at least 60 seconds. These bounds and the variation term reduce premature timeout decisions. G represents the clock granularity used by the implementation. After a timeout, the sender doubles the timer instead of treating the delayed ACK as a new RTT sample; this is the reason Karn's rule and exponential backoff appear together in the algorithm.

5. Exponential Backoff

   If a retransmitted segment also receives no ACK, expiration of the RTO causes another retransmission and exponential backoff. TCP doubles the RTO for each consecutive timeout for the same segment. With an initial RTO of 1 second, the sequence is 2, 4, and 8 seconds until a configured limit. After a timeout, RFC 6298 restarts the timer; a new valid RTT sample can lower the estimate again. For an unacknowledged SYN, the retransmission RTO is reinitialized to at least 3 seconds before data transfer.

2. TIME-WAIT Timer (2MSL)

After a typical orderly close, the endpoint that initiated the close does not immediately transition to 'CLOSED'. It enters TIME-WAIT, governed by a timer set to 2MSL. This state allows the endpoint to handle a retransmitted FIN and separates the old connection from a later connection that might reuse the same address and port tuple.

The Maximum Segment Lifetime (MSL) is the maximum time assigned to a segment for the purpose of this TCP rule. RFC 9293 uses two minutes for MSL in its specification, so 2MSL is four minutes there; an implementation may optimize the timer under the rules for timestamps. Waiting through this interval prevents old duplicates from being confused with a later connection. TIME-WAIT is maintained by the endpoint that performed the active close, and the state also lets it answer a retransmitted FIN with the required ACK.

Two Purposes of TIME-WAIT

The waiting period addresses two protocol requirements.

• Implementing Reliable Connection Termination

  The final exchange is the active closer sending an ACK in response to the passive closer's FIN. If that ACK is lost, the passive closer retransmits its FIN after its timer expires. Without TIME-WAIT, the active closer could already be in CLOSED and treat the retransmitted FIN as belonging to no connection, possibly responding with RST.

  During TIME-WAIT, the active closer retains enough state for 2MSL. If a retransmitted FIN arrives, it can send the final ACK again, allowing the passive closer to complete termination.

• Preventing Delayed Duplicates from Corrupting New Connections

  A segment from a previous connection can be delayed or duplicated in the network and delivered after the connection has closed.

  Consider a closed connection between $1.2.3.4:50000$ and $5.6.7.8:80$. A later connection between $1.2.3.4:50000$ and $5.6.7.8:80$ may reuse the same four-tuple. TCP sequence validation and TIME-WAIT reduce the chance that a delayed segment from the old connection is accepted as data for the new one.

  The 2MSL rule keeps the old tuple in TIME-WAIT while old duplicates can still be relevant. After the timer expires, the endpoint may move to CLOSED, subject to the implementation's reuse and timestamp rules.

3. Persistence Timer and Zero-Window Probing

TCP flow control has a failure scenario when a receiver advertises a zero receive window ('rwnd=0'). The sender stops sending new data. Later, the receiving application reads data and frees buffer space, so the receiver sends an ACK with a non-zero window update.

ACK-only segments are not reliably retransmitted by TCP. If the window update is lost, the sender may continue waiting for an update while the receiver waits for data, creating a zero-window deadlock.

The Persistence Timer breaks this deadlock. After a zero-window advertisement, the sender starts the timer. If it expires before a window update arrives, the sender transmits a small window probe. RFC 9293 specifies that the first probe is sent after the retransmission timeout and that the interval can back off exponentially. The probe contains at least one new octet when data is available, or retransmitted data, and the receiver responds with its current window. The probe is permitted even while the advertised window is zero, because its purpose is to discover a later window update and avoid an unrestricted data burst.

• If the window is still zero, the sender schedules another probe, with an interval that can increase through exponential backoff.
• If the window is now non-zero, the sender can resume data transmission within the advertised limit.

4. Optional Keep-Alive Timer

TCP connections can remain idle for hours, for example during an SSH session. If one endpoint crashes or loses network access without sending FIN, the peer can retain a half-open connection and its resources. A large number of such connections can contribute to resource pressure.

The Keep-Alive Timer is an optional TCP mechanism for testing an idle peer. The application controls whether it is enabled. RFC 1122 specifies a default-off behavior and an interval configurable by the application, with a default interval of at least two hours when keep-alive is used.

1. The server sends a keep-alive probe segment, usually an ACK with $SEG.SEQ = SND.NXT - 1$, chosen to elicit a response.
2. If the client responds with an ACK, the server has evidence that the TCP peer still responds and can reset its configured keep-alive timer.
3. If the client has crashed and rebooted, it may not recognize the connection and may respond with an RST (Reset), allowing the connection state to be removed.
4. If the client is unreachable, it may send no response. TCP does not define one universal probe count or interval, and a single missed probe does not prove that the peer is dead. The implementation or application policy determines whether later probes lead to closing the connection.

Keep-alive traffic can be filtered by middleboxes or confused with an application heartbeat. The default interval can also be too long for an application requirement, so many applications implement their own heartbeat and failure policy above TCP. A successful probe shows that the peer responded to a TCP segment at that time; it does not prove that the application is healthy or that the path will remain available. Applications should choose their own response deadline when they need a stronger liveness or transaction guarantee. A keep-alive response is also distinct from an acknowledgment of application data, so it should not be used as an application-level delivery receipt.