Send suggestions without assuming delivery
05UTO 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.
Separate fixture: an unsupported receiver ignores the UTO bytes and processes data normally. Its ordinary ACK does not prove acceptance of the UTO suggestion.
Key idea: Implementations MUST NOT assume UTO options are transmitted reliably.
Terms
- Advisory
- Information the peer considers under its own controls and policy.
- SYN
- The TCP flag used during connection opening.
- Silent ignore
- Continue normal TCP processing without applying this unsupported option.
Rules & examples
Implementations MUST NOT assume UTO options are transmitted reliably.
- Enabling UTO before open allows the initial SYN/SYN-ACK exchange to carry suggestions. No separate support-negotiation mechanism is defined. An enabled connection SHOULD also include UTO in the first packet without SYN (§3), useful when SYN cookies did not retain the earlier option.
- When a host starts using a new user timeout, it SHOULD include UTO in the next possible outgoing segment. Option space may prevent inclusion; no universal packet schedule is invented here.
- If the segment carrying an option is lost, the peer cannot use that update. UTO does not change processing of subsequent segments and has no separate reliable option-delivery handshake.
- Implementations MAY repeat the option when retransmitting its segment or attach it to stream bytes/acknowledgments for retransmission. These improve reliability but do not guarantee delivery.
- A TCP implementation without UTO support MUST silently ignore the unknown option. A normal data acknowledgment does not establish that the receiver applied the UTO suggestion. No UTO-specific success reply is defined.
- RFC 5482 §4.1 discusses paths that mishandle unknown options. Its historical study numbers are not current deployment measurements. The guide does not recommend blindly retrying an operation or application payload.
Both endpoints in the first frame are assumed UTO-capable and enabled before open. The final unsupported receiver is a separate fixture. The failed carrier stops before the receiver; a repeated carrier is a chosen successful delivery, not a guarantee. Ordinary TCP acknowledgments concern stream data, not UTO negotiation.
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.