Summary

  • TCP’s user timeout is a local, per-connection limit on how long transmitted data may remain unacknowledged before the endpoint aborts. It is distinct from the retransmission timer that decides when to send a segment again.
  • RFC 5482 created a four-byte User Timeout Option so one endpoint could advertise its current value. The message is advice, not binding negotiation: the peer may ignore it, clamp it to local limits or refuse to let it override an application-set timeout.
  • Longer timeouts can preserve a connection through a connectivity gap, but keep queues and connection state alive. Shorter values release state sooner, but can turn delay or transient loss into an avoidable abort.

Two clocks on one unanswered byte

Begin with an established connection and one byte that has not been acknowledged. TCP’s retransmission timer can expire, return the segment to the wire and start timing again. Another clock answers a different question: how long is the application willing to let transmitted data remain unacknowledged before the connection itself is no longer useful?

RFC 793 called that second limit the user timeout. When it expires, the prescribed action is not another retransmission. TCP flushes the queues, reports that the connection was aborted, deletes its transmission control block and enters CLOSED. RFC 9293 preserves this separation in the current consolidated specification: RETRANSMISSION TIMEOUT resends; USER TIMEOUT ends the state.

That distinction is the centre of RFC 5482. A retransmission timer estimates when another attempt may be worthwhile. A user timeout marks the endpoint’s limit for waiting. Conflating them makes a connection look dead merely because one sending interval elapsed, or keeps application state alive because the transport can still try again.

The decision existed before the option

The 1981 interface in RFC 793 already let an application supply a timeout when opening a connection and change it on a send. The policy was local. Two applications using TCP for different purposes did not have to value continuity equally, and the transport did not need a message from the network before obeying its user.

RFC 1122 refined failure handling in 1989 with thresholds R1 and R2. Reaching R1 should notify lower layers and can alert the application that delivery is in trouble. Reaching the larger R2 closes the connection. Crucially, an application must be able to set R2 for a particular connection; an interactive program could even choose an effectively infinite value and leave the decision to a person. The recommended R2 for data corresponds to at least 100 seconds, not a universal application requirement.

This made failure policy adaptable at one endpoint. It did not coordinate the other. If a mobile host lengthened its local timeout to survive a handoff, the peer might still abandon the connection earlier. If a busy service wanted to release silent state quickly, its client had no protocol signal explaining that budget.

Four bytes that did not close a deal

RFC 5482, published in 2009, gave that local decision a compact representation. TCP option Kind 28 has Length 4. A one-bit G field selects seconds or minutes; the remaining 15 bits carry the suggested value. Zero is reserved. The range allows fine short values in seconds and much longer intervals in minutes without turning the option into a retransmission count or round-trip estimate.

When enabled before an active or passive open, UTO can appear in the SYN and SYN-ACK. The first packet without SYN should carry it as well, which helps when a server did not retain option state from the opening exchange. An endpoint should send another option when it starts advertising a different value. A TCP that does not implement UTO must silently ignore it.

The option’s economy is easy to overread. RFC 5482 says the exchange is not binding negotiation. Sending a UTO suggests that the peer consider adapting its own user timeout; it does not commit the sender to keep the connection for that period, and it does not compel the receiver to adopt the number.

Whose policy wins

RFC 5482 names the control points explicitly. USER_TIMEOUT is the local limit. ADV_UTO is the value advertised to the peer. REMOTE_UTO is the last suggestion received. ENABLED controls whether the extension is in use, while CHANGEABLE controls whether peer advice may alter the local value.

UTO is disabled by default. CHANGEABLE normally begins true, but if the application explicitly sets USER_TIMEOUT, it must become false. A packet from the peer cannot silently overrule a local application request. The implementation may still notify the application that another value arrived, leaving the decision where it belongs.

When adaptation is permitted, RFC 5482 recommends taking the maximum of the local and remote advertised values, then applying local lower and upper limits. Choosing the larger suggestion favours survival through disruption. The bounds protect the endpoint from a value that is too short for the current retransmission timeout or too long for its resource policy.

Even that rule does not make the endpoints identical. Each can apply different limits. Either can close or abort independently. The option exposes preference; it does not create joint custody of connection state.

Advice that may never arrive

Most TCP options shape how later segments must be processed and therefore depend on a reliable opening exchange. UTO is different. If its segment is lost, the peer simply misses an opportunity to update local policy. RFC 5482 does not define a reliability handshake, and implementations must not assume delivery. They may repeat the option with a retransmission, but the result is still not guaranteed.

The finite option space adds another boundary. A TCP header has only forty bytes available for options, so a connection using other extensions may have no room for UTO. Some middleboxes may mishandle an option sent after the handshake. A stateful firewall can also discard idle flow state on its own schedule, regardless of what either endpoint advertised.

UTO therefore cannot prove path liveness. It cannot guarantee that the peer saw the number, that an intermediary will preserve the flow or that the next acknowledgment will return. It is a policy hint carried by the connection, not evidence that the network will honour the interval.

Survival has a price

Longer user timeouts help when connectivity interruptions are expected: a mobile handoff, routing disruption or intermittent path need not destroy an otherwise useful connection. But the endpoint must retain the queues and control state during the silence. A client that completes many handshakes and suggests very long timeouts can increase a server’s exposure to resource exhaustion.

RFC 5482 therefore requires implementations to impose upper and lower limits. Local policy can consider authentication, per-peer connection counts, resource use and attack conditions. A server retains the right to shed state; adopting a long suggestion does not make closure forbidden.

Very short values create the inverse risk. If the user timeout expires before an acknowledgment delayed by loss or path latency arrives, TCP closes a connection that might otherwise have recovered. The recommended lower limit must be greater than the current retransmission timeout. The option is not a licence to turn a timing preference into an aggressive failure detector.

Keep-alives remain separate. If both mechanisms are enabled, RFC 5482 requires the keep-alive timer to exceed the adopted user timeout so a different keep-alive abort policy does not terminate the connection first. UTO does not send probes, authenticate a peer or replace application knowledge about whether a session is still useful.

What the option changed

RFC 5482 did not invent application control over connection patience. It made one endpoint’s current policy visible to the other and offered a bounded way to react. The lasting design lesson is the restraint of the message: the peer can hear the timer without acquiring authority over it.

That makes UTO different from neighbouring TCP histories. Window Scale fixes how a field will be interpreted after its handshake exchange. PAWS uses timestamps to reject old sequence-space meaning. SACK reports byte ranges that arrived beyond a gap. User Timeout instead concerns how long local state remains worth keeping when acknowledgment does not arrive.

The RFC packet does not establish how widely UTO is deployed today, which operating systems expose which interfaces or what defaults particular applications use. It establishes a narrower history: TCP learned to communicate a limit on patience while keeping the final decision local.

Sources