linux 2.4 implementation of westwood+ tcp with rate-halving ...in the internet [14]. to test and...

Linux 2.4 Implementation of Westwood+ TCP

with rate-halving: A Performance Evaluation

over the Internet ∗

A. Dell’Aera, L. A. Grieco, S. Mascolo

Dipartimento di Elettrotecnica ed Elettronica

Politecnico di Bari

Via Orabona, 4 – 70125 BARI, Italy

{a.dellaera;a.grieco;mascolo}@poliba.it

Tech. Rep. N. 08/03/S

Abstract: The additive increase/multiplicative decrease probing paradigm is

at the core of TCP congestion control and allows TCP flows to regulate the

transmission rate in order to match the network capacity. To improve classic

Reno/New Reno congestion control algorithms, the recent Westwood+ TCP pro-

poses to substitute the multiplicative decrease phase with an adaptive decrease

phase: in particular, Westwood+ TCP passes through a filter the stream of re-

turning ACKs to obtain an estimate of the used bandwidth (BWE), so that when

a congestion episode happens, Westwood+ adaptively reduces the congestion win-

dow and the slow-start threshold to the value BWE times the minimum round

trip time.

This paper aims at evaluating the performance of Westwood+ TCP over the real

Internet. To this purpose, a Linux 2.4.19 implementation of Westwood+ TCP

has been developed and compared with an implementation of New Reno. To test

and compare the two implementations more than 4000 files, with different sizes,

have been uploaded via ftp from a host at the Politecnico of Bari (South of Italy)

to three remote servers, which are located at Parma (North of Italy), Uppsala

University (Sweden) and University of California Los Angeles (Ucla, California).

Experimental results indicate that Westwood+ TCP improves the goodput with

respect to New Reno TCP over paths with a bandwidth delay product larger

than few segments. In particular, goopdput improvements up to 40-50% have

been measured when transmitting data from Politecnico of Bari to Uppsala or

UCLA servers.

∗This work has been partially supported by the FIRB Research Project ”Traffic modelsand Algorithms for Next Generation IP networks Optimization (TANGO)”

1

1 Introduction

The additive increase/multiplicative decrease probing paradigm is at the core ofthe sliding window TCP congestion control algorithms and allows TCP flows toregulate the transmission rate in order to match the network capacity [1, 2, 3, 4,5]. It employs two variables: the congestion window (cwnd), which is the slidingwindow, and the slow start threshold (ssthresh), which varies the way cwnd isincreased. In order to probe the network capacity, cwnd is increased until acongestion episode happens. The cwnd increasing policy depends on ssthreshvalue. When cwnd < ssthresh, the cwnd is incremented by one segment for ev-ery received acknowledgement. This is the slow start phase that aims at quicklygrabbing the network available bandwidth. When cwnd ≥ ssthresh, the con-gestion avoidance phase is entered during which the cwnd is incremented byone segment per RTT. The congestion avoidance phase gently probes the net-work for extra available bandwidth. When 3 three duplicate acknowledgments(3 DUPACKs) are received ssthresh is set to cwnd/2 and cwnd is set equal tossthresh, whereas, if the retransmit timeout expires ssthresh is set to cwnd/2and cwnd is set equal to 1. The ssthresh represents an estimate of the currentavailable bandwidth. In fact, when the cwnd is less than ssthresh, the conges-tion control algorithm increases cwnd to quickly reach the ssthresh value andwhen cwnd=ssthresh, it increments the cwnd in a more gentle way in order toprobe for extra available bandwidth. TCP congestion control ensures that thenetwork capacity is never exceeded but it cannot guarantee fair sharing of thatcapacity [1].

