TCP Variations:

Tahoe, Reno, New Reno, Vegas, Sack

Paul D. Amer, Professor

Computer & Information Sciences

University of Delaware
 What are TCP Variations?

Implementations of TCP that use different

algorithms to achieve end-to-end
congestion control.
Tahoe
Reno
NewReno
Vegas
 Evolution of TCP
1984
Nagels algorithm 1987 1990
to reduce overhead Karns algorithm 4.3BSD Reno
1975 of small packets; fast recovery
to better estimate
Three-way handshake predicts congestion round-trip time delayed ACKs
Ray Tomlinson collapse
In SIGCOMM 75 1988
Van Jacobsons
1983 algorithms
BSD Unix 4.2 1986 slow start,
1974 supports TCP/IP Congestion congestion
TCP described by collapse avoidance, fast
Vint Cerf, Bob Kahn st
1 observed retransmit (all
1981 implemented in
In IEEE Trans Comm TCP & IP 4.3BSD Tahoe)
RFC 793 & 791 SIGCOMM 88

1975 1980 1985 1990

 Evolution of TCP
1996
NewReno
modified fast
1994
recovery
T/TCP
SACK TCP
Transaction TCP
Selective Ack
(Braden)
(Floyd et al)
1993 1994 1996
TCP Vegas(not ECN 1996 FACK TCP
implemented) Explicit Improving TCP Forward Ack
real congestion Congestion startup extension to SACK
avoidance Notification (Hoe) (Mathis et al)
(Brakmo et al) (Floyd)

1993 1994 1996

 How did TCP cause Congestion?
(original recipe TCP)

Poor Efficiency
In telnet-like applications, TCP sends 1 byte of data
with 4000% overhead.
Sending too much, too soon
Unnecessary retransmits
Send window too big
Very little change in behavior due to congestion
 Self-clocking or ACK Clock
Pb Pr

Sender Receiver

Ab
As
Ar

Self-clocking systems tend to be very stable under a wide

range of bandwidths and delays.
The principal issue with self-clocking systems is getting
them started.
TCP Algorithms:
Four intertwined algorithms used commonly in TCP
implementations

Slow Start - Every ack increases the senders window

(cwnd) size by 1
Congestion Avoidance - Reducing senders window size by
half at experience of loss, and increase the senders
window at the rate of about one packet per RTT (NOTE:
not per ack)
Fast Retransmit - Dont wait for retransmit timer to go off,
retransmit packet if 3 duplicate acks received
Fast Recovery - Since duplicate ack came through, one
packet has left the wire. Perform congestion avoidance,
dont jump down to slow start
 Slow Start Packet
Ack
TCP
TCP
Sender
t=0r Receiver
cwnd=1
pkt 0
ack 0
new cwnd t=1r
= cwnd=2
old cwnd pkts 1,2
+
acks 1,2
# acks recd t=2r
cwnd=4
pkts3,4,5,6

t=3r
cwnd=8
 Congestion Avoidance Packet
Ack
After cwnd reaches
a certain threshold TCP
TCP
Sender
t=xr Receiver
cwnd=4

new cwnd t=(x+1)r

= cwnd=5
old cwnd
+
# acks/cwnd t=(x+2)r
cwnd=6

t=(x+3)r
cwnd=7
 S R
cwnd = 1
Example: Slow Start/Congestion Avoidance
cwnd = 2
assume ssthresh = 8*MSS
cwnd = 4
12
congestion window size

10
ssthresh cnwd = 8
8
(in MSS)

2
cwnd = 9
0
1 2 3 4 5 6 7
transmission number
cwnd = 10

cwnd = 11
 Slow Start & Congestion Avoidance
Initally:
- cwnd = 1*MSS
- ssthresh = very high cwnd (initial) ssthresh

If a new ACK comes: Loss, e.g. timeout

- if cwnd < ssthresh update
cwnd according to slow start
- if cwnd > ssthresh update
ssthresh
cwnd according to congestion
avoidance
- If cwnd = ssthresh either
slow start in green time

If timeout (i.e. loss) : congestion avoidance in blue

- ssthresh = flight size/2;
- cwnd = 1*MSS
 Fast Retransmit Packet
Ack
At a random point
in the transfer TCP
TCP
Sender
Receiver

t=xr

t=(x+1)r

3 dup acks

Fast
Retransmit
 TCP Tahoes Fast Retransmit
