This paper explores the benefits of adding selective acknowledgments (SACK) and selective repeat to TCP through simulations. It compares Tahoe and Reno TCP, the two most common reference implementations, with two modified versions of Reno TCP: New-Reno and SACK TCP. New-Reno is a modified version of Reno TCP that avoids performance issues when multiple packets are dropped from a window of data without using SACK. SACK TCP is a conservative extension of Reno TCP that incorporates the SACK option proposed by the Internet Engineering Task Force (IETF). The paper highlights that while SACK is not necessary to solve Reno TCP's performance problems when multiple packets are dropped, the absence of SACK imposes limits on TCP's performance. Specifically, without SACK, TCP implementations can only retransmit at most one dropped packet per round-trip time or retransmit packets that might have already been successfully delivered. This is in contrast to Tahoe TCP, which can retransmit multiple dropped packets per round-trip time. The simulations demonstrate that SACK TCP performs better than New-Reno and Reno TCP, especially in scenarios with multiple packet drops. SACK TCP can avoid unnecessary delays and retransmissions, leading to improved throughput. The paper also includes a trace of Reno TCP traffic from actual Internet measurements, showing that Reno TCP without SACK experiences significant performance issues when multiple packets are dropped from a window of data. The paper concludes by discussing future directions for TCP with SACK and emphasizes the importance of adding SACK to TCP to improve its performance.This paper explores the benefits of adding selective acknowledgments (SACK) and selective repeat to TCP through simulations. It compares Tahoe and Reno TCP, the two most common reference implementations, with two modified versions of Reno TCP: New-Reno and SACK TCP. New-Reno is a modified version of Reno TCP that avoids performance issues when multiple packets are dropped from a window of data without using SACK. SACK TCP is a conservative extension of Reno TCP that incorporates the SACK option proposed by the Internet Engineering Task Force (IETF). The paper highlights that while SACK is not necessary to solve Reno TCP's performance problems when multiple packets are dropped, the absence of SACK imposes limits on TCP's performance. Specifically, without SACK, TCP implementations can only retransmit at most one dropped packet per round-trip time or retransmit packets that might have already been successfully delivered. This is in contrast to Tahoe TCP, which can retransmit multiple dropped packets per round-trip time. The simulations demonstrate that SACK TCP performs better than New-Reno and Reno TCP, especially in scenarios with multiple packet drops. SACK TCP can avoid unnecessary delays and retransmissions, leading to improved throughput. The paper also includes a trace of Reno TCP traffic from actual Internet measurements, showing that Reno TCP without SACK experiences significant performance issues when multiple packets are dropped from a window of data. The paper concludes by discussing future directions for TCP with SACK and emphasizes the importance of adding SACK to TCP to improve its performance.