Visual RFC.
ALL RFCs / RFC 9293
Read the RFC ↗
RFC 9293 / RELIABLE TRANSFER

Loss & retransmission

06

The sender keeps unacknowledged data and retransmits when loss recovery requires it.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

RFC 9293 · § 3.8.1EXAMPLE
4 / 4
Loss & retransmissionA visibly dropped segment leaves a gap; timer expiry causes retransmission and a returning ACK.SenderReceiverDATA×lostRTO!Timeout → back offretransmit same bytescumulative ACKReceiver fills the missing range; sender can retire it
04
Deliver the missing bytes.

The receiver acknowledges the now-contiguous sequence.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
WHAT CHANGED
RFC 793 § 3.7RFC 9293 § 3.8.1

The early illustrative RTO procedure is replaced by a requirement to use RFC 6298. RFC 9293 § 5 documents the update chain.

Read the updated RFC section ↗
KEY POINT

Adapt the timeout to the path.

  • Compute the RTO using RFC 6298, including Karn’s algorithm for RTT sampling.
  • Timeout recovery retransmits unacknowledged data and backs off the timer.
  • A delayed or lost ACK can cause a retransmission even when the original data arrived.
DETAILS

This animation shows timer-based recovery. Fast retransmit and other recovery techniques also exist; a timeout is not the only trigger.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. A reliable byte stream
  2. Headers & connections
  3. Three-way handshake
  4. Sequence & acknowledgment
  5. Initial sequence numbers
  6. Loss & retransmission
  7. Flow control
  8. Congestion control
  9. Segments & small writes
  10. Graceful close
  11. Resets & idle probes
  12. Security & the consolidated spec
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