To improve classic Reno/New Reno congestion control algorithms [2, 6], therecent Westwood TCP proposes to substitute the multiplicative decrease withan adaptive decrease phase: in particular, Westwood TCP passes through a fil-ter the stream of returning ACKs to obtain an estimate of the used bandwidth(BWE) so that when the network capacity is hit and a congestion episode hap-pens, Westwood adaptively reduces the congestion window and the slow-startthreshold to the value BWE times the minimum round trip time [7]. The origi-nal bandwidth estimation algorithms proposed in [7] does not work properly inthe presence of ACK compression [8]. Westwood+ TCP differs from WestwoodTCP in that it employs a new bandwidth estimation algorithm that works prop-erly also in the presence of ACK compression. Details concerning the filteringalgorithm can be found in [9, 10].

This paper aims at evaluating the performance of Westwood+ TCP over thereal Internet. To this purpose, a Linux 2.4.19 implementation of Westwood+TCP has been developed and compared with an implementation of New Reno[11]. To test and compare the two implementations more than 4000 files, withdifferent sizes, have been uploaded via ftp from a host at the Politecnico of Bari(South of Italy) to three remote servers, which are located at Parma (North ofItaly), Uppsala University (Sweden) and University of California Los Angeles(Ucla, California). Experimental results indicate that Westwood+ TCP im-proves the goodput with respect to New Reno TCP over paths with a bandwidthdelay product larger than few segments. In particular, goodput improvements

2

up to 40-50% have been measured when transmitting data from Politecnico ofBari to Uppsala and UCLA servers.

It is important to point out that GNU Linux 2.4 TCP implements the rate-halving algorithm [12] during the Fast Recovery/Fast Retransmit phase. Inorder to avoid abrupt interruption of data sending, which would be danger-ous for the self-clocking [1], we also implement the rate-halving algorithm inWestwood+ TCP.

The paper is organized as follows: Section 2 gives a brief explanation of TCPWestwood+ and describes an implementation in Linux 2.4.19; Section 3 reportsInternet measurements collected using this implementation; Finally, Section 4draws the conclusions.

2 TCP Westwood+

TCP Westwood+ differs from TCP Westwood in that it employs a differentbandwidth estimation algorithm that works properly even in presence of ACKcompression. In this section, we briefly describe the TCP Westwood algorithm.Subsequently, we introduce the new bandwidth estimation algorithm of West-wood+ TCP and its implementation in GNU Linux kernel.

2.1 TCP Westwood

TCP Westwood congestion control algorithm employs the following variables: (1) congestion window (cwnd) (2) slow start threshold (ssthresh) (3) roundtrip time of the connection (RTT ) (4) minimum round trip time measured bythe sender (RTTmin). TCP Westwood basic idea is to exploit the stream ofreturning ACK packets in order to obtain an estimate of connection availablebandwidth (BWE). The bandwidth estimate is used when a congestion episodeis detected to properly set the cwnd and ssthtresh. In absence of congestionepisodes, the dynamics of these variables is conform to RFC2581 [2]. A pseudo-code of the Westwood TCP algorithm follows:

- When 3 DUPACKs are received by the sender :ssthresh = (BWE * RTTmin) / MSS;if (ssthresh<2) ssthresh=2;cwnd = ssthresh;

- When coarse timeout expires :ssthresh = (BWE * RTTmin) / MSS;if (ssthresh<2) ssthresh=2;cwnd = 1;

- When ACKs are successfully received :cwnd increases as stated in RFC2581.

3

It is worth noting that the adaptive decrease mechanism employed by TCPWestwood improves the stability of the standard TCP multiplicative decrease.Infact, the adaptive windowd shrinking provides a congestion window that isdecreased enough in presence of heavy congestion and not too much in presenceof light congestion or losses not due to a real congestion episode, such as in thecase of unreliable radio links. Moreover the setting cwnd = BWE ∗ RTTmin

injects a transmission rate equal to B ∗RTTmin/RTT , which is less than band-width used at the time of congestion. As a consequence, a Westwood TCP flowclears out its path backlog after the setting thus leaving room in the routers’buffers for coexisting flows. This obviously improves network stability, statisti-cal multiplexing and fairness.

