Simulationbased 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

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

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

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

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

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

8
Reno TCP

• Senders usable window min(awin, cwnd ndup)
• awin receivers advertised window
• cwnd senders 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 its
  usable window by the number of duplicate acks
  received

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

10
New-Reno TCP

• Same as Reno TCP, but implements a modification
  to the senders 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

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

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

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
  lt 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

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

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

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

17
Simulation Results

• One Packet Loss Tahoe TCP doesnt perform as
  well as the other versions due to the fact it
  does slow-start after packet loss
• Two Packet Losses Reno TCP doesnt do as well as
  New-Reno and SACK
• Multiple Packet Losses SACK TCP performs the
  best out of all the algorithms

18
TCP Option Numbers
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

20
(No Transcript)
21
(No Transcript)