Selective acknowledgments describe islands beyond a gap

A TCP SACK block supplies a left edge and a right edge for a contiguous received range. The left edge identifies its first byte and the right edge the next position after its last byte. Thus [8,001,10,001) represents 2,000 bytes. Several blocks can report separated islands beyond the cumulative acknowledgment. The ordinary ACK number still identifies the earliest unfilled position in order. A SACK block reaching a high number does not advance that ACK across a lower gap, and adding the block endpoints is not a meaningful byte-count calculation.

SACK support is negotiated with the SACK-Permitted option during connection establishment. Actual SACK information occupies finite TCP option space, which can also be needed by other options. A report therefore need not list every island the receiver currently holds. Omission of a previously reported range in one later ACK is not, by itself, proof that it disappeared or was never received. Reconstruct the connection over time and distinguish positive reported evidence from missing information. Relative sequence displays remain useful for reading intervals, provided all endpoints refer to the same direction and connection.

The sender can maintain a scoreboard of reported ranges, inferred holes, and retransmitted data. This supports recovery from multiple losses in one flight without resending every byte after the first gap. A missing range is a candidate for repair, but the exact rule declaring it lost depends on the recovery algorithm and reordering tolerance. Selective reporting and loss detection are related yet separate mechanisms: SACK communicates observations, while the sender decides how to use them. Congestion control still limits how much repair and new traffic may enter the network.

Do not interpret selectively acknowledged data as permission to discard all responsibility for those bytes. RFC 2018 permits a receiver, exceptionally, to discard previously SACK-reported data before cumulative acknowledgment, although it discourages doing so. This possibility is called reneging. Senders retain data until it is cumulatively acknowledged and recovery logic must account for receiver reports being advisory in this sense. Even cumulative transport acknowledgment remains distinct from application persistence. These two limitations arise at different boundaries: one concerns receiver reassembly state, while the other concerns what the application does after stream receipt.

A sender-side capture may miss ACKs, record segmentation offload before actual packetization, or observe retransmissions without the receiver's full state. A receiver-side capture provides different evidence and can itself drop records under load. Align clocks carefully when comparing traces and record which observation point contains each event. A visible overlap between ranges may be retransmission, duplicate capture, or changed segmentation; packet count alone is insufficient. Build a timeline of sequence intervals, ACK movement, SACK blocks, and recovery transitions before blaming an implementation for resending something the analyst merely assumes was safely held.

Use the binomial lab to examine how multiple potential holes arise in an intentionally independent delivery model. Interpret success as segment delivery, hold p at 0.8, and increase n. Compare the mass below n−1 successful deliveries, representing at least two failed pieces. The bars cannot locate the holes or produce a SACK block; positions and recovery timing are absent. Predict how a larger flight can make multi-hole repair important, then use the worked interval example to decide which actual byte ranges require attention. Correlated congestion losses can differ sharply from this distribution.