Transport: TCP

1
Transport TCP

• Manpreet Singh
• (Slides borrowed from various sources on the web)

2
Announcements (1/2)

• Everybody needs to join the class mailing
  list...else I can't communicate class info.
• Check the class archives to see if someone else
  has picked the same lecture or TCP application
• We have a group of machines you can use for
  simulation (snoopy, linus, etc.). 
• You need CSUG accounts to access these machines.
• Well dig up more machines for those who want to
  do kernel hacking.

3
Announcements (2/2)

• Need a volunteer to give the "post-modern" E2E
  lecture 9/9 (in class...). 
• The non-research track students will have to do
  an initial demo by 11/9. 
• Most of the functionality should be there
• Allows us to give feed back
• You time to do performance measurements.

4
Roadmap

• Why is TCP fair ?
• Loss-based congestion schemes
• Tahoe
• Reno
• NewReno
• Sack
• Delay-based congestion control (Vegas)
• Modeling TCP throughput
• Equation-based congestion control

5
The Desired Properties of a Congestion Control
Scheme

• Efficiency (high utilization)
• Optimality (high throughput, utility)
• Fairness (resource sharing)
• Distributedness (no central knowledge for
  scalability)
• Convergence and stability (fast convergence after
  disturbance, low oscillation)

6
TCP Fairness
AIMD

• Fairness goal if N TCP sessions share same
  bottleneck link, each should get 1/N of link
  capacity

• TCP congestion avoidance
• AIMD additive increase, multiplicative decrease
• increase window by 1 per RTT
• decrease window by factor of 2 on loss event

TCP connection 1
bottleneck router capacity R
TCP connection 2
7
Why is TCP fair?

• Two competing sessions
• Additive increase gives slope of 1, as throughout
  increases
• multiplicative decrease decreases throughput
  proportionally

equal bandwidth share
R
loss decrease window by factor of 2
congestion avoidance additive increase
Connection 2 throughput
loss decrease window by factor of 2
congestion avoidance additive increase
Connection 1 throughput
R
8
Loss vs Delay as signal ???
Loss is a binary signal Delay is a multi-bit
signal
TCP
oscillation
9
Simulation-based Comparisons of Tahoe, Reno, and
SACK TCP

• Kevin Fall
• Sally Floyd

10
Introduction

• SACK compared with Tahoe, Reno and New-Reno
• Simulations designed to highlight performance
  differences with and without SACK

11
Comparison

• Tahoe Slow start, congestion avoidance and fast
  retransmit
• Reno Tahoe fast recovery
• New-Reno Reno with modified fast recovery
• SACK Reno selective ACKs

12
TCP Slowstart
Host A
Host B
one segment
RTT
initialize Congwin 1 for (each segment
ACKed) Congwin until (loss event OR
CongWin gt threshold)
two segments
four segments

• exponential increase (per RTT) in window size
  (not so slow!)
• loss event timeout (Tahoe TCP) and/or or three
  duplicate ACKs (Reno TCP)

13
TCP Congestion Avoidance
Congestion avoidance (linear phase)
/ slowstart is over / / Congwin gt
threshold / Until (loss event) every w
segments ACKed Congwin threshold
Congwin/2 Congwin 1 perform slowstart
1
1 TCP Reno skips slowstart (fast recovery)
after three duplicate ACKs
14
Fast Retransmit

• Receiving small number of duplicate ACKs (3)
  signals packet loss
• Lost packet can be retransmitted before timeout
• This improves channel utilization

15
TCP/Reno Congestion Control
Initially cwnd 1 ssthresh infinite
(64K) For each newly ACKed segment if (cwnd lt
ssthresh) / slow start/ cwnd cwnd
1 else / congestion avoidance cwnd
increases (approx.) by 1 per RTT /
cwnd 1/cwnd Triple-duplicate ACKs /
multiplicative decrease / cwnd ssthresh
cwnd/2 Timeout ssthresh cwnd/2 cwnd
1 (if already timed out, double timeout value
this is called exponential backoff)
16
TCP/Reno Big Picture
Tahoe Fast Recovery
cwnd
TD
TD
TD
TO
ssthresh
ssthresh
ssthresh
ssthresh
Time
slow start
congestion avoidance
congestion avoidance
congestion avoidance
slow start
congestion avoidance
TD Triple duplicate acknowledgements TO Timeout
17
Fast Recovery

• Observation Each duplicate ACK indicates some
  packet has left pipe

18
New-Reno extension

• New-Reno continues with fast recovery if a
  partial ACK is received

Old cwnd
Packet 1 lost
Packet 2 lost
LP Last Packet sent before loss detection
Usable window increased by 1 for each duplicate
ACK until ACK for LP is received
New cwnd (old cwnd)/2
19
Why use SACK?

• Without SACK sender has to use one of following
  retransmission strategies
• - Retransmit 1 dropped packet / RTT
• Reno, New-Reno
• - Retransmit packets that might have been
  successfully delivered
• Tahoe

20
SACK option RFC2018

• Ex 2nd segment dropped (each segment has 500
  bytes)

