Simulation-based Comparison of Tahoe, Reno, and SACK TCP
Kevin Fall & Sally Floyd
Presented: Heather HeimanSeptember 10, 2002
Heather Heiman Network Performance Research Lab
2
TCP Versions Tahoe TCP Reno TCP New-Reno TCP SACK TCP
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman 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
Heather Heiman Network Performance Research Lab
18
TCP Option Numbers
Heather Heiman 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
Heather Heiman Network Performance Research Lab
20
Heather Heiman Network Performance Research Lab
21
Top Related