TCP Westwood congestion control is heavily based on bandwidth estimationalgorithm. As stated before, bandwidth estimation algorithm proposed in [7]overestimates the available bandwidth in the presence of ACK compression [8].In order to avoid this undesirable behavior, Westwood+ TCP proposes a newbandwidth estimation algorithm that works properly also in the presence ofACK compression [9, 10].

2.2 TCP Westwood+ bandwidth estimation algorithm

The new bandwidth estimation algorithm proposed along with Westwood+ TCPrelies on bandwidth samples which are collected every RTT instead that everytime an ACK is received by the sender. Basically, the Westwood+ TCP sendercounts the amount of data Dk, which is acknowledged during the last RTT = Tk

and then computes a bandwidth samples as Bk = Dk/Tk. In order to avoid po-tential numerical instabilities due to too small RTT values, a minimum value of50ms has been set for the catching time interval Tk. Details concerning the ACKcounting can be found in [7]. Briefly, a duplicate ACK counts for one deliveredsegments, a delayed ACK for two segments, whereas a cumulative ACK countsfor 1 segment or for the number of segments exceeding those already accountedfor by previous duplicate acknowledgments. Since congestion depends on lowfrequency components of available bandwidth [13], Bk samples are filtered usinga discrete time low-pass filter. In [10] it has been shows that the Bk samplescan be effectively filtered using a simple exponential filter as the following:

BWEk =78BWEk−1 +

18Bk (1)

The GNU Linux implementation of Westwood+ TCP slightly modifies the rate-halving mechanism to incorporate the adaptive setting of Westwood+ TCP. Inparticular, we exploit the gracefully cwnd decreasing phase of the rate-halvingmechanism but we do not allow the cwnd to become smaller than the valueBWE ∗RTTmin. Moreover, when the fast-recovery phase ends we set cwnd toBWE ∗RTTmin.

4

2.3 Implementation details

In order to implement TCP Westwood+ on GNU Linux kernel 2.4.19 a newstructure named westwood has been inserted in structure tcp opt. The tcp optis a per-socket structure that contains data that are useful for maintaining thestate of a TCP connection. For example, it contains variables identifying thecurrent window of data the sender is allowed to transmit, variables that maintainoptions of the TCP headers, variables for congestion control such as cwnd andssthresh and so on. This structure is employed only if the kernel is compiledwith the TCP Westwood+ support enabled. Notice that it is not possible tocompile this support as a loadable kernel module but it can be compiled onlystatically in the kernel image. This feature simplifies the design since it providesaccess to not exported kernel symbols. The patch was written having in mindthe idea of being as less intrusive as possible. The patch allows the superuser toenable/disable TCP Westwood+ at run-time. Moreover, the patch provides theoption to enable statistics logging support for testing purposes. It also parseslog files in such a way to easily manipulate experimental results [11].

3 Experimental Results

When a new protocol is proposed, it is necessary to collect a large set of experi-mental results in order to assess its validity and the advantages of its deploymentin the Internet [14]. To test and compare the Linux 2.4.19 implementations ofWestwood+ and New Reno TCP more than 4000 files, with different sizes, havebeen uploaded via ftp from a host at the Politecnico of Bari (South of Italy)to three remote servers, which are located at Parma (North of Italy), UppsalaUniversity (Sweden) and University of California Los Angeles (Ucla, Califor-nia). Tests were realized exploiting the patch feature which allows to switchbetween TCP GNU Linux standard implementation and TCP Westwood+. Foreach upload we have recorded the goodput, the number of retransmitted seg-ments, and important variables such as cwnd, sstresh, RTT and BWE. Eachsession of measurements collects data of many file uploads, which are alterna-tively executed by using Westwood+ or New Reno. Table 1 summarize themain characteristics of the measurement sessions involving the FTP server atthe UCLA. Fig. 1 shows the average goodputs achieved during data transferfrom Politecnico of Bari to UCLA. The average goodput of a measurement ses-sion is obtained by averaging the goodputs of all the uploads of that session.It is interesting to note that Westwood+ TCP provides goodput improvementsfrom 23% to 53% wrt New Reno. Moreover the goodput improvements providedby Westwood+ TCP are not due to a more aggressive behavior, since, Fig. 2shows that the retransmission ratio is roughly the same for both Westwood+and New Reno TCP.

