Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
date No. Size of uploaded filesof uploads (MBytes)
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.
date No. Size of uploaded filesof uploads (MBytes)
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
Figure 19: Goodputs of 79 ftps executed on 19/03/2003 from Politecnico of Barito UCLA (file size = 32MBytes).
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
Figure 20: Goodputs of 47 ftps executed on 21/03/2003 from Politecnico of Barito UCLA (file size = 32MBytes).
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
Figure 23: Goodputs of 100 ftps executed on 10/01/2003 from Politecnico ofBari to the Uppsala University (file size = 3.2MBytes).
16
0
5
10
15
20
25
30
35
12 January 2003 13 January 2003
Date
Goo
dput
(KBy
tes/s
)
Westwood+
New Reno
Figure 24: Goodputs of 100 ftps executed on 12/01/2003 from Politecnico ofBari to the Uppsala University (file size = 3.2MBytes).
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
Figure 26: Goodputs of 1000 ftps executed on 17/01/2003 from Politecnico ofBari to the Uppsala University (file size = 3.2MBytes).
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
Figure 33: Goodputs of 200 ftps executed on 7/04/2003 from Politecnico of Barito Parma (file size = 3.2MBytes).
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
Figure 34: Goodputs of 200 ftps executed on 9/04/2003 from Politecnico of Barito Parma (file size = 3.2MBytes).
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