Simulation-based Comparison of Tahoe, Reno, and SACK TCP

1. Simulation-based Comparison of Tahoe, Reno, and SACK TCP Kevin Fall & Sally Floyd Presented: Heather Heiman September 10, 2002

2. TCP Versions • Tahoe TCP • Reno TCP • New-Reno TCP • SACK TCP Network Performance Research Lab

3. Tahoe TCP • First implemented in 4.3 BSD in 1988 • Earlier TCP implementations used a go-back-n model to control network congestion • Tahoe TCP added Slow-Start, Congestion Avoidance, and Fast Retransmit Algorithms Network Performance Research Lab

4. Slow-Start • The congestion window (cwnd) is increased by 1 for every acknowledgement received, therefore the cwnd increases exponentially • Slow-Start continues until the cwnd is greater than or equal to the threshold • Threshold = cutoff point based on the last occurring congestion • Once the cwnd is greater than or equal to the threshold, congestion avoidance begins Network Performance Research Lab

5. Congestion Avoidance • Instead of increasing the cwnd by 1 each time an acknowledgement is received, the congestion avoidance algorithm increases the cwnd by 1 each RTT • cwnd grows linearly Network Performance Research Lab

6. Fast Retransmit • When a set number of duplicate acknowledgements have been received for the same packet, the data sender retransmits the packet without waiting for the retransmit timer to expire Network Performance Research Lab

7. Reno TCP • Same as Tahoe TCP, but changed Fast Retransmit to include Fast Recovery • Fast Recovery is entered once a certain number of duplicate acks have been received (generally the threshold is set to 3) • Like Fast Retransmit, the sender retransmits the packet that has been lost, but instead of slow-starting the cwnd is cut in half and then the sender counts duplicate acks to determine when to send packets Network Performance Research Lab

8. Reno TCP • Sender’s usable window = min(awin, cwnd + ndup) • awin = receiver’s advertised window • cwnd = sender’s congestion window • ndup = number of duplicate acks (remains at 0 until the number of duplicate acks reaches the threshold) • During Fast Recovery, the sender increases it’s usable window by the number of duplicate acks received Network Performance Research Lab

9. Reno TCP • Fast Recovery is exited when an ack is received asking for new data • Fast Recovery is optimal for the case when only one packet is lost from a window of data • The best rate Reno TCP can retransmit packets is the rate of 1 per RTT Network Performance Research Lab

10. New-Reno TCP • Same as Reno TCP, but implements a modification to the sender’s algorithm during Fast Recovery • In Reno TCP, if a partial ack is received, Fast Recovery is exited and the usable window size is reset to the cwnd size • In New-Reno TCP, if a partial ack is received, it indicates to the sender that the packet numbered immediately after the acked packet has been lost Network Performance Research Lab

11. New-Reno TCP • The packet is immediately retransmitted without waiting for the retransmit timer to expire • New-Reno exits Fast Recovery only when all the outstanding data when it began has been acked • A “maxburst” parameter is used to limit the number of packets that can be sent in response to a single ack, even if the cwnd would allow more packets to be sent • Maxburst = four when outside of Fast Recovery • Maxburst = two during Fast Recovery Network Performance Research Lab

12. SACK TCP • Explained in detail in RFC 2018 • Uses SACK blocks that contain information about received and queued non-contiguous data packets • The first block is required to keep track of the most recently received data sequence • SACK TCP uses the same algorithms for adjusting the cwnd • The main difference between SACK TCP and New-Reno TCP is during multiple packet loss Network Performance Research Lab

13. SACK TCP • During Fast Recovery, SACK has an extra variable called pipe • pipe is used to keep track of the number of outstanding packets • New or retransmitted data is only sent when pipe < cwnd • When a packet is sent, pipe is incremented by 1 • When a duplicate ack is received with a SACK option indicating new data has been received, pipe is decremented by 1 Network Performance Research Lab

14. SACK TCP • If a partial ack is received, pipe is decreased by 2 • This represents the original packet sent and the retransmitted packet • For partial acks, the sender never recovers slower than Slow-Start Network Performance Research Lab

15. SACK TCP • SACK TCP keeps track of all acks from previous SACK options using a data structure called the “scoreboard” • When the sender is allowed to send a packet, it retransmits the next packet on the list that the receiver is thought to have not received • If there are no packets on the list, then a new packet is sent Network Performance Research Lab

16. SACK TCP • If a retransmitted packet is lost, it is detected when the retransmit timer expires • When this occurs, the packet is retransmitted • Then SACK TCP goes into Slow-Start Network Performance Research Lab

17. Simulation Results • One Packet Loss: Tahoe TCP doesn’t perform as well as the other versions due to the fact it does slow-start after packet loss • Two Packet Losses: Reno TCP doesn’t do as well as New-Reno and SACK • Multiple Packet Losses: SACK TCP performs the best out of all the algorithms Network Performance Research Lab

18. TCP Option Numbers Network Performance Research Lab

19. Problems w/TCP • Unnecessary traffic due to retransmissions • Protocols that retransmit all unacknowledged data at a single time can overwhelm the network. • Unsuccessful connections • The load on network servers can be very high when processing unsuccessful connections • Beginning Connections without a Slow-Start can cause bursts of traffic Network Performance Research Lab

20. Network Performance Research Lab

21. Network Performance Research Lab