Summary

  • TCP's retransmission timeout determines when to send again; USER TIMEOUT determines when unresolved delivery has lasted long enough to abort the connection.
  • RFC 5482 encoded a peer's timeout suggestion in a four-byte option, but local applications, bounds and the CHANGEABLE flag retained final authority.

Two clocks answer different questions

Consider a TCP connection with data in flight and no useful acknowledgment returning. Its retransmission machinery estimates when another copy should be sent. That timer can expire, move the oldest queued segment back onto the wire, and start again. Repeating that action does not by itself say how long the application is willing to preserve the connection.

TCP's user timeout supplies the other decision. RFC 793 described it as a bound on how long transmitted data may remain unsuccessfully delivered before TCP aborts. RFC 9293 makes the event distinction explicit. A retransmission-timeout event sends the first queued segment again and reinitializes the retransmission timer. A USER TIMEOUT event flushes the queues, reports that the connection was aborted, deletes the transmission control block, and enters CLOSED.

The clocks can therefore disagree without contradiction. Another retransmission might be technically schedulable at the same moment that the user's persistence budget has expired. RTO adapts retry timing to observed round trips and loss ambiguity. USER TIMEOUT expresses how long unresolved delivery remains worth state, memory and application uncertainty.

This is also why user timeout is not an application request timeout in disguise. An application might abandon one operation while keeping a connection for later work, or it might require the transport connection itself to disappear when outstanding data cannot be delivered. TCP's parameter belongs to connection state and controls the latter action.

A suggestion encoded in seconds or minutes

The original timeout was local. One endpoint could not know how long the other intended to retain a disrupted connection. RFC 5482 introduced the TCP User Timeout Option so a host could communicate a preferred persistence interval to its peer.

The option is Kind 28 and four octets long. After kind and length, one granularity bit selects the unit: zero means seconds and one means minutes. The remaining 15 bits carry the unsigned timeout suggestion. This compact form spans intervals from one second to more than nine hours at second granularity, and from one minute to more than twenty-two days at minute granularity.

Those ranges made the option expressive, not authoritative. A received value advises the peer about the sender's expectation for the connection. The peer considers whether to alter its own USER_TIMEOUT. It does not surrender its local resource policy or give the remote endpoint a direct abort control.

RFC 5482 described four pieces of per-connection state. USER_TIMEOUT was the established local parameter. ADV_UTO held the value to advertise. ENABLED decided whether the option could be sent and processed, and defaulted to false. CHANGEABLE decided whether a received suggestion could modify the local timeout.

The last flag protected an important boundary. If an application had selected a specific timeout, CHANGEABLE could be false, and a received option then had to leave USER_TIMEOUT unchanged. TCP should still notify the application of the peer's suggestion. Evidence crossed the connection; authority did not.

Bounds were part of the protocol design

Even when CHANGEABLE permits adaptation, RFC 5482 requires implementations to impose upper and lower limits. An extremely short timeout can abort connections that are merely passing through a transient disruption or a high-delay path. An extremely long timeout can hold buffers and connection state long after useful progress has stopped.

The long-timeout risk is not abstract bookkeeping. A peer that completes many handshakes and requests long persistence can make a server retain state at lower attack traffic rates. The RFC discusses authentication and per-peer resource limits as possible mitigations, while leaving the selection of local policy to the implementation and application environment.

Interoperability also had to survive absence. TCP implementations that do not understand UTO silently ignore it under the ordinary option rules. Supporting hosts may still be unable to include it when TCP's forty-byte option space is consumed by other options. A missing UTO in a trace therefore does not prove that an application has no user timeout.

Nor can endpoint policy govern every stateful device on the path. A firewall may discard its connection record after an inactivity interval regardless of the endpoints' adopted USER_TIMEOUT values. A captured option proves only that a suggestion appeared at that observation point. It does not prove that the receiver adopted it or that an intermediary will preserve state for the same duration.

Keepalive could not become the earlier executioner

Keepalive and user timeout answer neighboring but different questions. Keepalive probes an otherwise idle connection according to an implementation's liveness policy. USER TIMEOUT limits unresolved delivery of outstanding data. When both are active, competing abort policies could make the advertised persistence preference meaningless.

RFC 5482 resolved the ordering mechanically: the keepalive timer must be greater than the adopted USER_TIMEOUT. Otherwise keepalive could terminate the connection before the user-timeout policy had a chance to govern it. This rule does not merge the mechanisms. It establishes which deadline owns the earlier decision.

The historical move was subtle. RFC 5482 did not invent connection persistence and did not replace retransmission. It exposed a local policy as a bounded suggestion, supplied enough state to decide whether that suggestion could matter, and documented the resource consequences of trusting it. The protocol carried a preference while preserving the right to say no.

Sources