5

date No. Size of uploaded filesof uploads (MBytes)

Feb,21 2003 117 32Feb,26 2003 197 3.2Feb,28 2003 702 3.2Mar,14 2003 54 32Mar,19 2003 79 32Mar,21 2003 47 32

Table 1: FTP uploads from Politecnico of Bari to UCLA, Los Angeles.

0

5

10

15

20

25

30

35

40

45

50

21 Feb 2003 26 Feb 2003 28 Feb 2003 14 Mar 2003 19 Mar 2003 21 Mar 2003

Ave

rage

Goo

dput

(K

Byt

es/s

)

New RenoWestwood+

Figure 1: Average Goodput of ftps from Politecnico of Bari to UCLA.

0

2

4

6

8

10

12

21 Feb 2003 26 Feb 2003 28 Feb 2003 14 Mar 2003 19 Mar 2003 21 Mar 2003

Rat

io o

f re

tran

smit

ted

segm

ents

(%

)

New RenoWestwood+

Figure 2: Retransmission ratios when transferring data from Politecnico of Barito UCLA.

6

Fig. 3 shows the typical dynamics of the congestion window and the slowstart threshold of Westwood+ TCP obtained during a file transfer from thePolitecnico of Bari to UCLA. Fig. 4 shows the same variables obtained duringthe next upload using New Reno. The main difference between Westwood+ andNew Reno consists in the ssthresh behavior, which is larger when Westwood+ isemployed. This effect is due to the adaptive decrease mechanism of Westwood+,which exploits the end-to-end bandwidth estimate. Fig. 5 shows the end-to-endbandwidth estimate obtained during the data transfer. Finally, Fig. 6 plots theRTT experienced by the Westwood+ flow during the data transfer.

0

2

4

6

8

10

12

14

16

18

20

0 2 4 6 8 10time (min)

Seg

men

ts

cwndssthresh

Figure 3: Congestion window and slow start threshold of Westwood+ TCP whiletransferring a 32MByte file from Politecnico of Bari to UCLA on 19/03/03.

0

2

4

6

8

10

12

14

16

18

20

0 1 2 3 4 5 6 7 8 9 10 11 12 13time (min)

Segm

ents

cwndssthresh

Figure 4: Congestion window and slow start threshold of New Reno TCP whiletransferring a 32MByte file from Politecnico of Bari to UCLA on 19/03/03.

Table 2 summarizes the main characteristics of the measurement sessionsinvolving the FTP server at the Uppsala University. Figs. 7 and 8 show theaverage goodputs and the average retransmission percentage when transferringdata from Politecnico of Bari to the Uppsala University.

7

10

20

30

40

50

60

70

80

90

0 2 4 6 8 10

time (min)

Band

wid

th e

stim

ate

(KBy

tes/s

)

Figure 5: Bandwidth estimate of Westwood+ TCP while transferring a 32MBytefile from Politecnico of Bari to UCLA on 19/03/03.

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0 2 4 6 8 10

time (min)

Roun

d Tr

ip T

ime

(s)

Figure 6: Round Trip Time experienced by Westwood+ TCP while transferringa 32MByte file from Politecnico of Bari to UCLA on 19/03/03.

8


Dec,14 2002 253 32Dec,17 2002 200 3.2Jan,10 2003 100 3.2Jan,12 2003 100 3.2Jan,13 2003 150 32Jan,17 2003 1000 3.2Feb,3 2003 278 32Feb,7 2003 500 32

Table 2: FTP from Politecnico of Bari to the Uppsala University (Sweden)

It is interesting to note that Westwood+ TCP provides goodput improve-ments from 4% to 40% wrt New Reno, whereas the percentages of retransmittedsegments are similar.

0

50

100

150

200

250

14 Dec2002

17 Dec2002

10 Jan2003

12 Jan2003

