Simulation-based comparisons of Tahoe, Reno and SACK TCP

TLDR

The study uses simulations to evaluate the benefits of adding selective acknowledgments (SACK) and selective repeat to TCP. The authors simulate Tahoe and Reno TCP together with New‑Reno and SACK‑TCP variants, implementing and comparing their congestion‑control algorithms. The results show that SACK is not required to resolve Reno’s multi‑packet drop problems, but its absence limits performance by restricting retransmissions to at most one packet per round‑trip time or causing duplicate retransmissions.

Abstract

This paper uses simulations to explore the benefits of adding selective acknowledgments (SACK) and selective repeat to TCP. We compare Tahoe and Reno TCP, the two most common reference implementations for TCP, with two modified versions of Reno TCP. The first version is New-Reno TCP, a modified version of TCP without SACK that avoids some of Reno TCP's performance problems when multiple packets are dropped from a window of data. The second version is SACK TCP, a conservative extension of Reno TCP modified to use the SACK option being proposed in the Internet Engineering Task Force (IETF). We describe the congestion control algorithms in our simulated implementation of SACK TCP and show that while selective acknowledgments are not required to solve Reno TCP's performance problems when multiple packets are dropped, the absence of selective acknowledgments does impose limits to TCP's ultimate performance. In particular, we show that without selective acknowledgments, TCP implementations are constrained to either retransmit at most one dropped packet per round-trip time, or to retransmit packets that might have already been successfully delivered.