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