S R
1. Sender cwnd = 1
receives 3
dupACKS. cwnd = 2

2. Sender infers
that the cwnd = 4
segment is
lost.
3. Sender re- 3 duplicate
sends the ACKs
segment
immediately!
4. Sender returns
fast-retransmit
to slow-start.
of segment 4
TCP Variants :
TCP-Tahoe:
implements the slow start, congestion avoidance, and
fast retransmit algorithms

TCP-Reno:
implements the slow start, congestion avoidance, fast
retransmit, and fast recovery algorithms

Among other implementations are Vegas,

NewReno (the most commonly implemented on
webservers today, according to a survey) and
SACK TCP.
 TCP Tahoe Trace
(with one dropped segment)
500000 48

Sent Segment 44
ACK'ed Segment
480000 cwnd 40
ssthresh
36

460000 32
Lost segment
Fast Retransmit
Sequence #

28

MSS
440000 24

20
Begin congestion
420000 avoidance 16
Begin slow-start
12

400000 8

380000 0
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time (s)
 TCP Tahoe Trace
(with one dropped segment)
500000 48

Sent Segment 44
ACK'ed Segment
480000 cwnd 40
ssthresh
36

460000 32
Sequence #

28

MSS
440000 24

20

420000 16

12

400000 8

380000 0
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time (s)
 Could Tahoe be Improved?

Receipt of dupACKs tells the

sender that the receiver is
still getting new segments,
i.e. there is still data flowing
between sender and
receiver
Why does sender go back to
slow start after fast
retransmit?
Why does sender let Ack
clock die?
 TCP Variation: TCP Reno

2nd Improvement was TCP Reno (1990)

Nagles algorithm
Improved RTO calculation and back-off
AIMD congestion avoidance with slow-start
Fast retransmit & fast recovery
 Fast Recovery
Concept: cwnd (initial) ssthresh
After fast retransmit, fast-retransmit
reduce cwnd by half, and fast-retransmit timeout
continue sending
segments at this reduced
level. new ACK
new ACK

Problems:
Sender has too many
outstanding segments.
How does sender transmit
packets on a dupACK? Time
Slow Start Congestion Avoidance
Need to use a trick -
inflate cwnd.
inflating cwnd with dupACKs

deflating cwnd with a new ACK

 Fast Retransmit & Fast Recovery
After receiving 3 dupACKS:
1. Retransmit the lost segment.
2. Set ssthresh = flight size/2.
3. Set cwnd = ssthresh, and ndupacks = 3.
N.B. In Reno: send_win = min ( rwnd, cwnd + ndupacks ).
If dupACK arrives:
++ ndupacks
Transmit new segment, if allowed.
If new ACK arrives:
ndupacks = 0
Exit fast recovery.
If RTO expires:
ndupacks = 0
Perform slow-start - ( ssthresh = flight size/2, cwnd = 1 )
 TCP Reno Trace
(with one dropped segment)
500000 48

Sent Segment
44
ACK'ed Segment
cwnd
480000 40
ssthresh
cwnd+ndupacks
36

460000 32
Sequence #

28

MSS
440000 24

20

420000 16

12

400000 8

380000 0
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time (s)
 TCP Tahoe & Reno Trace
(with two dropped segments)
500000

Tahoe
Reno
480000 Tahoe & Reno

460000
Sequence #

440000

420000

400000

380000
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time(s)
 What if There are Multiple
Losses in a Window?
With two losses in a window, Reno will
occasionally timeout.

With three losses in a window, Reno will usually

timeout.

With four losses in a window, Reno is guaranteed

to timeout!

With three or more losses in a window, Tahoe

typically out performs Reno!
 TCP Reno Trace
(with two dropped segments)
500000 48

Sent Segment
44
ACK'ed Segment
cwnd
480000 40
ssthresh
cwnd+ndupacks
36

460000 32
Sequence #

28

MSS
440000 24

20

420000 16

12

400000 8

380000 0
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time (s)
 TCP Variation: TCP NewReno

3rd Improvement was TCP NewReno (1995)

Nagles algorithm
Improved RTO calculation and back-off
AIMD congestion avoidance with slow-start
Fast retransmit & modified fast recovery
 Modifications to Fast Recovery

Partial ACKs: An ACK that acknowledges some but not

all the segments that were outstanding at the start of
fast recovery. NewReno interprets this as an indication
of multiple loss.

If partial ACK received, re-transmit the next lost

