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