Editing Transmission Control Protocol (section)

===Selective acknowledgments===
{{see also|SACK Panic}}
Relying purely on the cumulative acknowledgment scheme employed by the original TCP can lead to inefficiencies when packets are lost. For example, suppose bytes with sequence number 1,000 to 10,999 are sent in 10 different TCP segments of equal size, and the second segment (sequence numbers 2,000 to 2,999) is lost during transmission. In a pure cumulative acknowledgment protocol, the receiver can only send a cumulative ACK value of 2,000 (the sequence number immediately following the last sequence number of the received data) and cannot say that it received bytes 3,000 to 10,999 successfully. Thus the sender may then have to resend all data starting with sequence number 2,000.

To alleviate this issue TCP employs the ''selective acknowledgment (SACK)'' option, defined in 1996 in {{harvtxt|RFC 2018}}, which allows the receiver to acknowledge discontinuous blocks of packets that were received correctly, in addition to the sequence number immediately following the last sequence number of the last contiguous byte received successively, as in the basic TCP acknowledgment. The acknowledgment can include a number of ''SACK blocks'', where each SACK block is conveyed by the ''Left Edge of Block'' (the first sequence number of the block) and the ''Right Edge of Block'' (the sequence number immediately following the last sequence number of the block), with a ''Block'' being a contiguous range that the receiver correctly received. In the example above, the receiver would send an ACK segment with a cumulative ACK value of 2,000 and a SACK option header with sequence numbers 3,000 and 11,000. The sender would accordingly retransmit only the second segment with sequence numbers 2,000 to 2,999.

A TCP sender may interpret an out-of-order segment delivery as a lost segment. If it does so, the TCP sender will retransmit the segment previous to the out-of-order packet and slow its data delivery rate for that connection. The duplicate-SACK option, an extension to the SACK option that was defined in May 2000 in {{harvtxt|RFC 2883}}, solves this problem. Once the TCP receiver detects a second duplicate packet, it sends a D-ACK to indicate that no segments were lost, allowing the TCP sender to reinstate the higher transmission rate.

The SACK option is not mandatory and comes into operation only if both parties support it. This is negotiated when a connection is established. SACK uses a TCP header option (see {{slink||TCP segment structure}} for details). The use of SACK has become widespread—all popular TCP stacks support it. Selective acknowledgment is also used in [[Stream Control Transmission Protocol]] (SCTP).

Selective acknowledgements can be 'reneged', where the receiver unilaterally discards the selectively acknowledged data. {{harvtxt|RFC 2018}} discouraged such behavior, but did not prohibit it to allow receivers the option of reneging if they, for example, ran out of buffer space.{{sfn|RFC 2018|p=10}} The possibility of reneging leads to implementation complexity for both senders and receivers, and also imposes memory costs on the sender.{{sfn|RFC 9002|loc=4.4. No Reneging}}