comparison between tcpwestwood and explicit control protocol (xcp) jinsong yang shiva navab cs218...
Post on 20-Dec-2015
232 views
TRANSCRIPT
Comparison between TCPWestwood and eXplicit Control Protocol (XCP)
Jinsong YangShiva Navab
CS218 Project - Fall 2003
Outline Traditional TCP shortcomings How TCPW and XCP address those
shortcomings XCP: eXplicit Control Protocol TCPW: TCP Westwood
Simulation Results
Traditional TCP Shortcomings
in High BW*Delay Congestion Detection
Based on receiving ACK (congested or not) No information on degree on congestion
Reaction to Random Loss Throughput inversely proportional to RTT
Unfairness in different RTT Reaching to the full link capacity in high BW
AIMD increase Cwind 1 per RTT Short Flows can cause instability in high BW
Never exit slow start exponential increase
Addressing TCP problemsCongestion Control Mechanism
TCPW Rate Estimate based on ACK rate Modification on the Sender
XCP Based on INFORMATON on each ACK
header Modification on Sender, Receiver and
Router
TCP Westwood Enhance congestion control via Eligible
Rate Estimates (ERE) Estimates are computed at the sender by
sampling and exponential filtering methods
ERE determined from ACK arrival process statistics and info in ACKs regarding amounts of bytes delivered
ERE is used by sender to appropriately set cwnd and ssthresh after packet loss or during slow start
TCPW Algorithm When three duplicate ACKs are detected:
set ssthresh=ERE*RTTmin (instead of ssthresh=cwin/2 as in Reno)
if (cwin > ssthresh) set cwin=ssthresh When a TIMEOUT expires:
set ssthresh=ERE*RTTmin (instead of ssthresh=cwnd/2 as in Reno) and cwin=1
Note: RTTmin = min round trip delay experienced by the connection and is an estimate of the propagation time over the path (roundtrip)
eXplicit Control Protocol (XCP) Senders express their setting (cwnd,
RTT) to routers, and routers express changes required to senders Exchange of information in packet header
Recognizes two types of requirements for Congestion Control: Efficiency: Achieve high link utilization Allocation: Allocate bandwidth according to
desired criteria; e.g. fairness, QoS, etc.
XCP Sender and Receiver
Sender
Receiver Similar to TCP receiver (send back
ACK) But it copies the header of packet to ACK
cwnd
cwndrttrfeedbackH
*
_
),_max( sfeadbackHcwndcwnd
XCP Router Approach: Decouple controls for
efficiency and allocation Control aggregate traffic to achieve
efficient link utilization Divide link bandwidth among
connections to achieve desired criteria
Efficiency Controller Goal: Match aggregate input traffic to link
capacity & drains the queue Algorithm(MIMD):
: Aggregate feedback (increase or decrease) increases with an increase in spare BW decreases with an increase in the router
queue size; i.e.
S: Spare Bandwidth & Q: Queue Size d: Current router’s estimate of RTT
QSd ***
Fairness Controller Goal: Divide among flows to converge
to fairness criteria Algorithm (AIMD): If > 0 ⇒ Divide equally between flows
(regardless of current rate) If < 0 ⇒ Divide between flows in
proportion to their current rates If = 0 ⇒ bandwidth Shuffling
Allocate & deallocate BW such that total traffic range doesn’t change
)*,0max( yh
y= input traffic in avg RTT
Fairness Controller Feedback field: Positive Feedback:
Negative Feedback:
iii npfeedbackH _
i
ipi cwnd
rttp
2
i
ip
cwndrtt
d
h
*
)0,max(
ini rttn *Ld
hn *
)0,max(
Addressing TCP problemsReaction to Error Loss
TCP Reno Halves cwind for each loss (error or overflow)
TCPW: A small fraction of isolated “randomly” lost
packets does not impact the ERE value in TCPW Thus, cwnd = ERE * RTTmin remains unchanged
XCP: Distinguishes Random loss and recovers fast Congestion drop will be preceded with a ACK
(to tell the sender to decrease its cwind)
Addressing TCP problemsReaching to Full Link Capacity TCP Reno
AIMD- increasing 1 per RTT TCPW
Doesn’t reduce cwind drastically catches up fast
XCP Reaches the full capacity in several RTT
based on the information about the spare bandwidth on the received ACK
Pros of XCP Stable for Bandwidth and delay
Uses AQM Parameters independent of environment
Scalable for number of flows No per flow state keeps the state in the
header Almost NO Packet Drop No slow start
Reaches to full capacity fast Smaller queue size comparing to other
queuing schemes
Cons of XCP
Needs router participation deployment might prove to be
difficult Malicious Sender can falsify the
header and mess up the feedback calculation
Issue: Uses average RTT Problem if RTT varies in a large range
Simulation Results-NS2 Topology Bottleneck
single hop Parameters
Bandwidth Delay Loss Rate Number of Flows
Throughput Comparison
Throuput Comparision
0
5
10
15
20
25
0 2 4 6 8 10 12 14
time
Th
rou
gh
pu
t
XCP
TCPW
BW=20MDelay=10msNo Loss
Impact of Capacity
Avg Throughput
0
20
40
60
80
100
120
1 5 10 20 50 75 100
BW(Mbps)
Avg
Th
rou
gh
pu
t(M
bp
s)
TCPW
XCP
Single FlowDifferent BWDelay= 10ms
Impact of Link Delay
Throughput ComparisonDifferent Delay
0
5
10
15
20
25
0 200 400 600 800 1000
Delay (ms)
Th
rou
gh
tpu
t (M
bs)
TCPW-Avg-Thrp
XCP-Avg_Thrp Different DelayBW= 20MbpsNo Loss
Different Loss Rate
Avg Thoughput Loss Rate= 0.1%
0
5
10
15
20
25
0 2 4 6 8 10 12 14 16
Time(sec)
Th
rou
gh
pu
t (M
bp
s)
XCP
TCPW
Avg Throughput Loss rate= 0.5%
0
5
10
15
20
25
0 2 4 6 8 10 12 14 16
Time (sec)T
hro
ug
hp
ut
(Mb
ps
)
TCPW
XCP
BW=20 MbpsDelay= 10ms
Impact of Loss RateThroughput Comparison
Different Loss Rate
0
5
10
15
20
25
0 0.05 0.1 0.15 0.2 0.25
Loss Rate
Th
rou
gh
pu
t (M
bp
s)
TCPW-Avg-Thrpt
XCP-Avg-Thrp
Diff. Loss RateBW= 20MbpsDelay= 10ms
Impact of Number of Flows
0
2
4
6
8
10
12
1 2 5 10 20 50 100 200 500
Number of Flows
Th
rou
gh
pu
t (M
bp
s)
XCPREDDropTail
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
1 2 5 10 20 50 100 200 500
Number of Flows
Pac
ket D
rop
(Pac
ket)
XCPREDDropTail
BW=10 MbpsDelay=20ms
Impact of Web-Like Traffics
0
0.5
1
1.5
2
2.5
3
3.5
0.1 5.1 10.1 15.1 20.1 25.1
Time (sec)
Th
rou
gh
pu
t (M
bp
s)
XCP
RED
DropTail
0
10
20
30
40
50
60
70
0.1 5.1 10.1 15.1 20.1 25.1
Time (se)
Pa
ck
et
Dro
p (
Pa
ck
et) XCP
RED
DropTail
BW 10 Mb, # of Short Flows 500, Start @ Random Time, Running for 1 sec ,Link Delay 45 ms
500/30=17 10M/18=0.55M XCP not friendly
Fairness Study – No Loss
0
20
40
60
80
100
120
0.1 0.6 1.1 1.6 2.1 2.6
Time
Th
rou
gh
pu
t
Flow 0Flow 1Flow 2
0
20
40
60
80
100
120
0.1 0.6 1.1 1.6 2.1 2.6
Time
Th
rou
gh
pu
t
Flow 0
Flow 1
Flow 2
TCPW XCP
BW=100 MbpsDelay=20 ms
Fairness Study – Different Delay
0
5
10
15
20
25
0.1 5.1 10.1 15.1 20.1 25.1Time (sec)
Th
rou
gh
pu
t (M
bp
s)
Flow 0
Flow 1
Flow 2
BW=20 Mbpsd1=10, d2=50, d3=100ms
0
5
10
15
20
25
0.1 5.1 10.1 15.1 20.1 25.1
Time (sec)
Th
rou
gh
pu
t
Flow 0
Flow 1
Flow 2
TCPW XCP
References [1] Katabi, D., M. Handley, C. Rohrs. Internet Congestion Control for
Future High Bandwidth-Delay Product [2] M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, S. Mascolo,
"TCP Westwood: Congestion Window Control Using Bandwidth Estimation", In Proceedings of IEEE Globecom 2001, Volume: 3, pp 1698-1702, San Antonio, Texas, USA, November 25-29, 2001
[3]Mascolo, S., C. Casetti, M. Geral, M. Y. Sanadidi, R. Wang. TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links
[4] Ren Wang, Massimo Valla, M. Y. Sanadidi, and Mario Gerla, Adaptive Bandwidth Share Estimation in TCP Westwood, In Proc. IEEE Globecom 2002, Taipei, Taiwan, R.O.C., November 17-21, 2002
[5]Claudio Casetti, Mario Gerla, Saverio Mascolo, M.Y. Sansadidi, and Ren Wang, TCP Westwood: End-to-End Congestion Control for Wired/Wireless Networks, In Wireless Networks Journal 8, 467-479, 2002
More TCP Westwood papers on http://www.cs.ucla.edu/NRL/hpi/tcpw/ [6] Network simulator ns-2. http://www.isi.edu/nsnam/ns [7] Sally Floyd, HighSpeed TCP for Large Congestion Windows Internet draft
draft-ietf-tsvwg-highspeed-01.txt, work in progress, August 2003. [8] Red parameters http://www.icir.org/floyd/red.html#parametes