1 performance evaluation and comparison of westwood+, new reno and vegas tcp congestion control...

1

Performance Evaluation Performance Evaluation and Comparison and Comparison of of Westwood+Westwood+, New Reno and Vegas TCP, New Reno and Vegas TCP

Congestion ControlCongestion Control

Saverio MascoloSaverio Mascolomascolomascolo@@polibapoliba.it.it

http://www-http://www-ictservictserv..polibapoliba.it/.it/mascolomascolo//Dipartimento di Elettrotecnica ed ElettronicaDipartimento di Elettrotecnica ed Elettronica

Politecnico di BariPolitecnico di BariVia Orabona 4, 70125 Bari, ItalyVia Orabona 4, 70125 Bari, Italy

Gotland August 25, 2004

mailto:[email protected]




http://www-ictserv.poliba.it/mascolo/







2 Saverio Mascolo – WIP/Beats 04, Visby, Gotland

OutlineOutline Brief dBrief description of Westwood+ TCPescription of Westwood+ TCP, ,

New Reno and Vegas TCPNew Reno and Vegas TCP Performance evaluation of Westwood+, Performance evaluation of Westwood+,

New Reno and Vegas TCP using ns-2New Reno and Vegas TCP using ns-2 Internet measurementInternet measurementss using using an an

implementation of Westwood+ in implementation of Westwood+ in LinuxLinux 2.4 (Westwood+ is now in the official 2.4 (Westwood+ is now in the official kernel of Linux 2.6 at www.kernel.org)kernel of Linux 2.6 at www.kernel.org)

For more details see: ACM Computer For more details see: ACM Computer Communication Review, April 2004, Communication Review, April 2004, and ICC04 and ICC04


WESTWOODWESTWOOD++ TCP TCP

key idea of Westwood+: to use the stream of ack packets to get

an e2e estimate of the available bandwidth to be used for setting cwnd and ssthresh after congestion (whereas standard TCP implements a “blind” by half window decrease)


TCP WestwoodTCP Westwood++

Congestion Avoidance

Slow start

cwnd

time

Timeoutssthresh

BWE*RTTmin

Adaptive decrease cwnd=ssthr=BWE*RTTmin

Westwood Adaptive decrease vs (New) Reno blind by ½ window shrinking


Rate HalvingRate Halving

Another feature of the Linux implementation of Westwood+ TCP is the rate-halving mechanism (taken from New Reno): after congestion the cwnd is reduced

by one every two ack packets up to the value BWE*RTTmin

E2E bandwidth estimationE2E bandwidth estimation

The rate of returning ACKS is exploited to The rate of returning ACKS is exploited to estimate the “best-effort” available bandwidthestimate the “best-effort” available bandwidth

ACKs

packets

Filter

RECEIVERSENDER

Bandwidthestimate

ACKs

packets

Network


An anti-aliasing filter in An anti-aliasing filter in packet networkspacket networks

j

jj

db

RTT Lastj

RTTlast in the edacknowledg dataalld j

Antialiased samples


ACK compression effectsACK compression effects

ACK pairs give information about the ACK pairs give information about the bandwidth of the last link traversed bandwidth of the last link traversed on the backward pathon the backward path

To smooth ACK compression we To smooth ACK compression we accumulate ACKs over an RTT and accumulate ACKs over an RTT and then compute a bandwidth samplethen compute a bandwidth sample


We are currently using the standard We are currently using the standard exponential filter exponential filter