21
SACK Congestion Control (1/2)

• Conservative extensions to Reno
• Fast recovery algorithm modified
• Uses a variable called pipe to estimate
  outstanding data in the flow
• Rules for changing pipe variable
• 1 when packet transmitted
• - 1 when dup ACK received

22
SACK Congestion Control (2/2)

• SACK sender tracks successfully sent packets
  using scoreboard structure
• Missing packets are retransmitted
• Similar to New-Reno in exiting from fast recovery
  exits after all outstanding data at time of
  loss is ACked

23
Simulation Model used

• Three flows are setup from S1 to K1, 2nd and 3rd
  flows are used to change packet drop pattern of
  1st flow

24
One Packet Loss (1/2)
Performs slow start
Packet dropped
Packet retransmitted
25
One Packet Loss (2/2)
Performs fast recovery
Packet dropped
Packet retransmitted
26
Two Packet Loss (1/2)
Performs slow start
Packets dropped
Packets retransmitted
27
Two Packet Loss (2/2)
Performs fast recovery
Packets dropped
Packets retransmitted
28
Three Packet Losses (1/3)
Has to wait for timeout
Packets dropped
Packets retransmitted
29
Three Packet Losses (2/3)
No need for timeout Retransmits 1 pkt/RTT
Packets dropped
Packets retransmitted
30
Three Packet Losses (3/3)
Retransmits more than 1 pkt /RTT
Packets dropped
Packets retransmitted
31
Observations

• Tahoe Robust, performs slow start
• Reno For gt 2 losses, timeout is often needed
• New-Reno Can avoid timeouts, but still cannot
  retransmit gt 1 pkt/RTT
• SACK Can retransmit gt 1 pkt/RTT , thus recovers
  from losses faster

32
Conclusions

• SACK can improve TCP performance
• SACK can be used in high loss links too (Ex
  Wireless)
• New-Reno demonstrates that certain problems of
  Reno can be avoided without SACK

33
Reno vs Vegas (Congestion Avoidance)

• Renos mechanism
• Characteristics
• uses the loss of segments as a signal
• reactive not proactive
• needs to create losses to find the available
  bandwidth
• example

send window
congestion window
Threshold window
34
TCP Vegas

• Idea source watches for some sign that routers
  queue is building up and congestion will happen
  too e.g.,
• RTT grows
• sending rate flattens

Congestion window
Avg. source send rate
Buffer space at router
In shaded region we expect throughput to increase
but it cannot increase beyond available bandwidth
35
Vegas approach

• Basic idea
• Vegas tries not to send at a rate that causes
  buffers to fill
• maintain the right amount of extra data
• based on changes in the estimated amount of extra
  data
• window size vs. throughput
• Keep the actual rate straying too far from the
  available rate (resulting in smooth congestion
  avoidance period)

36
Vegas Algorithm

• define a given connections BaseRTT
• BaseRTT the minimum of all measured RTT
• expected throughput WindowSize / BaseRTT
• Actual rate Flight size / RTT
• Calculate the current Actual sending rate
• Compare Actual (A) to expected (E) and adjusts
  the window (linear increase or decrease)
• If (E-A) gt beta, cwnd - - (congestion state)
• If (E-A) lt alpha, cwnd (low utilization)
• When a loss is detected, reduce the window by a
  half

37
Algorithm (cont)

• Parameters
• a 1 buffer
• b 3 buffers

Black line actual rate Green line expected
rate Shaded region between a and b
Note Linear decrease in Vegas does not violate
AIMD since it Happens before packets loss
38
Comparison of Reno and Vegas (Retransmission)

• Renos retransmission mechanism
• retransmission timeout
• based on RTT and variance estimates
• BSD-based 500ms
• Fast Retransmit and Fast Recovery
• When the sender receives duplicate acks, it
  reduces the window size by a half and avoids
  timeout which causes retransmission with slow
  start
• If multiple drops occur, timeout and slow start
  will follow anyway.
• 19 increase in throughput

39
Vegas Retransmission

• reads and records the system clock each time a
  segment is sent
• when an ACK arrives, Vegas reads the clock again
• RTT calculation using this time and the timestamp
  recorded for the relevant segment
• uses this more accurate RTT estimate to decide to
  retransmit

40
Some fun topics to discuss
41
Modeling TCP throughput

• Consider congestion avoidance only

cwnd
W
TD
bottleneck bandwidth
ssthresh
W/2
Time
congestion avoidance
Assume one packet loss (loss event) per
cycle Total packets send per cycle 3W2/8 Thus p
1/(3W2/8) 8/(3W2) gt
42
Modeling TCP throughput

• 1/throughput c sqrt(p) RTT

43
Equation-based Congestion Control

• Dont need reliability
• But still want to be friendly to the network
• What rate should we send the UDP traffic ?
• Use detailed TCP analysis to relate throughput to
  loss and RTT.
• Measure these values and then calculated
  appropriate throughput directly.
• Result is rate-based and equation-driven protocol
  called TFRC.

44
mulTCP

• Effect of AIMD parameters on the throughput of TCP