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

1. Performance Evaluation and Comparison of Westwood+, New Reno and Vegas TCP Congestion Control Saverio Mascolo mascolo@poliba.it http://www-ictserv.poliba.it/mascolo/ Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari, Italy Gotland August25, 2004

2. Outline • Brief description of Westwood+ TCP, New Reno and Vegas TCP • 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 www.kernel.org) • For more details see: ACM Computer Communication Review, April 2004, and ICC04 Saverio Mascolo – WIP/Beats 04, Visby, Gotland

3. WESTWOOD+ TCP • key ideaof Westwood+: • to use the stream of ack packets to get an e2e estimateof the available bandwidth to be used for setting cwnd and ssthreshafter congestion (whereas standard TCP implements a “blind” by half window decrease) Saverio Mascolo – WIP/Beats 04, Visby, Gotland

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

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

6. E2E bandwidth estimation • The rate of returning ACKS is exploited to estimate the “best-effort” available bandwidth packets packets SENDER RECEIVER Network Filter Bandwidth estimate ACKs ACKs

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

8. ACK compression effects • 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 Saverio Mascolo – WIP/Beats 04, Visby, Gotland

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

10. 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 for each RTT (see ACM CCR, April 04) Saverio Mascolo – WIP/Beats 04, Visby, Gotland

11. Advantages of Westwood+ TCP • higher throughput over wireless links because losses due to unreliable links do not provokeovershrinking 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) )

12. New Reno TCP Saverio Mascolo – WIP/Beats 04, Visby, Gotland • 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” • New Renois the leading Internet congestion control protocol

13. Vegas TCP Saverio Mascolo – WIP/Beats 04, Visby, Gotland • 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/RTTmin), 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.

14. Saverio Mascolo – WIP/Beats 04, Visby, Gotland • TCP Vegas has been considered because: • Analogously to Westwood+, itis 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”. • Fast TCP is stillin 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)

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

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

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

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

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

20. Remark Saverio Mascolo – WIP/Beats 04, Visby, Gotland 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 dk. 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.

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

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

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

24. cwnd and ssthresh dynamics NewReno Westwood+ Vegas Reno Saverio Mascolo – WIP/Beats 04, Visby, Gotland

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

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

27. Saverio 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. • wireless link affected by bursty segment losses in both directions • A Gilbert two state Markov chain models the loss process • loss probability pequal to 0, when channel in the Goodstate, • p=0.1 when the channel is in the Badstate. • permanence time in the Goodstate deterministic and equal to 1s • 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.

28. Single connection Saverio Mascolo – WIP/Beats 04, Visby, Gotland • 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.

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

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

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

32. reverse + cross traffic Saverio Mascolo – WIP/Beats 04, Visby, Gotland 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.

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

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

35. 20 TCP 20 TCP senders sinks 10 TCP 10 TCP senders sinks Satellite scenario • 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. Saverio Mascolo – WIP/Beats 04, Visby, Gotland

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

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

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

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

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

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

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

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

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

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

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

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

48. Further research • 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) Saverio Mascolo – WIP/Beats 04, Visby, Gotland

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