kkk bbb )1(ˆˆ1

kRTTkd

kb


Summary on bandwidth Summary on bandwidth estimateestimate

Westwood TCP: one bandwidth Westwood TCP: one bandwidth sample computed for each ACK sample computed for each ACK (Mobicom 01)=>> Bandwdith (Mobicom 01)=>> Bandwdith overestiamte (when ACK overestiamte (when ACK compression)compression)

Westwood+ TCP: one bandwidth Westwood+ TCP: one bandwidth sample for each RTT (see sample for each RTT (see ACM CCR, ACM CCR, April 04April 04))

AdvantagesAdvantages of of Westwood+ TCPWestwood+ TCP

higherhigher throughput over wireless throughput over wireless linkslinks because losses due to because losses due to unreliable links unreliable links do not provokedo not provoke overshrinking of the congestion overshrinking of the congestion windowwindow

Improved fairness wrt to Improved fairness wrt to RenoReno (Reno(Reno throughput is proportional to 1/RTTthroughput is proportional to 1/RTT whreas Westwood throughput whreas Westwood throughput is is proportional to 1/sqrt(RTT) )proportional to 1/sqrt(RTT) )


New Reno TCPNew Reno TCP

New Reno is an improved version of Reno New Reno is an improved version of Reno that avoids multiple reductions of the that avoids multiple reductions of the cwndcwnd when several segments from the when several segments from the same window of data get lost same window of data get lost RFC 3782, RFC 3782, S. Floyd, T. Henderson, A. GurtovS. Floyd, T. Henderson, A. Gurtov, ,

““The NewReno Modification to TCP's Fast The NewReno Modification to TCP's Fast Recovery AlgorithmRecovery Algorithm””

New RenoNew Reno is the leading Internet is the leading Internet congestion control protocol congestion control protocol


Vegas TCPVegas TCP Vegas TCP was the first attempt to depart from the Vegas TCP was the first attempt to depart from the

loss-driven paradigm of the TCP by introducing a loss-driven paradigm of the TCP by introducing a mechanism of congestion detection before packet mechanism of congestion detection before packet losseslosses:: Vegas TCP computes the difference Vegas TCP computes the difference between the between the actual actual

input rateinput rate ( (cwndcwnd//RTTRTT) and the ) and the expected rateexpected rate ( (cwndcwnd//RTTRTTminmin), ),

to infer network congestion. to infer network congestion. IIf f is smaller than a threshold is smaller than a threshold αα then the then the cwndcwnd is additively increased, whereas if the is additively increased, whereas if the difference is greater than another threshold difference is greater than another threshold ββ then the then the cwndcwnd is Additively Decreased; finally, if is Additively Decreased; finally, if αα << < <ββ then the then the cwndcwnd is kept constant. is kept constant. ItIt has been shown that Vegas TCP has been shown that Vegas TCP ensures network stability but it is not able to grab its own ensures network stability but it is not able to grab its own bandwidth share when interacting with algorithms that bandwidth share when interacting with algorithms that systematically hits network queue capacity systematically hits network queue capacity such as such as Reno. Reno.


TCP Vegas TCP Vegas has been considered becausehas been considered because:: AnalogouslyAnalogously to to Westwood+, Westwood+, it it is based on is based on mechanism mechanism

for throttling the congestion window based on RTT for throttling the congestion window based on RTT measurements.measurements.

Vegas TCP Vegas TCP isis behind the new Fast TCP behind the new Fast TCP ((by by researchers at Caltech researchers at Caltech )). In authors’ words, “Fast . In authors’ words, “Fast TCP is a sort of high-speed version of Vegas”.TCP is a sort of high-speed version of Vegas”.

Fast TCP Fast TCP isis still still in a trial phase and in a trial phase and nono kernel code kernel code or or ns-2ns-2 implementation implementation available at time of this work available at time of this work Being based on Being based on RTTRTT measurements to infer congestion, measurements to infer congestion, Fast TCP Fast TCP could could

inherit all drawbacks of Vegas that will be illustrated inherit all drawbacks of Vegas that will be illustrated (( incapacity to grab incapacity to grab bandwidth when coexisting with Reno traffic or in the presence of bandwidth when coexisting with Reno traffic or in the presence of reverse trafficreverse traffic))


Following our suggestions, Les Following our suggestions, Les Cotrell at Stanford Linear Cotrell at Stanford Linear Accelerator CenterAccelerator Center found that Fast found that Fast TCP is, in his words “very TCP is, in his words “very handicapped in the presence of handicapped in the presence of reverse traffic” (fall 2003) reverse traffic” (fall 2003)


Performamce evaluationPerformamce evaluation

Bandwidth estimateBandwidth estimate


Topology with ACK compression effects Topology with ACK compression effects (10 Mbps)(10 Mbps)

10 TCP

R R

Sink

10 TCPSinks

10 TCPConnections

Reverse traffic:

20 TCP connections

Forward traffic: West TCP

connection


The 20 Westwood+ connections estimate a best-effort available bandwidth that

reasonably approaches the fair share of 0.5Mbps

1.0E+01

1.0E+02

1.0E+03

1.0E+04

1.0E+05

1.0E+06

1.0E+07

1.0E+08

1.0E+09

0 20 40 60 80 100

s

Ban

dwid

th e

stim

ate

(bps

)

Fair share


Westwood overestimates up to 100 times Westwood overestimates up to 100 times the fair share due to ACK compression the fair share due to ACK compression

1.0E+01

1.0E+02

1.0E+03

1.0E+04

1.0E+05

1.0E+06

1.0E+07

1.0E+08

1.0E+09

0 20 40 60 80 100

s

Ban

dwid

th e

stim

ate

(bps

)

Fair share


RemarkRemark WestwoodWestwood estimate is different from measuring the estimate is different from measuring the

low frequency components of the sending rate low frequency components of the sending rate cwndcwnd//RTTRTT ( (cwndcwnd//RTT RTT is the measure of the is the measure of the instantaneous throughput employed by Vegas TCPinstantaneous throughput employed by Vegas TCP))

In fact, the Vegas actual rate In fact, the Vegas actual rate cwndcwnd//RTT RTT is a is a measure of the available bandwidth that is based on measure of the available bandwidth that is based on the number of sent packets (the number of sent packets (cwndcwnd) and not on the ) and not on the number of acknowledged packets number of acknowledged packets ddkk. As a . As a

consequence, Vegas samples do not take into consequence, Vegas samples do not take into account that a fraction of sent packets could be lost account that a fraction of sent packets could be lost thus leading to available bandwidth overestimate. thus leading to available bandwidth overestimate.


1 Mbps1 Mbps

7.0E+05

8.0E+05

9.0E+05

1.0E+06

1.1E+06

1.2E+06

0 20 40 60 80 100s

bps

BWEInput RateBottleneck Capacity


Formula of Steady State Formula of Steady State ThroughputThroughput

p

)p(

RTTT

121Reno

p

p

qTRTTT

11West


Single connection + Single connection + 10 TCP connections 10 TCP connections on the backward path on the backward path following following an OFF-an OFF-

ON-OFF-ON pattern toON-OFF-ON pattern to i investigate the nvestigate the effect of reverse trafficeffect of reverse traffic

TCP1

source

10 TCPsources

Forward Traffic

Reverse Traffic

TCP1

Sink

10 TCP Sinks


cwnd and ssthresh cwnd and ssthresh dynamicsdynamics

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000s

Seg

men

ts

cwndssthresh

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000s

Seg

men

ts

cwndssthresh

NewReno

Westwood+

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000s

Seg

men

ts

cwndssthresh

Vegas

0

20

40

60

80

100

120

0 100 200 300 400 500 600 700 800 900 1000s

Seg

men

ts

cwndssthresh

Reno


Visual look at fairness 20 Visual look at fairness 20 connectionsconnections

0

10000

20000

30000

40000

50000

60000

70000

0 200 400 600 800 1000

s

Sequ

ence

Num

ber

s (S

egm

ents

)

NewReno

0

10000

20000

30000

40000

50000

60000

70000

0 200 400 600 800 1000

s

Sequ

ence

Num

ber

s (S

egm

ents

)

Westwood +

0

10000

20000

30000

40000

50000

60000

70000

0 200 400 600 800 1000

s

Sequ

ence

Num

ber

s (S

egm

ents

)

Vegas


Wireless tWireless terrestrial errestrial scenarioscenario

one way delay one way delay of TCP1 of TCP1 ==125ms125ms;; 20ms delay on the wireless link20ms delay on the wireless link ( (2Mbps2Mbps))

5 TCP sources

10 TCP sources

Cross Traffic

Reverse Traffic

5 TCP Sinks

10 TCP Sinks

TCP1

source

Wireless link

TCP1 sink


RTTRTTs 5 cross traffic connections and 10 New Reno s 5 cross traffic connections and 10 New Reno backward traffic connections are uniformly spread in the backward traffic connections are uniformly spread in the intervals [66ms,250ms] and [46ms,250ms], respectively. intervals [66ms,250ms] and [46ms,250ms], respectively.

wireless link affected by bursty segment losses in both wireless link affected by bursty segment losses in both directionsdirections

A A Gilbert two state Markov chain modelGilbert two state Markov chain modelss the loss the loss processprocess loss probability loss probability pp equal to 0, when channel in the equal to 0, when channel in the GoodGood statestate, , pp ==0.1 when the channel is in the 0.1 when the channel is in the BadBad statestate. . permanence time in the permanence time in the GoodGood statestate deterministic and equal to 1s deterministic and equal to 1s permanence time in the permanence time in the Bad stateBad state also deterministic ranging also deterministic ranging

from 0.1ms to 100 ms. from 0.1ms to 100 ms. When the permanence time in a state elapses, the state can When the permanence time in a state elapses, the state can

transit to a transit to a GoodGood or or BadBad state with a probability state with a probability pp=0.5. =0.5.


Single connectionSingle connection

For each considered case, we run 10 simulations For each considered case, we run 10 simulations by varying the seed of the random loss process. For by varying the seed of the random loss process. For each value of the BAD state duration we report the each value of the BAD state duration we report the maximum, minimum and average goodputs.maximum, minimum and average goodputs.

In order to analyze only the impact of bursty losses In order to analyze only the impact of bursty losses on the TCP behavior, we have first turned off both on the TCP behavior, we have first turned off both the cross and reverse traffic sources. This simple the cross and reverse traffic sources. This simple scenario is particularly useful to investigate the scenario is particularly useful to investigate the effectiveness of the adaptive decrease paradigm effectiveness of the adaptive decrease paradigm when losses not due to congestion are experienced when losses not due to congestion are experienced by the TCP. by the TCP.


Goodput of TCP1 connection without reverse Goodput of TCP1 connection without reverse

traffic: DACK enabledtraffic: DACK enabled

0 .0E+00

2 .0E+05

4 .0E+05

6 .0E+05

8 .0E+05

1 .0E+06

1 .2E+06

1 .4E+06

1 .6E+06

1 .8E+06

2 .0E+06

0 .00 01 0.0 01 0.01 0 .1D uration of the BAD sta te (s)

Go

odpu

t (b

ps)

W estwood+, DA CK enabled

New Reno, DACK ena bled


Goodput of TCP1Goodput of TCP1, no , no reverse traffic: DACK reverse traffic: DACK disdisabledabled

0 .0E+00

2 .0E+05

4 .0E+05

6 .0E+05

8 .0E+05

1 .0E+06

1 .2E+06

1 .4E+06

1 .6E+06

1 .8E+06

2 .0E+06

0 .00 01 0.0 01 0.01 0 .1D uration of the BAD sta te (s)

Go

odpu

t (b

ps)

W estwood+, DA CK disabled

New Reno, DACK disabled

SACK


CwndCwnd and and ssthreshssthresh + + (( duration of the BAD 0.01s duration of the BAD 0.01s))

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000s

Seg

men

ts

cwndssthresh

Westwood+

0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800 900 1000s

Seg

men

ts

cwndssthresh

New Reno


reverse + cross trafficreverse + cross traffic One further point valuable of investigation is One further point valuable of investigation is

when Westwood+ shares the wired portion of when Westwood+ shares the wired portion of the network with several TCP flows on the the network with several TCP flows on the forward and backward paths.forward and backward paths.

For that purpose, we turn on the cross and For that purpose, we turn on the cross and reverse traffic and we measure the goodput reverse traffic and we measure the goodput of the TCP1 connections for various values of of the TCP1 connections for various values of the BAD state duration. the BAD state duration.


1 00000

2 00000

3 00000

4 00000

5 00000

6 00000

7 00000

8 00000

9 00000

0.0001 0.001 0.01 0 .1Du ration of the BAD state (s)

Go

odp

ut (

bps

)

W estw ood+, DA CK disabled

New Reno, DACK disa bled

SACK

W estw ood+, DA CK ena bled

New Reno, DA CK enabled


RemarksRemarks TThe delayed ACK option plays a major role in this he delayed ACK option plays a major role in this

scenario. In fact, protocols that do not employ the scenario. In fact, protocols that do not employ the delayed ACK option provides goodputs that are roughly delayed ACK option provides goodputs that are roughly two times larger than those obtained when the delayed two times larger than those obtained when the delayed ACK option is enabled. The reason is that the delayed ACK option is enabled. The reason is that the delayed ACK option slows down the TCP probing phase. ACK option slows down the TCP probing phase.

In these scenarios Westwood+ TCP (DACK disabled) In these scenarios Westwood+ TCP (DACK disabled) still improves the goodput with respect to New Reno still improves the goodput with respect to New Reno (DACK disabled) and SACK TCP, but the improvement (DACK disabled) and SACK TCP, but the improvement is now only up to roughly 20%is now only up to roughly 20% since since in this case the in this case the TCP1 connection loses bandwidth in favor of the cross TCP1 connection loses bandwidth in favor of the cross traffic that, being wired, is not penalized by losses not traffic that, being wired, is not penalized by losses not due to congestion.due to congestion.


SaSatellite scenariotellite scenario

20 TCP senders

20 TCP sinks

10 TCP sinks

10 TCP senders

•20 TCP forward connections in the presence of reverse traffic contributed by 10 long-lived New Reno connections.

•large leaky pipe: 10Mbps bottleneck link with one-way delay equal to 275ms

•RTTs of the forward connections are equal to 590ms.


0

10 00000

20 00000

30 00000

40 00000

50 00000

60 00000

70 00000

80 00000

90 00000

100 00000

0.0001 0.001 0.01 0.1 1

Du ration of the BAD state (s)

Tot

al G

ood

put (

bps

)

Westwood+, DACK disa bled

W estw ood+, DA CK enabled

SACK

New Reno, DACK disabled

Ne w Reno , DA CK enabled

Linux 2.4.19Linux 2.4.19implementation of implementation of Westwood+ TCPWestwood+ TCP

More than 4000 FTP froma Bari, More than 4000 FTP froma Bari, South Italy to:South Italy to: ssignserv.signal.uu.seignserv.signal.uu.se (Uppsala) (Uppsala) panther.cs.ucla.edupanther.cs.ucla.edu (UCLA) (UCLA) main.penguin.itmain.penguin.it (Parma) (Parma)


Average goodput during Average goodput during ftpftp to Los Angelesto Los Angeles

0 5

10 15 20 25 30 35 40 45 50

21 Feb 2003 32MB

26 Feb 2003 3.2MB

28 Feb 2003 3.2 MB

14 Mar 2003 32MB

19 Mar 2003 32 MB

21 Mar 2003 32 MB

Ave

rage

Goo

dput

(K

Byt

es/s

) New Reno Westwood+


Retransmission ratio Retransmission ratio during during ftpftp to UCLA to UCLA

0

2

4

6

8

10

12

21 Feb 2003 32MB

26 Feb 2003 3.2MB

28 Feb 2003 3.2MB

14 Mar 2003 32MB

19 Mar 2003 32MB

21 Mar 2003 32MB

Ret

rans

mis

sion

rat

io (

%)

New Reno Westwood+


Average goodput during Average goodput during ftpftp to Uppsalato Uppsala

0

50

100

150

200

250

14 Dec 2002

32 MB 17 Dec

2002 3.2MB

10 Jan 2003

3.2MB 12 Jan

2003 3.2MB

13 Jan 2003

32MB 17 Jan

2003 3.2MB

3 Feb 2003

32MB

7 Feb 2003

32MB

New Reno Westwood+

Ave

rag

e G

ood

pu

ts (

Kb

ytes/

s)


Retransmission ratio Retransmission ratio during during ftpftp to Uppsala to Uppsala

0 0.5

1 1.5

2 2.5

3 3.5

4 4.5

17 Dec 2002

3.2MB 10 Jan

2003 3.2MB

12 Jan 2003

3.2 MB 13 Jan

2003 32MB

17 Jan 2003

3.2MB 3 Feb 1003

32MB 7 Feb 2003

32MB

New Reno Westwood+

Ret

rans

mis

sion

rat

io (

%)


Average goodput during Average goodput during ftpftp to Parmato Parma

0 20 40 60 80

100 120 140 160

26 Mar 2003

32MB 27 Mar

2003 3.2MB

28 Mar 2003

3.2MB 4 Apr 2003

32MB 7 Apr 2003

3.2MB 9 Apr 2003

3.2MB 11 Apr

2003 3.2MB

New Reno Westwood+

Ave

rag

e G

ood

pu

ts (

Kb

ytes/

s)


Retransmission ratio Retransmission ratio during during ftpftp to Parma to Parma

0 2 4 6 8

10 12 14

26 Mar 2003

32MB 27 Mar

2003 3.2MB

28 Mar 2003

3.2MB 4 Apr 2003

32MB 7 Apr 2003

3.2MB 9 Apr 2003

3.2MB 11 Apr

2003 3.2MB

New Reno Westwood+

Retr

an

smis

sion

rati

o (

%)

Uploads to Uploads to panther.cs.ucla.edu panther.cs.ucla.edu (1)(1)

File size=3.2MB, From: rigel.poliba.it, To: panther.cs.ucla.edu, Total number of uploads = 197, Average New Reno Goodput = 16.86Kbyte/s,

Average Westwood+ Goodput = 25.21Kbyte/s

0

10

20

30

40

50

60

Wed Feb26

13:35:162003

Wed Feb26

19:38:032003

Wed Feb26

22:53:272003

Thu Feb 2701:41:26

2003

Thu Feb 2704:10:01

2003

Thu Feb 2706:11:28

2003

Thu Feb 2708:23:06

2003

Date

Go

odp

ut (K

B/s

)

Westwood+New Reno


File size=32MB

0

10

20

30

40

50

60

70

80

Fri Feb 2118:15:56

2003

Sat Feb 2206:04:31

2003

Sat Feb 2220:26:44

2003

Sun Feb 2307:24:58

2003

Sun Feb 2319:06:51

2003

Mon Feb 2403:52:51

2003Date

Goo

dput

(KB

/s)

Westwood+New Reno


File size=32MB

0

10

20

30

40

50

60

Fri Mar 1418:59:15

2003

Sat Mar 1506:09:27

2003

Sat Mar 1513:29:48

2003

Sat Mar 1522:20:43

2003

Sun Mar 1609:57:01

2003

Mon Mar 1702:47:05

2003Date

Goo

dput

(K

B/s

)

Westwood+New Reno


File size=32MB

0

10

20

30

40

50

60

70

Wed Mar19

14:15:252003

Wed Mar19

22:55:382003

Thu Mar20

02:47:102003

Thu Mar20

06:08:362003

Thu Mar20

10:45:342003

Thu Mar20

19:52:362003

Fri Mar21

01:07:102003

Fri Mar21

05:29:192003

Date

Go

odp

ut

(KB

/s)

Westwood+New Reno


Further Further researchresearch

Realistic Characterization of Realistic Characterization of wireless linkswireless links still needed in ns-2! still needed in ns-2!

Can we expect the same result with Can we expect the same result with Westwood+ over the gigabit Westwood+ over the gigabit Internet? Internet? (tests are going at SLAC (tests are going at SLAC and CERN)and CERN)


Thanks for the attentionThanks for the attention and and Questions?Questions?

1 performance evaluation and comparison of westwood+, new reno and vegas tcp congestion control...

Documents

ack compression westwood

saverio mascolo wipbeats

bandwidth sample slide

comparison of westwood

standard tcp

rttmin slide

ack mobicom

gotland rate