13 Jan2003

17 Jan2003

3 Feb1003

7 Feb2003

Ave

rage

Goo

dput

(K

Byt

es/s

)

New RenoWestwood+

Figure 7: Average Goodput of ftps from Politecnico of Bari to Uppsala.

Table 3 summarizes the main characteristics of the measurement sessionsinvolving the FTP server located at Parma. Figs. 9 and 10 show the good-puts and the retransmission ratios that have been measured while transferringdata from Politecnico of Bari to Parma. In this case the connection has a na-tional extension and Westwood+ and New Reno TCP basically achieve the samegoodput.

9

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

17 Dec2002

10 Jan2003

12 Jan2003

13 Jan2003

17 Jan2003

3 Feb 1003 7 Feb 2003

Rat

io o

f re

tran

smit

ted

segm

ents

(%

)

New RenoWestwood+

Figure 8: Retransmission ratios when transferring data from Politecnico of Barito Uppsala.


Mar,26 2003 100 32Mar,27 2003 98 3.2Mar,28 2003 1000 3.2Apr,4 2003 390 32Apr,7 2003 200 3.2Apr,9 2003 200 3.2Apr,11 2003 1000 3.2

Table 3: FTP uploads towards the server located at Parma (Italy)

10

Fig. 11 shows the congestion window and the slow start threshold of West-wood+ TCP during a file transfer from the Politecnico of Bari to Parma. Fig.12 shows the same variables obtained using New Reno. In this case cwnd andssthtresh exhibit a similar behavior. This is due to the small RTT that makesless drastic the effect of the Westwood+ TCP algorithm. Finally, Fig. 13 plotsthe bandwidth estimate obtained by Westwood+ whereas Fig. 14 shows theRTT measured during the data transfer.

0

20

40

60

80

100

120

140

160

26 Mar2003

27 Mar2003

28 Mar2003

4 Apr 2003 7 Apr 2003 9 Apr 2003 11 Apr2003

Ave

rage

Goo

dput

(KB

ytes

/s)

New RenoWestwood+

Figure 9: Average Goodput of ftps from Politecnico of Bari to Parma.

0

2

4

6

8

10

12

14

26 Mar2003

27 Mar2003

28 Mar2003

4 Apr 2003 7 Apr 2003 9 Apr 2003 11 Apr2003

Rat

io o

f re

tran

smit

ted

segm

ents

(%

)

New RenoWestwood+

Figure 10: Retransmission ratios when transferring data from Politecnico ofBari to Parma.

It is worth noting that minimum measured RTT is equal to 190ms for theconnection with the UCLA server, 70ms for the connection with the Uppsalaserver and 50ms for the connection with the server located at Parma. Table4 shows for each server the pipe size, which is computed as the average West-wood+ TCP goodput times the minimum RTT, and the related average goodputimprovement. Table 4 shows that when the pipe size is larger than few MSS,Westwood+ improves the goodput wrt New Reno up to 53%. We were not able

11

0

2

4

6

8

10

12

14

16

18

0 0.5 1 1.5 2 2.5 3 3.5time (min)

Segm

ents

cwndssthresh

Figure 11: Congestion window and slow start threshold of Westwood+ TCPwhile transferring a 32MByte file from Politecnico of Bari to Parma on 4/04/03.

0

2

4

6

8

10

12

14

16

18

20

0 0.5 1 1.5 2 2.5 3 3.5time (min)

Segm

ents

cwndssthresh

Figure 12: Congestion window and slow start threshold of New Reno TCP whiletransferring a 32MByte file from Politecnico of Bari to Parma on 4/04/03.

0

50

100

150

200

250

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5

time (min)

Band

wid

th e

stim

ate

(KBy

tes/s

)

Figure 13: Bandwidth estimate of Westwood+ TCP while transferring a32MByte file from Politecnico of Bari to Parma on 4/04/03.

12

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

0.2

0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50

time (min)

Roun

d Tr

ip T

ime

(s)

