Simulation-based Comparisons of Tahoe, Reno and SACK TCP

Summary

• Main point: Nothing compares to SACK TCP!
• Tahoe TCP: Follows a basic go-back-n model using slow-start, congestion avoidance and fast retransmit algorithms. With Fast Retransmit, after receiving a small number of duplicate acks for the same TCP segment, the data sender infers that the packet has been lost and retransmits the packet without waiting for the retransmission timer to expire.
• Reno TCP:
  • Modification to the Tahoe TCP Fast Retransmit algorithm to include Fast Recovery; this prevents the pipe from going empty after Fast Retransmit, thereby avoiding the need to slow start after a single packet loss.
  • A TCP sender enters Fast Recovery after receiving athreshold number of dup acks. The sender retransmits one packet and reduces its congestion window by half. Instead of slow-starting, the Reno sender uses additional incoming dup acks to clock subsequent outgoing packets.
  • Reno TCP greatly improves performance in the face of single packet loss, but can suffer when multiple packets are lost.
• New Reno TCP: In Reno, a partial ack (ack for some but not all of the packets that were outstanding at the start of the fast recovery period) takes TCP out of Fast Recovery. In New Reno, partial acks fo not take TCP out of fast recovery; partial acks receivbed during fast recovery are treated as an indication that the packet immediately following the acked packet has been lost and should be retransmitted. Thus, when multiple packets are lost, New Reno can recover without a retransmission timeout.
• SACK TCP: The TCP sender maintain a scoreboard which keeps track of acks from previous SACK packets. When the sender is allowed to send a packet, it retransmits the next packet from the list of packets inferred to be missing at the receiver. If there are no such packets and the receiver's advertized window is sufficiently large, the sender sends a new packet.
• Simulations:
  • One packet loss: Tahoe TCP does badly due to slow-start after the packet loss. All others do relatively the same.
  • Two packet losses: Reno TCP fails to do as well as New Reno or SACK TCP, since its algorithm is tuned for single packet losses.
  • Multiple packet losses: Reno TCP performs miserably in the face of a large number of packet losses. SACK TCP continues to out-perform the rest of the algorithms.

  ---

  Back to index (Created by Yatin Chawathe)