Visual RFC.
ALL RFCs / RFC 5482
Read the RFC ↗

RFC 5482 / START HERE

TCP user timeout, before the details

TCP means Transmission Control Protocol; UTO means User Timeout Option. The option suggests a waiting limit to the other endpoint.

A TCP sender waits for acknowledgments of transmitted bytes. Its local user timeout limits that wait before the connection is aborted. RFC 5482 adds a four-byte option advertising a suggested interval.

Why it exists

A longer local wait alone may not help if the other endpoint gives up sooner. UTO lets peers consider each other’s suggestions while preserving application choices and mandatory limits. It is not a binding negotiation, a retransmission timer or a guarantee of connectivity.

A familiar example

A fictional picnic-planning app briefly loses connectivity. An endpoint can suggest a longer wait, but the peer may limit or ignore it, and a firewall can still expire earlier. The chapters show real option bytes, local controls, bounded calculations, loss and other timers.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Separate the user timeout from retransmissionTransmission Control Protocol (TCP) delivers an ordered byte stream. A sender retains transmitted bytes until the peer acknowledges them. Its local user timeout limits how long that wait may last.
  2. Read the four option bytesThe UTO option occupies four octets in the TCP header’s option area. Its final two octets contain a granularity bit and a 15-bit unsigned suggestion.
  3. Keep application choices in controlThe option has local control variables. Enabling it permits sending and receiving suggestions; a separate flag decides whether received advice may change the local timeout.
  4. Apply local upper and lower limitsLong waits consume connection state; very short waits can abort useful connections before an acknowledgment arrives. Both endpoints keep their own limits.
  5. Send suggestions without assuming deliveryUTO is advisory and has no reliability handshake of its own. A lost option leaves the peer without that update; even acknowledgment of data is not proof of accepting its option.
  6. Respect keep-alives, middleboxes and resourcesOther timers and resource policies can end a connection earlier. A longer suggested user timeout neither preserves firewall state nor reserves unlimited server memory.
Start with chapter one →

This introduction explains RFC 5482 (2009). Read the original RFC ↗