In the previous sections, we discussed how the TCP sequence number and acknowledgment number help provide reliability to the end application. But the default acknowledgement and the retransmission behavior are not throughput efficient due to the nature of TCP requiring to retransmit all the segments from the missing segment within the sliding window. The following is an illustration that helps us understand the default behavior better.

For illustration, we are using a TCP session with window size of five segments. Based on the window size, the Sender can send five segments before waiting for the acknowledgement. Accordingly, it sends five segments with seq=2,3,4,5,6. Receiver had received the segments with seq=2,4,5,6, but it didn't receive the segment with seq=3. While sending the ACK, the receiver sends with ack=3. As noted before, the ender will not only retransmit segment with seq=3, but also the remaining segments in the window.

This leads to retransmitting duplicate segments, causing throughput issues.

Selective acknowledgement solves this issue by allowing the receiver to selectively acknowledge non-contiguous segments. TCP SACK is a TCP option that will be negotiated during the initial TCP three-way handshake.

In the same example, the sender and receiver are enabled with TCP SACK. Please note that, TCP SACK will be included in the SYN segment to signal the capability to peer. Using the same example, when the receiver didn't receive segment with seq=3, it sends ACK segment with ack=3, but it also includes selective ACK for 4,5,6. This instructs the sender to just send the missing segments and not to retransmit other received segments. This avoids duplication and helps provide efficient throughput.