1 Performance Evaluation and Comparison of Westwood+, New Reno and Vegas TCP Congestion Control Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, Bari, Italy Gotland August 25, 2004

2Saverio Mascolo – WIP/Beats 04, Visby, GotlandOutline Brief description of Westwood+ TCP, New Reno and Vegas TCP Brief description of Westwood+ TCP, New Reno and Vegas TCP Performance evaluation of Westwood+, New Reno and Vegas TCP using ns-2 Performance evaluation of Westwood+, New Reno and Vegas TCP using ns-2 Internet measurements using an implementation of Westwood+ in Linux 2.4 (Westwood+ is now in the official kernel of Linux 2.6 at Internet measurements using an implementation of Westwood+ in Linux 2.4 (Westwood+ is now in the official kernel of Linux 2.6 at For more details see: ACM Computer Communication Review, April 2004, and ICC04 For more details see: ACM Computer Communication Review, April 2004, and ICC04

3Saverio Mascolo – WIP/Beats 04, Visby, Gotland WESTWOOD+ 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)

4Saverio Mascolo – WIP/Beats 04, Visby, Gotland TCP Westwood+ Congestion Avoidance Slow start cwnd time Timeout ssthresh BWE*RTTmin Adaptive decrease cwnd=ssthr=BWE*RTTmin Westwood Adaptive decrease vs (New) Reno blind by ½ window shrinking

5Saverio Mascolo – WIP/Beats 04, Visby, Gotland Rate 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 estimation The rate of returning ACKS is exploited to estimate the “best-effort” available bandwidth The rate of returning ACKS is exploited to estimate the “best-effort” available bandwidth ACKs packets Filter RECEIVER SENDER Bandwidth estimate ACKs packets Network

7Saverio Mascolo – WIP/Beats 04, Visby, Gotland An anti-aliasing filter in packet networks Antialiased samples

8Saverio Mascolo – WIP/Beats 04, Visby, Gotland ACK compression effects ACK pairs give information about the bandwidth of the last link traversed on the backward path ACK pairs give information about the bandwidth of the last link traversed on the backward path To smooth ACK compression we accumulate ACKs over an RTT and then compute a bandwidth sample To smooth ACK compression we accumulate ACKs over an RTT and then compute a bandwidth sample

9Saverio Mascolo – WIP/Beats 04, Visby, Gotland We are currently using the standard exponential filter We are currently using the standard exponential filter

10Saverio Mascolo – WIP/Beats 04, Visby, Gotland Summary on bandwidth estimate Westwood TCP: one bandwidth sample computed for each ACK (Mobicom 01)=>> Bandwdith overestiamte (when ACK compression) Westwood TCP: one bandwidth sample computed for each ACK (Mobicom 01)=>> Bandwdith overestiamte (when ACK compression) Westwood+ TCP: one bandwidth sample for each RTT (see ACM CCR, April 04) Westwood+ TCP: one bandwidth sample for each RTT (see ACM CCR, April 04)

Advantages of Westwood+ TCP  higher throughput over wireless links because losses due to unreliable links do not provoke overshrinking of the congestion window  Improved fairness wrt to Reno (Reno throughput is proportional to 1/RTT whreas Westwood throughput is proportional to 1/sqrt(RTT) )

12Saverio Mascolo – WIP/Beats 04, Visby, Gotland New Reno TCP New Reno is an improved version of Reno that avoids multiple reductions of the cwnd when several segments from the same window of data get lost New Reno is an improved version of Reno that avoids multiple reductions of the cwnd when several segments from the same window of data get lost RFC 3782, S. Floyd, T. Henderson, A. Gurtov, “The NewReno Modification to TCP's Fast Recovery Algorithm” RFC 3782, S. Floyd, T. Henderson, A. Gurtov, “The NewReno Modification to TCP's Fast Recovery Algorithm” New Reno is the leading Internet congestion control protocol New Reno is the leading Internet congestion control protocol

13Saverio Mascolo – WIP/Beats 04, Visby, Gotland Vegas TCP Vegas TCP was the first attempt to depart from the loss- driven paradigm of the TCP by introducing a mechanism of congestion detection before packet losses: Vegas TCP was the first attempt to depart from the loss- driven paradigm of the TCP by introducing a mechanism of congestion detection before packet losses: Vegas TCP computes the difference  between the actual input rate (cwnd/RTT) and the expected rate (cwnd/RTT min ), to infer network congestion. If  is smaller than a threshold α then the cwnd is additively increased, whereas if the difference is greater than another threshold β then the cwnd is Additively Decreased; finally, if α <  <β then the cwnd is kept constant. It has been shown that Vegas TCP ensures network stability but it is not able to grab its own bandwidth share when interacting with algorithms that systematically hits network queue capacity such as Reno. Vegas TCP computes the difference  between the actual input rate (cwnd/RTT) and the expected rate (cwnd/RTT min ), to infer network congestion. If  is smaller than a threshold α then the cwnd is additively increased, whereas if the difference is greater than another threshold β then the cwnd is Additively Decreased; finally, if α <  <β then the cwnd is kept constant. It has been shown that Vegas TCP ensures network stability but it is not able to grab its own bandwidth share when interacting with algorithms that systematically hits network queue capacity such as Reno.

14Saverio Mascolo – WIP/Beats 04, Visby, Gotland TCP Vegas has been considered because: TCP Vegas has been considered because: Analogously to Westwood+, it is based on mechanism for throttling the congestion window based on RTT measurements. Analogously to Westwood+, it is based on mechanism for throttling the congestion window based on RTT measurements. Vegas TCP is behind the new Fast TCP (by researchers at Caltech ). In authors’ words, “Fast TCP is a sort of high- speed version of Vegas”. Vegas TCP is behind the new Fast TCP (by researchers at Caltech ). In authors’ words, “Fast TCP is a sort of high- speed version of Vegas”. Fast TCP is still in a trial phase and no kernel code or ns-2 implementation available at time of this work Fast TCP is still in a trial phase and no kernel code or ns-2 implementation available at time of this work Being based on RTT measurements to infer congestion, Fast TCP could inherit all drawbacks of Vegas that will be illustrated ( incapacity to grab bandwidth when coexisting with Reno traffic or in the presence of reverse traffic) Being based on RTT measurements to infer congestion, Fast TCP could inherit all drawbacks of Vegas that will be illustrated ( incapacity to grab bandwidth when coexisting with Reno traffic or in the presence of reverse traffic)

15Saverio Mascolo – WIP/Beats 04, Visby, Gotland Following our suggestions, Les Cotrell at Stanford Linear Accelerator Center found that Fast TCP is, in his words “very handicapped in the presence of reverse traffic” (fall 2003) Following our suggestions, Les Cotrell at Stanford Linear Accelerator Center found that Fast TCP is, in his words “very handicapped in the presence of reverse traffic” (fall 2003)

16Saverio Mascolo – WIP/Beats 04, Visby, Gotland Performamce evaluation Bandwidth estimate Bandwidth estimate

17Saverio Mascolo – WIP/Beats 04, Visby, Gotland Topology with ACK compression effects (10 Mbps) 10 TCP RR Sink 10 TCP Sinks 10 TCP Connections Reverse traffic: 20 TCP connections Forward traffic: West TCP connection

18Saverio Mascolo – WIP/Beats 04, Visby, Gotland The 20 Westwood+ connections estimate a best-effort available bandwidth that reasonably approaches the fair share of 0.5Mbps

19Saverio Mascolo – WIP/Beats 04, Visby, Gotland Westwood overestimates up to 100 times the fair share due to ACK compression

20Saverio Mascolo – WIP/Beats 04, Visby, GotlandRemark Westwood estimate is different from measuring the low frequency components of the sending rate cwnd/RTT (cwnd/RTT is the measure of the instantaneous throughput employed by Vegas TCP) Westwood estimate is different from measuring the low frequency components of the sending rate cwnd/RTT (cwnd/RTT is the measure of the instantaneous throughput employed by Vegas TCP) In fact, the Vegas actual rate cwnd/RTT is a measure of the available bandwidth that is based on the number of sent packets (cwnd) and not on the number of acknowledged packets d k. As a consequence, Vegas samples do not take into account that a fraction of sent packets could be lost thus leading to available bandwidth overestimate. In fact, the Vegas actual rate cwnd/RTT is a measure of the available bandwidth that is based on the number of sent packets (cwnd) and not on the number of acknowledged packets d k. As a consequence, Vegas samples do not take into account that a fraction of sent packets could be lost thus leading to available bandwidth overestimate.

21Saverio Mascolo – WIP/Beats 04, Visby, Gotland 1 Mbps

22Saverio Mascolo – WIP/Beats 04, Visby, Gotland Formula of Steady State Throughput

23Saverio Mascolo – WIP/Beats 04, Visby, Gotland Single connection + 10 TCP connections on the backward path following an OFF-ON-OFF-ON pattern to investigate the effect of reverse traffic TCP 1 source 10 TCP sources Forward Traffic Reverse Traffic TCP 1 Sink 10 TCP Sinks

24Saverio Mascolo – WIP/Beats 04, Visby, Gotland cwnd and ssthresh dynamics NewRenoWestwood+ VegasReno

25Saverio Mascolo – WIP/Beats 04, Visby, Gotland Visual look at fairness 20 connections NewReno Westwood + Vegas

26Saverio Mascolo – WIP/Beats 04, Visby, Gotland Wireless terrestrial scenario one way delay of TCP1 =125ms; 20ms delay on the wireless link (2Mbps) 5 TCP sources 10 TCP sources Cross Traffic Reverse Traffic 5 TCP Sinks 10 TCP Sinks TCP1 source Wireless link TCP1 sink

27Saverio Mascolo – WIP/Beats 04, Visby, Gotland RTTs 5 cross traffic connections and 10 New Reno backward traffic connections are uniformly spread in the intervals [66ms,250ms] and [46ms,250ms], respectively. RTTs 5 cross traffic connections and 10 New Reno backward traffic connections are uniformly spread in the intervals [66ms,250ms] and [46ms,250ms], respectively. wireless link affected by bursty segment losses in both directions wireless link affected by bursty segment losses in both directions A Gilbert two state Markov chain models the loss process A Gilbert two state Markov chain models the loss process loss probability p equal to 0, when channel in the Good state, loss probability p equal to 0, when channel in the Good state, p =0.1 when the channel is in the Bad state. p =0.1 when the channel is in the Bad state. permanence time in the Good state deterministic and equal to 1s permanence time in the Good state deterministic and equal to 1s permanence time in the Bad state also deterministic ranging from 0.1ms to 100 ms. permanence time in the Bad state also deterministic ranging from 0.1ms to 100 ms. When the permanence time in a state elapses, the state can transit to a Good or Bad state with a probability p=0.5. When the permanence time in a state elapses, the state can transit to a Good or Bad state with a probability p=0.5.

28Saverio Mascolo – WIP/Beats 04, Visby, Gotland Single connection For each considered case, we run 10 simulations by varying the seed of the random loss process. For each value of the BAD state duration we report the maximum, minimum and average goodputs. For each considered case, we run 10 simulations by varying the seed of the random loss process. For each value of the BAD state duration we report the maximum, minimum and average goodputs. In order to analyze only the impact of bursty losses on the TCP behavior, we have first turned off both the cross and reverse traffic sources. This simple scenario is particularly useful to investigate the effectiveness of the adaptive decrease paradigm when losses not due to congestion are experienced by the TCP. In order to analyze only the impact of bursty losses on the TCP behavior, we have first turned off both the cross and reverse traffic sources. This simple scenario is particularly useful to investigate the effectiveness of the adaptive decrease paradigm when losses not due to congestion are experienced by the TCP.

29Saverio Mascolo – WIP/Beats 04, Visby, Gotland Goodput of TCP1 connection without reverse traffic: DACK enabled

30Saverio Mascolo – WIP/Beats 04, Visby, Gotland Goodput of TCP1, no reverse traffic: DACK disabled

31Saverio Mascolo – WIP/Beats 04, Visby, Gotland Cwnd and ssthresh + ( duration of the BAD 0.01s) Westwood+New Reno

32Saverio Mascolo – WIP/Beats 04, Visby, Gotland reverse + cross traffic One further point valuable of investigation is when Westwood+ shares the wired portion of the network with several TCP flows on the forward and backward paths. One further point valuable of investigation is when Westwood+ shares the wired portion of the network with several TCP flows on the forward and backward paths. For that purpose, we turn on the cross and reverse traffic and we measure the goodput of the TCP1 connections for various values of the BAD state duration. For that purpose, we turn on the cross and reverse traffic and we measure the goodput of the TCP1 connections for various values of the BAD state duration.

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

34Saverio Mascolo – WIP/Beats 04, Visby, GotlandRemarks The delayed ACK option plays a major role in this scenario. In fact, protocols that do not employ the delayed ACK option provides goodputs that are roughly two times larger than those obtained when the delayed ACK option is enabled. The reason is that the delayed ACK option slows down the TCP probing phase. The delayed ACK option plays a major role in this scenario. In fact, protocols that do not employ the delayed ACK option provides goodputs that are roughly two times larger than those obtained when the delayed ACK option is enabled. The reason is that the delayed ACK option slows down the TCP probing phase. In these scenarios Westwood+ TCP (DACK disabled) still improves the goodput with respect to New Reno (DACK disabled) and SACK TCP, but the improvement is now only up to roughly 20% since in this case the TCP1 connection loses bandwidth in favor of the cross traffic that, being wired, is not penalized by losses not due to congestion. In these scenarios Westwood+ TCP (DACK disabled) still improves the goodput with respect to New Reno (DACK disabled) and SACK TCP, but the improvement is now only up to roughly 20% since in this case the TCP1 connection loses bandwidth in favor of the cross traffic that, being wired, is not penalized by losses not due to congestion.

35Saverio Mascolo – WIP/Beats 04, Visby, Gotland Satellite 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.

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

Linux implementation of Westwood+ TCP More than 4000 FTP froma Bari, South Italy to: More than 4000 FTP froma Bari, South Italy to: signserv.signal.uu.se (Uppsala) signserv.signal.uu.se (Uppsala) panther.cs.ucla.edu (UCLA) panther.cs.ucla.edu (UCLA) main.penguin.it (Parma) main.penguin.it (Parma)

38Saverio Mascolo – WIP/Beats 04, Visby, Gotland Average goodput during ftp to Los Angeles

39Saverio Mascolo – WIP/Beats 04, Visby, Gotland Retransmission ratio during ftp to UCLA

40Saverio Mascolo – WIP/Beats 04, Visby, Gotland Average goodput during ftp to Uppsala Average Goodputs (Kbytes/s)

41Saverio Mascolo – WIP/Beats 04, Visby, Gotland Retransmission ratio during ftp to Uppsala

42Saverio Mascolo – WIP/Beats 04, Visby, Gotland Average goodput during ftp to Parma Average Goodputs (Kbytes/s)

43Saverio Mascolo – WIP/Beats 04, Visby, Gotland Retransmission ratio during ftp to Parma Retransmission ratio (%)

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

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

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

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

48Saverio Mascolo – WIP/Beats 04, Visby, Gotland Further research Realistic Characterization of wireless links still needed in ns-2! Realistic Characterization of wireless links still needed in ns-2! Can we expect the same result with Westwood+ over the gigabit Internet? (tests are going at SLAC and CERN) Can we expect the same result with Westwood+ over the gigabit Internet? (tests are going at SLAC and CERN)

49Saverio Mascolo – WIP/Beats 04, Visby, Gotland  Thanks for the attention and Questions?