Worst-case performance limitation of TCP SACK and a feasible solution

In the present implementation of the transmission control protocol (TCP) selective acknowledgment (SACK), every SACK block needs 8 bytes to carry information about the received packets, back to the sender. Since TCP options field has a fixed length, there is a limit on the number of SACK block that can be carried by the acknowledgment packets. Under some error conditions, this limitation can force the TCP sender to retransmit packets that have already been received successfully by the receiver. This paper puts forward a proposal to modify the present SACK implementation, in order to prevent these unwanted retransmissions. We show that the proposed implementation of SACK mechanism increases the throughput of SACK enabled TCP connections.

1. Introduction

New Reno is the present default Transmission Control Protocol (TCP) implementation in most systems. However, when multiple packets are lost from a window of New Reno implementation, TCP may end up either re-transmitting packets that might have already been successfully received, or re-transmitting at most one dropped packet per round-trip time. To overcome this limitation, a selective acknowledgment (SACK) mechanism was defined in RFC 2018 [1]. In TCP SACK. the receiver can inform the sender about all the segments that have been received successfully. allowing the sender to retransmit only the segments that have actually been lost.