Recover safely after a timeout
05A receiver may run short of buffer space and discard data it reported with SACK. This is called reneging. The sender must retain a way to recover.
After A is acknowledged to 1100, later recovery can retransmit B=[1100,1200) even though B was previously SACKed. C and D remain pending in this example.
Source for this drawing: RFC 2018 · Read RFC section 8 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Ignoring prior SACK information after a timeout is SHOULD, not MUST. Retaining payload until cumulative ACK and retransmitting the left edge after timeout remain MUST requirements.
Read the updated RFC section ↗A timeout can invalidate the assumption that previously SACKed data is still queued.
- The receiver MAY discard data it reported in SACK, although this is discouraged. Except for the newest segment, SACK blocks MUST NOT report old data no longer held. The first block MUST at least report the newest segment even if it will be discarded.
- After a retransmission timeout, section 5 says the sender SHOULD clear its SACKed flags. Verified technical erratum 1610 changes section 5.1’s instruction to ignore prior SACK information from MUST to SHOULD. This drawing chooses that recommended clearing behavior.
- The sender MUST retransmit the segment at the left edge after timeout even if its SACKed bit is on. The erratum does not weaken this separate section 5 requirement.
- The sender MUST NOT discard payload before cumulative acknowledgment. Retaining it allows a later retransmission of bytes previously reported by SACK. This is a bounded recovery example, not a prescribed timer value or a complete congestion-control implementation.
- SACK retains TCP’s existing security properties. It is not authentication, encryption, or a guarantee that every lost segment is instantly identified.
Separate failure scenario: after reporting B–D, the receiver discards those queued ranges before A arrives. A retransmission timeout occurs at the sender. The chosen subsequent recovery sends A and then B; the illustration does not prescribe the spacing, congestion window or all remaining recovery actions.
Read the RFC section ↗