tcp westwood (with faster recovery) claudio casetti ([email protected]) mario gerla...
Post on 21-Dec-2015
220 views
TRANSCRIPT
TCP Westwood (with Faster Recovery)
Claudio Casetti ([email protected])
Mario Gerla ([email protected])
Scott Seongwook Lee ([email protected])
Saverio Mascolo ([email protected])
Medy Sanadidi ([email protected])
Computer Science Department
University of California, Los Angeles, USA
TCP Congestion Control • Based on a sliding window algorithm• Two stages:
– Slow Start, initial probing for available bandwidth (“exponential” window increase until a threshold is reached)
– Congestion Avoidance,”linear” window increase by one segment per RTT
• Upon loss detection (coarse timeout expiration or duplicate ACK) the window is reduced to 1 segment (TCP Tahoe)
Congestion Window of a TCP Connection Over Time
Shortcomings of current TCP congestion control
• After a sporadic loss, the connection needs several RTTs to be restored to full capacity
• It is not possible to distinguish between packet loss caused by congestion (for which a window reduction is in order) and a packet loss caused by wireless interference
• The window size selected after a loss may NOT reflect the actual bandwidth available to the connection at the bottleneck
New Proposal:TCP with “Faster Recovery”
• Estimation of available bandwidth (BWE):– performed by the source– computed from the arrival rate of ACKs,
smoothed through exponential averaging
• Use BWE to set the congestion window and the Slow Start threshold
TCP FR: Algorithm Outline
• When three duplicate ACKs are detected:– set ssthresh=BWE*rtt (instead of ssthresh=cwin/2 as in Reno)
– if (cwin > ssthresh) set cwin=ssthresh
• When a TIMEOUT expires:– set ssthresh=BWE*rtt (instead of ssthresh=cwnd/2 as in Reno) and cwin=1
Experimental Results
• Compare behavior of TCP Faster Recovery with Reno and Sack
• Compare goodputs of TCP with Faster Recovery, TCP Reno and TCP Sack– with bursty traffic (e.g., UDP traffic)– over lossy links
FR/Reno Comparison
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0 100 200 300 400 500 600 700 800
no
rma
lize
d t
hro
ug
hp
ut
Time (sec)
1 TCP + 1 On/Off UDP (ON=OFF=100s) 5 MB buffer - 1.2s RTT - 150 Mb/s Cap.
FR
Reno
Goodput in presence of UDPDifferent Bottleneck Sizes
0
1
2
3
4
5
6
0 20 40 60 80 100 120 140 160
Goo
dput
[M
b/s]
Bottleneck bandwidth [Mb/s]
FR
RenoSack
Wireless and Satellite Networks
0
200000
400000
600000
800000
1e+06
1.2e+06
1.4e+06
1e-10 1e-09 1e-08 1e-07 1e-06 1e-05 0.0001 0.001
good
put
(bits
/s)
bit error rate (logscale)
TahoeRenoFR
link capacity = 1.5 Mb/s - single “one-hop” connection
Experiment Environment
Router
Source
Linkem ulator
D estination
Source
100M
100M
• New version of TCP FR called “TCP Westwood”•TCP Westwood is implemented in Linux kernel 2.2.10.• Link emulator can emulate:
• link delay• loss event
• Sources share bottleneck through router to destination.
Goodput Comparison with Reno (Sack)
goodput vs. pipesize
0
1
2
3
0.02 0.27 0.52 1.02 2.52 5.02
pipesize(Mb)
good
put(M
b/Se
c)
Westwood
Reno withSack
• Bottleneck capacity 5Mb• Packet loss rate 0.01• Larger pipe size
corresponds to longer delay
goodput vs. loss rate
0
0.5
1
0 0 0 0 0
Packet Loss Rate
good
put
(Mb/
Sec) Westwood
Reno withSack
• Link delay 300ms• Bottleneck bandwidth 5Mb• Concurrent on-off UDP
traffic
Friendliness with Reno
• Goodput comparison when TCP-W and Reno share the same bottleneck– over perfect link– 5 Reno start first– 5 west start after 5 seconds– 100 ms link delay
• Goodput comparison when TCP-W and Reno share the same bottleneck– over lossy link(1%)– 3 Reno start first then 2 Westwood– 100 ms link delay
• TCP-W improves the performance over lossy link but does not catch the link.
Current Status & Open Issues
• Extended testing of TCP WEswoh
• Friendliness/greediness towards other TCP schemes
• Refinements of bandwidth estimation process
• Behavior with short-lived flows, and with large number of flows
Extra slides follow
Losses Caused by UDPDifferent RTT
0.8
1
1.2
1.4
1.6
1.8
2
2.2
2.4
2.6
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Goo
dput
[M
b/s]
one-way RTT (s)
FR
RenoSack
Losses Caused by UDPDiffererent Number of Connections
0
1
2
3
4
5
6
7
8
9
10
11
0 5 10 15 20 25 30
Goo
dput
[M
b/s]
no. of connections
FR1
RenoSack
TCP over Lossy linksDifferent Bottleneck Size
0.1
1
10
0 20 40 60 80 100 120 140 160
Goo
dpu
t [M
b/s]
Bottleneck bandwidth [Mb/s]
FR
RenoSack
Bursty trafficdiffererent number of connections
0
2
4
6
8
10
12
14
0 5 10 15 20 25 30
Goo
dpu
t [M
b/s]
no. of connections
FRRenoSack
Fairness of TCP Westwood
• Cwnds of two TCP Westwood connections– over lossy link– concurrent UDP traffic– timeshifted– link delay 100ms
• Concurrent TCP-W connections goodput– 5 connections (other2 are
similar)– link delay 100ms.