Report a changed receive queue
03The receiver can hold later bytes while an earlier range is missing. Each new arrival changes the queue and may change its SACK report without advancing the cumulative ACK.
Now [1000,1400) is contiguous. ACK 1400 cumulatively acknowledges these bytes; no above-ACK block remains to report in this example.
Source for this drawing: RFC 2018 · Read RFC section 4 ↗
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.
The first block normally contains the segment that triggered this ACK.
- For ordinary new data, the first SACK block MUST contain the segment triggering the ACK, unless that segment advanced the cumulative ACK field.
- The receiver SHOULD include as many distinct blocks as space allows and SHOULD repeat recently reported blocks that are not subsets of blocks already included. After the first block, the others may be in arbitrary order.
- If SACK is used, the receiver SHOULD acknowledge each valid segment containing new data in this out-of-order situation, with a SACK option. A lost report can be compensated by repeating blocks; repetition does not guarantee delivery.
- In this chosen four-segment example, A=[1000,1100) is initially missing. B arrives, then D, then C bridges their ranges. Finally A fills the first gap and the cumulative ACK advances to 1400.
Each segment in this teaching example is 100 data bytes. Permission was received and the receiver chooses to generate SACK. Buffer space and the receive window allow these bytes. RFC 2018 section 7 has separate published examples with 500-byte segments.
Read the RFC section ↗