Harry Chandra Tanuwidjaja

20165650

Reading Assignment 8 – Simulation-based Comparisons of Tahoe, Reno, and

SACK TCP Kevin Fall and Sally Floyd

This paper proposes New-Reno TCP, a modified Reno TCP without Selective Acknowledgement (SACK) and
SACK TCP, an extension of Reno TCP with an addition of SACK option. They compare the performance of
New-Reno TCP, SACK TCP, Tahoe TCP, and Reno TCP by simulation. Reno and New-Reno retransmit at
most one dropped packet per round trip time to recover from lost data, while Tahoe retransmit packet
that have been successfully delivered. On the other hand, in SACK TCP, a sender can identify which packets
have been successfully delivered, so he can avoid unnecessary delays and retransmission, resulting in
improved throughput. During the simulation, the writer of this paper shows that adding SACK to TCP is
very important. This paper is good, because it shows the comparison between Reno, New-Reno, SACK,
and Tahoe TCP in same environmental simulation with various test case (one, two, three, and four packet
loss), so the reader can understand well about the characteristic difference between the four TCP
methods. The weakness of this paper is stability issue in SACK TCP. In SACK TCP, in order to indicate
congestion, sender will continually increase the sending rate until there is congestion, and the rate will be
back to normal. So the sending rate is keep oscillating. It will be better if we can flatten the sending rate
at optimal bandwidth. My question is, in SACK TCP, if we measure change in throughput, rather than
packet loss during the congestion estimation, will this give the better utilization of bandwidth? Any
possible negative effect of this change? And, what are the challenges to incorporate SACK in the current
TCP?