Figure 14: Round Trip Time experienced by Westwood+ TCP while transferringa 32MByte file from Politecnico of Bari to Parma on 4/04/03.

to execute measurements over larger bandwidth-delay paths where we expectthat Westwood+ will provide larger goodput improvements.

Server Goodput PipeImprovement size (MSS)

UCLA 23%÷ 53% 3-6Uppsala 4%÷ 40% 1-10Parma −9%÷ 10% 0.5-5

Table 4: Performance analysis, (MSS=1500Bytes)

To give a further insight, Figs. 15-20, report the goodputs achieved by NewReno and Westwood+ TCP during each transfer of the measurement sessiontransmitting data from Politecnico of Bari to UCLA. Figs. 27-26 report anal-ogous data for the uploads from Politecnico of Bari to the Uppsala Universityand Figs. 29-35 for the uploads from Politecnico of Bari to Parma.

13

0

10

20

30

40

50

60

70

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 2003

Date and hour

Goo

dput

(KBy

te/s)

Westwood+New Reno

Figure 15: Goodputs of 117 ftps executed on 21/02/2003 from Politecnico ofBari to UCLA (file size = 32MBytes).

0

5

10

15

20

25

30

35

40

45

50

Wed Feb 2613:35:16

2003

Wed Feb 2619:38:03

2003

Wed Feb 2622:53:27

2003

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 and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno

Figure 16: Goodputs of 197 ftps executed on 26/02/2003 from Politecnico ofBari to UCLA (file size = 3.2MBytes).

0

10

20

30

40

50

60

Fri Feb 2818:26:52

2003

Sat Mar 111:00:37

2003

Sat Mar 118:51:28

2003

Sun Mar 202:50:47

2003

Sun Mar 207:40:10

2003

Sun Mar 214:58:36

2003

Mon Mar 300:00:47

2003

Mon Mar 308:29:19

2003

Date and hour

Goo

dput

(KBy

tes/

s)

Westwood+New Reno

Figure 17: Goodputs of 702 ftps executed on 28/02/2003 from Politecnico ofBari to UCLA (file size = 3.2MBytes).

14

0

5

10

15

20

25

30

35

40

45

50

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 2003

Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno

Figure 18: Goodputs of 54 ftps executed on 14/03/2003 from Politecnico of Barito UCLA (file size = 32MBytes).

0

10

20

30

40

50

60

70

Wed Mar 19 14:15:25 2003 Thu Mar 20 07:53:33 2003 Fri Mar 21 05:29:19 2003

Date and hour

Goo

dput

(KB

ytes

/s)

Westwood+New Reno


0

20

40

60

80

100

120

140

160

180

Fri Mar 2120:05:57 2003

Sat Mar 2212:17:18 2003

Sun Mar 2302:57:08 2003

Sun Mar 2312:02:30 2003

Sun Mar 2320:25:37 2003

Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno


15

0

20

40

60

80

100

120

140

160

14 December 2002 15 December 2002 16 December 2002

Date

Goo

dput

(KB

ytes

/s)

Westwood+New Reno

Figure 21: Goodputs of 253 ftps executed on 14/12/2002 from Politecnico ofBari to the Uppsala University (file size = 32MBytes).

0

10

20

30

40

50

60

17 December2002

18 December2002

Date

Goo

dput

(KBy

tes/

s)

Westwood+

New Reno

Figure 22: Goodputs of 200 ftps executed on 17/12/2002 from Politecnico ofBari to the Uppsala University (file size = 3.2MBytes).

0

5

10

15

20

25

30

35

40

45

10 January 2003 11 January 2003

Date

Goo

dput

(KBy

tes/s

)

Westwood+

New Reno


16

0

5

10

15

20

25

30

35

12 January 2003 13 January 2003

Date

Goo

dput

(KBy

tes/s

)

Westwood+

New Reno


0

20

40

60

80

100

120

140

160

180

13 January2003

14 January2003

15 January2003

Date

Goo

dput

(KBy

tes/

s)

Westwood+

New Reno

