Separate the user timeout from retransmission
01Transmission 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.
In a separate fixture, an acknowledgment arrives at t = 250 seconds. The illustrated outstanding data is acknowledged before the 300-second limit; this does not guarantee future connectivity.
Key idea: A user timeout ends an unacknowledged wait; an RTO schedules another transmission.
Terms
- User timeout
- The local limit on how long transmitted data may remain unacknowledged.
- Acknowledgment
- The peer’s indication that TCP bytes have been received.
- RTO
- Retransmission timeout: a timer for trying a segment again.
Rules & examples
A user timeout ends an unacknowledged wait; an RTO schedules another transmission.
- The user timeout is local and per connection. RFC 5482 lets an endpoint advertise advice, not force the peer to accept a deadline or guarantee that either endpoint stays connected.
- The illustrative ESTABLISHED connection has USER_TIMEOUT = 300 seconds and an initial retransmission timeout (RTO) of 5 seconds. These are chosen values, not universal defaults or a complete RTO/backoff model.
- In the outage fixture no acknowledgment arrives. An RTO can cause a retransmission before the user timeout expires. At the user timeout, TCP aborts the connection; a retry is not a new promise to wait indefinitely.
- The alternative final state starts a separate fixture: an acknowledgment at 250 seconds clears the illustrated outstanding data before its 300-second user timeout. Other connection failures and application policies remain possible.
- Advertised UTO values apply in synchronized states: ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING and LAST-ACK. Other states MUST use the base specification’s default timeout values (§3.3). Do not lengthen a SYN-only wait using this option.
A one-segment teaching timeline, not a TCP timer implementation. Later retransmission intervals, queue management, clock-reset details and other timeout conditions are omitted. RFC 9293 is the current TCP base; it does not obsolete RFC 5482.
Sources
New to this? Start hereA quick picture + helpful background
Suggest how long to keep waiting
Imagine two people holding a shared call open during a brief outage. Telling the other person your waiting limit can help, but they still choose their own limit. This analogy is not a promise that the network or either endpoint will stay available.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.