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

Heather HeimanNetwork Performance Research Lab2 TCP Versions Tahoe TCP Reno TCP New-Reno TCP SACK TCP

Heather HeimanNetwork Performance Research Lab3 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

Heather HeimanNetwork Performance Research Lab4 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

Heather HeimanNetwork Performance Research Lab5 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

Heather HeimanNetwork Performance Research Lab6 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

Heather HeimanNetwork Performance Research Lab7 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

Heather HeimanNetwork Performance Research Lab8 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

Heather HeimanNetwork Performance Research Lab9 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

Heather HeimanNetwork Performance Research Lab10 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

Heather HeimanNetwork Performance Research Lab11 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

Heather HeimanNetwork Performance Research Lab12 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

Heather HeimanNetwork Performance Research Lab13 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

Heather HeimanNetwork Performance Research Lab14 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

Heather HeimanNetwork Performance Research Lab15 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

Heather HeimanNetwork Performance Research Lab16 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

Heather HeimanNetwork Performance Research Lab17 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

Heather HeimanNetwork Performance Research Lab18 TCP Option Numbers

Heather HeimanNetwork Performance Research Lab19 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

Heather HeimanNetwork Performance Research Lab20

Heather HeimanNetwork Performance Research Lab21