Figure 25: Goodputs of 150 ftps executed on 13/01/2003 from Politecnico ofBari to the Uppsala University (file size = 32MBytes).

4 Conclusions

Westwood+ TCP with the rate-halving feature has been implemented in Linux2.4.19 and experimented over continental and international Internet connec-tions. Extensive measurements have shown that Westwood+ TCP improvesthe goodput wrt New Reno over connections with a bandwidth-delay productlarger than few MSS. In particular, over an Internet connection from Bari, Italyto Los Angeles, California, goodput improvements up to 50% have been mea-sured.

5 Acknowledgements

We thank Prof. Mario Gerla, Prof. Mikael Sternad and Daniele Verzelloni whoallowed us to collect live Internet measurements using FTP servers located at

17

0

20

40

60

80

100

120

140

Fri Jan 1714:04:32

2003

Sat Jan 1800:32:37

2003

Sat Jan 1804:28:31

2003

Sat Jan 1808:14:21

2003

Sat Jan 1813:18:49

2003

Sat Jan 1817:34:12

2003

Sat Jan 1821:58:11

2003

Date and hour

Good

put (

KByt

e/s)

Westwood+

New Reno


0

20

40

60

80

100

120

140

160

180

200

3 February 2003 4 February 2003 5 February 2003

Date

Goo

dput

(KB

ytes

/s)

Westwood+

New Reno

Figure 27: Goodputs of 278 ftps executed on 3/02/2003 from Politecnico of Barito the Uppsala University (file size = 32MBytes).

0

50

100

150

200

250

300

350

400

450

Fri Feb 718:43:14

2003

Sat Feb 805:14:49

2003

Sat Feb 811:30:33

2003

Sat Feb 823:28:39

2003

Sun Feb 906:56:15

2003

Sun Feb 911:50:38

2003

Sun Feb 917:02:12

2003

Sun Feb 923:42:26

2003Date and hour

Goo

dput

(KB

ytes

/s)

Westwood+New Reno

Figure 28: Goodputs of 500 ftps executed on 7/02/2003 from Politecnico of Barito the Uppsala University (file size = 32MBytes).

18

0

50

100

150

200

250

Wed Mar 2614:08:49 2003

Wed Mar 2623:13:37 2003

Thu Mar 2701:47:09 2003

Thu Mar 2704:12:13 2003

Thu Mar 2706:12:37 2003

Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno

Figure 29: Goodputs of 100 ftps executed on 26/03/2003 from Politecnico ofBari to Parma (file size = 32MBytes).

0

10

20

30

40

50

60

70

Thu Mar 2719:00:05 2003

Thu Mar 2720:52:46 2003

Fri Mar 2800:35:33 2003

Fri Mar 2804:17:52 2003

Fri Mar 2807:12:29 2003

Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno

Figure 30: Goodputs of 98 ftps executed on 27/03/2003 from Politecnico of Barito Parma (file size = 3.2MBytes).

0

20

40

60

80

100

120

140

Fri Mar 2818:00:46

2003

Sat Mar 2909:51:15

2003

Sat Mar 2920:12:43

2003

Sun Mar 3003:09:41

2003

Sun Mar 3007:11:20

2003

Sun Mar 3010:46:51

2003

Sun Mar 3017:21:39

2003

Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno

Figure 31: Goodputs of 1000 ftps executed on 28/03/2003 from Politecnico ofBari to Parma (file size = 3.2MBytes).

19

0

50

100

150

200

250

Fri Apr 418:47:58

2003

Sat Apr 503:51:10

2003

Sat Apr 508:58:01

2003

Sat Apr 523:21:35

2003

Sun Apr 606:39:31

2003

Sun Apr 613:52:39

2003

Sun Apr 622:02:58

2003

Mon Apr 704:32:25

2003

Date and hour

Goo

dput

(KBy

te/s)

Westwood+New Reno

Figure 32: Goodputs of 390 ftps executed on 4/04/2003 from Politecnico of Barito Parma (file size = 32MBytes).

0

10

20

30