segment immediately and set ndupacks = 0 (deflate
send_win).

Sender remains in fast recovery until all data

outstanding when fast recovery was initiated is ACKed.
Additional dupACKs increase ndupacks.
 TCP NewReno Trace
(with two dropped segments)
500000 48

Sent Segment
44
ACK'ed Segment
cwnd
480000 40
ssthresh
cwnd+ndupacks
36

460000 32
Sequence #

28

MSS
440000 24

20

420000 16

12

400000 8

380000 0
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time(s)
 Tahoe, Reno & NewReno Trace
(with two dropped segments)
500000

NewReno
Reno
480000 Tahoe
Reno & NewReno
All

460000
Sequence #

440000

420000

400000

380000
4.9 5.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Time (s)
 Is There a Better Way?
The only way Tahoe, Reno and NewReno can
detect congestion is by creating congestion!
They carefully probe for congestion by slowly
increasing their sending rate.
When they find (create), congestion, they cut sending
rate at least in half!
This slow advance and rapid retreat approach
results in a saw-toothed sending rate, and highly
erratic throughput.
What if TCP could detect congestion without
causing congestion?
 TCP Variation: TVP Vegas
(True Congestion Avoidance)

Introduced by Brakmo and Peterson (1994)

Three changes to TCP Reno
Modified congestion avoidance
Dont wait for a timeout, if actual throughput < expected
throughput decrease the congestion window. (AIAD!)
New retransmission mechanism
motivation: what if sender never receives 3-dupACKs (due to
lost segments or window size is too small.)
mechanism: sender does retransmission after a dupACK
received, if RTT estimate > timeout.
Modified slow start
motivation: sender tries finding correct window size without causing
a loss.
 Vegas vs. NewReno

TCP NewReno throughput with simulated background traffic

TCP Vegas throughput with simulated background traffic

Source: Brakmo and Peterson, TCP Vegas: End to End Congestion Avoidance
on a Global Internet, IEEE JSAC, Vol 13, No. 8, Oct. 1995, pp. 1465 1480
 What Variations are being used?

Experimental results obtained by testing

3728 web servers:
NewReno 42%
Tahoe 27% (w/o Fast Retransmit)
Reno 18%
Other 8%
Tahoe 5%

Source: Padhye and Floyd, SIGCOMM 01, August 27-31, San Diego, CA
 Summary of TCP Behavior
TCP Response to Partial
Response to 3 Response to full ACK
Variatio ACK of Fast
dupACKs of Fast Retransmission
n Retransmission
Do fast
Tahoe retransmit, ++cwnd ++cwnd
enter slow start
Do fast
Exit fast recovery, Exit fast recovery, deflate
retransmit,
Reno deflate window, enter window, enter congestion
enter fast
congestion avoidance avoidance
recovery
Do fast Fast retransmit and Exit modified fast
NewRen retransmit, deflate window recovery, deflate window,
When entering slow start, if connection is new, When entering either fast recovery or
o ssthreshenter modified
= arbitrarily remain in modified
large value fastfast recovery,
modified enter congestion
cwnd = fast
1. recovery recovery ssthresh = max(flight avoidance
size/2, 2*MSS)
else, cwnd = ssthresh.
ssthresh = max(flight size/2, 2*MSS) In congestion avoidance
cwnd = 1. cwnd += 1*MSS per RTT
In slow start ++cwnd on new ACK
 TCP without SACK

TCP uses cumulative ACKs

Receiver identifies the last byte of data successfully received
Out of order segments are not ACKed
Receiver sends duplicate ACKs

TCP without SACK forces the TCP sender

Either to wait an RTT to find out a segment was lost
Or, unnecessarily retransmit data that has been correctly received

Can result in reduced overall throughput

34
 TCP with Selective Ack (SACK)

SACK + Selective Repeat Retransmission Policy allows

receiver informs sender about all segments that are successfully received.
sender fast retransmits only the missing data segments
SACK is implemented using two TCP Options
SACK-Permitted Option
SACK Option

35
 SACK Example

receivers buffer

1-100 101-200
sender

receiver

1-100 101-200 401-500 501-600

36
 SACK Rules

With SACKs, the ACK field is still a cum ACK

A SACK cannot be sent unless the SACK-Permitted option has been
received (in the SYN)
The 1st SACK block MUST specify the contiguous block of data containing
the segment which triggered this acknowledgment
If SACKs are sent, SACK option should be included in all ACKs which do
not ACK the highest sequence number in the data receivers queue

