Read the two edges of a SACK block
02A SACK block describes a contiguous range of received bytes. Its left edge is included; its right edge is the first byte after the range.
Four blocks use 34 bytes. Reserving twelve bytes for Timestamp and padding leaves 28 bytes: three SACK blocks use 26 of those bytes.
Source for this drawing: RFC 2018 · Read RFC section 3 ↗
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.
A first block [3000,3500) with cumulative ACK 4000 can report duplicate bytes. This extends the interpretation; it is not a formal Updates edge in the RFC Editor metadata.
Read the updated RFC section ↗SACK reports received ranges, not missing ranges or segment numbers.
- The SACK option has Kind 5. Its Length is 2 + 8 times the number of blocks. Each block uses two unsigned 32-bit sequence numbers in network byte order.
- A block [1300,1400) reports bytes 1300 through 1399. The right edge 1400 is excluded. Sequence numbers identify byte positions; they are not packet IDs.
- The 40-byte TCP option area holds at most four SACK blocks. With the Timestamp option and its usual two padding bytes consuming twelve bytes, at most three SACK blocks fit. Other options may leave room for fewer.
- The chosen report has cumulative ACK 1000 and blocks [1300,1400), [1100,1200). It describes two received islands above the first gap; it does not cumulatively acknowledge either island.
- RFC 2883 later extends the same option to report duplicate data in a first D-SACK block, possibly below the cumulative ACK or contained in a following block. These ordinary new-data examples do not prohibit that extension.
These examples stay far from 32-bit sequence wrap. A real TCP compares sequence numbers with TCP’s wrap-aware rules. The encoder checks option bytes and space, not full TCP validity, connection state or D-SACK semantics. Field boxes are schematic.
Read the RFC section ↗