40

50

60

70

80

90

100

Mon Apr 719:31:19

2003

Mon Apr 723:04:08

2003

Tue Apr 802:25:46

2003

Tue Apr 805:11:55

2003

Tue Apr 806:43:33

2003

Tue Apr 808:19:00

2003

Tue Apr 816:37:54

2003Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno


0

20

40

60

80

100

120

140

160

180

Wed Apr 913:55:29

2003

Wed Apr 920:29:51

2003

Wed Apr 922:31:51

2003

Wed Apr 923:38:28

2003

Thu Apr 1000:11:27

2003

Thu Apr 1000:42:54

2003

Thu Apr 1001:26:33

2003Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno


20

0

20

40

60

80

100

120

140

160

180

200

Fri Apr 1113:23:10

2003

Fri Apr 1122:56:08

2003

Sat Apr 1202:40:18

2003

Sat Apr 1206:15:08

2003

Sat Apr 1209:38:34

2003

Sat Apr 1214:30:34

2003

Sat Apr 1218:44:10

2003

Date and hour

Goo

dput

(KBy

tes/s

)

Westwood+New Reno

Figure 35: Goodputs of 1000 ftps executed on 11/04/2003 from Politecnico ofBari to Parma (file size = 3.2MBytes).

Universities of Los Angeles (USA), Uppsala (Sweden) and Parma (Italy).

References

[1] V. Jacobson. Congestion avoidance and control. In ACM Sigcomm ’88,pages 314–329, Stanford, CA, USA, August 1988.

[2] M. Allman, V. Paxson, and W. R. Stevens. TCP congestion control. RFC2581, April 1999.

[3] W. Stevens. TCP/IP Illustrated vol.1 : The Protocols. Addison Wesley,Reading, MA, 1994.

[4] D. Clark. The design philosophy of the darpa internet protocols. In ACMSigcomm ’88, pages 106–114, Stanford, CA, USA, August 1988.

[5] L. Peterson, B. Davie, and D. Clark. Computer Networks A Systems Ap-proach. Morgan Kaufmann, 2 edition, October 1999.

[6] S. Floyd and T. Henderson. NewReno modification to TCP’s fast recovery.RFC 2582, April 1999.

[7] S. Mascolo, C. Casetti, M. Gerla, M. Sanadidi, and R. Wang. TCP west-wood: End-to-end bandwidth estimation for efficient transport over wiredand wireless networks. In ACM Mobicom 2001, Rome, Italy, July 2001.

[8] L. A. Grieco and S. Mascolo. Westwood TCP and easy RED to improve fair-ness in high speed networks. In IFIP/IEEE Seventh International Work-shop on Protocols For High-Speed Networks, pages 130–146, Berlin, Ger-many, April 2002.

[9] R. Ferorelli, L. A. Grieco, S. Mascolo, G. Piscitelli, and P. Camarda. Liveinternet measurements using Westwood+ TCP congestion control. In IEEEGlobecom 2002, Taipei, Taiwan, November 2002.

21

[10] L. A. Grieco and S. Mascolo. End-to-end bandwidth estimation for conges-tion control in packet networks. In Second International Workshop, QoS-IP2003, pages 645–658, Milano, Italy, February 2003.

[11] Linux kernel v2.4.19. Available at http://www.kernel.org/pub/linux/kernel/v2.4/.

[12] Matt Mathis, Jeff Semke, Jamshid Mahdavi, and Kevin Lahey. The Rate-Halving Algorithm for TCP Congestion Control. draft-ratehalving.txt,June 1999.

[13] S. Q. Li and C. Hwang. Link capacity allocation and network control byfiltered input rate in high speed networks. IEEE/ACM Transactions onNetworking, 3(1):10–25, February 1995.

[14] S. Floyd and V. Paxson. Difficulties in simulating the internet. IEEE/ACMTransaction on Networking, 9:392–403, August 2001.

22

linux 2.4 implementation of westwood+ tcp with rate-halving ...in the internet [14]. to test and...

Documents