37
 Generating SACKs data receiver behavior

If the data receiver has not received a SACK-Permitted Option for a given
connection, the receiver must not send SACK options on that connection
The receiver should send an ACK for every valid segment that arrives
containing new data
The data receiver should include as many distinct SACK blocks as possible
in the SACK option
SACK option should be filled out by repeating the most recently reported
SACK blocks
The data receiver provides the sender with the most up-to-date info about
the state of the network and the receivers queue

38
 Interpreting SACKs - Data Sender behavior

The sender records the SACK for future reference

Maintains a retransmission queue containing unacknowledged segments
One possible implementation
Turns on SACK bit for the segment in retransmission queue when it receives a SACK
Skips SACKed data during any later fast retransmission
On fast retransmit, retransmits data not SACKed so far and less than the highest
SACKed data
Turns off SACK bit after retransmission time out

39
 Another SACK Example

Receiver Buffer
100 299

300 500 699

receiver
sender

300 500 699 900 1099

40
 Another SACK Example (contd)

300 500 699 900 1099

300 500 699 900 1099

receiver
sender

300 500 700 900 1099

1100

41
 Without SACK vs. With SACK

TCP without SACK TCP with SACK

receiver
receiver

sender
sender

fast retransmit fast retransmit

42
 SACK Observations

SACK TCP follows standard TCP congestion control; Adding SACK to TCP
does not change the basic underlying congestion control algorithms
SACK TCP has major advantages when compared TCP Tahoe, Reno,
Vegas and New Reno, as PDUs have been provided with additional
information due to the SACK
Difference in behavior when multiple packets are dropped from one window
of data
SACK information allows the sender to better decide what to retransmit and
what not to

43
Any questions ?
 Data Receiver Reneging

Reneging fail to fulfill a promise or obligation

Data receiver is permitted to discard data in its queue that has not been
acknowledged to the data sender, even if the data has already been SACKed
Such discarding of SACKed segments is discouraged, but may occur if the
receiver must give buffer space back to the OS
If reneging occurs
first SACK should reflect the newest segment even if its going to be discarded
Except for the newest segment, all SACK blocks MUST NOT report any old data
which is no longer actually held by the receiver

45
 Reneging Example

100 199

200 300 399

receiver
200 reneg occurs; window decreases
sender

200 window increases

200 500 599

46
 Consequences of Reneging

Sender must maintain normal TCP timeouts

Data cannot be considered communicated until a cum ACK is sent
Sender must retransmit the data at the left window edge after a retransmit
timeout, even if that data has been SACKed by the receiver
Sender MUST NOT discard data before being acked by the Cum Ack

47
 SACK-Permitted Option

SackPermitted option
is allowed only in a SYN Segment.
indicates sender handles SACKs, and receiver should send SACKs if possible.

SACK option can be used once connection is established TCP Header

Source port address Destination port address

Sequence Number
TCP
header Cumulative Ack No.
length 6 1 Window size
Checksum Urgent pointer
kind=4 length=2 kind=1 kind=1 options
SYN bit
SACK- 48 NOP NOP
permitted
 SACK-Permitted Option and SACK

SENDER RECEIVER

TCP
connection
establishment
phase
Source
Sourceport
portaddress
address Destination
Destinationport
portaddress
address
Source port address
SequenceDestination
Sequence Number port address
Number
Sequence Ack
Cumulative
CumulativeNumber
AckNo.
No.
data
transfer 1Cumulative
11 AckWindow
No.
Window size
size
phase Window size
Checksum
Checksum
1 Urgent
Urgentpointer
pointer
Checksum
kind=4
kind=4 length=2
length=2 Urgent
kind=1 pointer
kind=1 kind=1
kind=1 options
options
SYN bit
ACK bit
SACK-
SACK-
49 kind=1 kind=1
ACK bit NOP
NOP NOP
NOP
 SACK Option

Source port address Destination port address Length of SACK with n blocks?
= (2 + 8 * n) bytes
Sequence
Number Ack No.
Cumulative
HLEN Window size Max number bytes available
for TCP Options?
Checksum Urgent pointer = 40 bytes
Kind=1 Kind=1 Kind=5 Length=??
Left edge of 1st block Max number of SACK blocks
possible?
Right edge of 1st block
= 4 SACK blocks
(barring no other TCP
Options)

Left edge of nth block

Right edge of nth block
50