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

Transcription

1 1 Analisys and Performance Evaluation of Westwood+, New Reno and Vegas TCP Congestion Control Saverio Mascolo poliba.it ictserv.poliba.it/.it/mascolo/ Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, Bari,, Italy Eurecom, October 21, 2004

2 2 Outline Part I: TCP Weswtood+ congestion control Part II: Performance evaluation of Westwood+, New Reno and Vegas TCP using ns-2 2 simulations (good practice when doing simulations). Measurements using Linux implementation of Westwood+ Part III: A control theoretic look at TCP congestion control

3 Application Data Send Socket Buffer TCP/IP Network TCP/IP m Receive Socket Buffer Application Data Advertised Window TCP/IP TCP/IP i buffer TCP/IP TCP/IP j TCP flows TCP/IP k Internet is a black box

4 4 Part I: Westwood+ + TCP Brief descriptiond of Westwood+ + TCP,, New Reno and Vegas TCP

5 Classic VJ TCP (Reno, New Reno) cwnd ssthresh Linear increasing Fast recovery Timeout Slow-start (SS) Exponential increasing Congestion Avoidance (CA) time Typical cwnd dynamics following the AIMD paradigm

6 TCP Westwood+ Saverio Mascolo Eurecom, Oct. 21, cwd Congestion Avoidance Adaptive decrease cwnd=ssthr=bwe*rttmin ssthresh Timeout BWE*RTTmin Slow start time y feature: adaptive window shrinking after congestion based on e measured available bandwidth (Adaptive decreasing vs. ultiplicative decreasing) estwood Adaptive decrease vs (New) Reno blind by ½ window shrinking

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

8 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) )

9 9 Warning ACKs reach the TCP sender compressed Bandwidth samples b j = t j d j t j 1 contain high frequency components that cannot be filtered out by a discrete-time time filter due to aliasing t j t j 1 = ACK interarrival time

10 e2e bandwidth estimate Westwood+ TCP BWE Low pass filter Segments sent Internet Anti ACK compression Returning ACKs

11 11 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

12 12 An anti-aliasing aliasing filter in packet networks b j = d j j Antialiased samples j = Last RTT d j = all data acknowledged in the last RTT

13 13 Low pass filtering Congestion depends on low-frequency components of available bandwidth Once ACKs have been smoothed, bandwidth samples b k need to be low-pass filtered

14 14 Result We are currently using the standard exponential filter bˆ k = bˆ α + (1 ) k 1 α b k b k = dk RTT k

15 15 Pseudo-code if (3 DUPACKs are received) ssthresh=bwe* =BWE*RTTmin; cwnd = ssthresh; endif enter congestion avoidance if (timeout expires) ssthresh=bwe* =BWE*RTTmin; cwnd = 1; endif enter slow-start start

16 16 Summary Westwood TCP: : one bandwidth sample computed for each ACK (Mobicom 01) Westwood+ TCP: : one bandwidth sample for each RTT (see ACM CCR April 04)

17 17 Part II: Performance evaluation Performance evaluation 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 For more details see: ACM Computer Communication Review, April 2004, and ICC04

18 18 We have found that ACK compression has very important effects on TCP. ACK compression must be considered when doing simulation

19 19 Topology with ACK compression effects (10 Mbps) 20 TCP Forward traffic: West TCP connection Sink R R 10 TCP Sinks Reverse traffic: 20 TCP connections 10 TCP Connections

20 The 20 Westwood+ connections estimate a best-effort available bandwidth that reasonably approaches the fair share of 0.5Mbps Saverio Mascolo Eurecom, Oct. 21, E+09 Bandwidth estimate (bps) 1.0E E E E E E E E+01 Fair share s

21 21 Westwood overestimates up to 100 times the fair share due to ACK compression Bandwidth estimate (bps) 1.0E E E E E E E E E s Fair share

22 Westwood+, New Reno and Vegas TCP Saverio Mascolo Eurecom, Oct. 21, 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 Reno is the leading Internet congestion control protocol

23 Vegas TCP Saverio Mascolo Eurecom, Oct. 21, TCP Vegas has been considered because, as Westwood+, 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. Fast TCP is still in a trial phase and authors do not have released any kernel code or ns-2 implementation. 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 ic)

24 24 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). See also recent papers by S. Low

25 25 Remark 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( 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.

26 26 1 Mbps 1.2E E+06 BWE Input Rate Bottleneck Capacity bps 1.0E E E E s

27 27 Single connection + 10 TCP connections on the backward path following an OFF-ON ON-OFF-ON pattern to investigate the effect of reverse traffic TCP 1 source Forward Traffic TCP 1 Sink 10 TCP Sinks Reverse Traffic 10 TCP sources

28 28 cwnd and ssthresh dynamics Segments NewReno cwnd ssthresh s Segments Westwood+ cwnd ssthresh s Segments Vegas cwnd ssthresh s Segments cwnd ssthresh Reno s

29 29 Fast TCP was found very handicapped in the presence of reverse traffic. See Les Cottrell papers at SLAC and recent papers by S. Low

30 30 Formula of Steady State Throughput T Reno = 1 RTT 2( 1 p p ) T West = 1 RTT Tq 1 p p

31 31 Intraprotocol Fairness M TCP flows persistent and controlled by the same algorithm over a single bottleneck. RTTs are uniformly spread in the interval [20+230/M,, 250]ms, with M ranging from 10 to 200, to investigate the fairness with respect to the round trip time

32 32 Total Goodput (bps) 1.0E E E E E E E E E E E+00 New Reno Vegas Westwood Fairness Index New Reno Vegas Westwood M=No. of TCP connections M

33 33 Visual look at fairness 20 connections Sequence Numbers (Segments) NewReno s s Sequence Numbers (Segments) Westwood + Sequence Numbers (Segments) Vegas s

34 34 Multihop Scenario Sink 3 C 3 Sink 5 C 5 C Sink 1 1 R R R R C 2 Sink 2 C 4 Sink 4 1 th hop 2 th hop Link between router: delay = 10ms, capacity = 10Mbps Entry exit links: delay = 20ms, capacity = 100Mbps Start time: C1:10s; Cross Traffic: 0s.

35 35 Case 1: description The C 2, C 3, C 4 C 2N+1 sources of cross traffic are controlled by New Reno TCP whereas the C 1 connection is controlled by New Reno, Vegas or Westwood+ This scenario aims at comparing New Reno, Vegas or Westwood+, when going through an Internet dominated by New Reno traffic.

36 36 Case 1: results Goodput of the C1 connection (bps) 1.0E E E E E+03 New Reno Vegas Westwood+ Fair share No. of traversed hops Total Goodput (bps) 1.0E E E E E E E E+06 New Reno Vegas Westwood No. of traversed hops C1 Goodput vs. number of traversed hops in the presence of New Reno cross traffic Total Goodput vs. number of traversed hops in the presence of New Reno cross traffic.

37 37 Case 2: description The C 2, C 3, C 4 C 2N+1 sources of cross traffic are controlled by Westwood+ TCP whereas the C 1 connection is alternatively controlled by New Reno, Vegas or Westwood+. This scenario allows us to investigate the friendliness of Westwood+ towards New Reno and Vegas TCP.

38 38 Case 2: results Goodput of the C1 connection (bps) 1.0E E E E E+03 New Reno Vegas Westwood+ Fair share No. of traversed hops C1 Goodput vs. number of traversed hops in the presence of Westwood+ cross traffic Total Goodput (bps) 1.0E E E E E E E E+06 New Reno Vegas Westwood No. of traversed hops Total Goodput vs. number of traversed hops in the presence of Westwood+ cross traffic.

39 39 Case 3: description The C 2, C 3, C 4 C 2N+1 sources of cross traffic are controlled by Vegas TCP whereas the C 1 connection is alternatively controlled by Reno, Vegas or Westwood+ This scenario investigates the friendliness of Vegas towards Reno and Westwood+ TCP

40 40 Case 3: Results Goodput of the C1 connection (bps) 1.0E E E E E+03 New Reno Vegas Westwood+ Fair share No. of traversed hops Total Goodput (bps) 1.0E E E E E E E E+06 New Reno Vegas Westwood No. of traversed hops C1 Goodput vs. number of traversed hops in the presence of Vegas cross traffic Total Goodput vs. number of traversed hops in the presence of Vegas cross traffic

41 41 Case 4: Description All traffic sources are controlled by the same control algorithm This is a homogeneous scenario aiming at evaluating New Reno, Westwood+ and Vegas TCP in absolute terms

42 42 Case 4: results Goodput of the C1 connection (bps) 1.0E E E E E+03 New Reno Vegas Westwood+ Fair share No. of traversed hops Total Goodput (bps) 1.0E E E E E E E E+06 New Reno Vegas Westwood No. of traversed hops C1 Goodput vs. number of traversed hops in the presence of homogeneous cross-traffic Total Goodput vs. number of traversed hops in the presence of homogeneous cross-traffic

43 43 Wireless terrestrialt scenario one way delay of TCP1 =125ms; 20ms delay on the wireless link (2Mbps) TCP1 source 5 TCP sources 10 TCP Sinks Cross Traffic Reverse Traffic 5 TCP Sinks 10 TCP sources Wireless link TCP1 sink

44 44 RTTs of 5 cross traffic connections and of 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 p equal to 0, when channel in the Good 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 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.

45 45 Single connection For each considered case, we run 10 simulations by varying the seed s of the random loss process. For each value of the BAD state duration we report the maximum, minimum and average goodputs. To o analyze only the impact of bursty losses on the TCP behavior, we have first turned off both the cross and reverse traffic sources. This s 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.

46 46 Goodput of TCP1 connection without reverse traffic: DACK enabled 2.0E E+06 Goodput (bps) 1.6E E E E E E E E E+00 Westwood+, DACK enabled New Reno, DACK enabled Duration of the BAD state (s)

47 47 Goodput of TCP1,, no reverse traffic: DACK disabled 2.0E E+06 Goodput (bps) 1.6E E E E E E E E E+00 Westwood+, DACK disabled New Reno, DACK disabled SACK Duration of the BAD state (s)

48 Typical behaviour of cwnd and ssthresh + ( duration of the BAD 0.01s) Saverio Mascolo Eurecom, Oct. 21, Segments Westwood+ cwnd ssthresh s Segments New Reno cwnd ssthresh s

49 49 reverse + cross traffic Westwood+ shares the wired portion of the network with several TCP T flows on the forward and backward paths (i.e. cross and reverse traffic are turned on) Results show that the delayed ACK option plays a major role in this scenario.

50 50 Goodput (bps) Westwood+, DACK disabled New Reno, DACK disabled SACK Westwood+, DACK enabled New Reno, DACK enabled Duration of the BAD state (s)

51 51 remarks Protocols that do not employ delayed ACK provides goodputs 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%. The reason is that in this case the TCP1 connection loses bandwidth in favor r of the cross traffic that, being wired, is not penalized by losses not due to congestion.

52 Satellite scenario Saverio Mascolo Eurecom, Oct. 21, 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.

53 53 Total Goodput (bps) Westwood+, DACK disabled Westwood+, DACK enabled SACK New Reno, DACK disabled New Reno, DACK enabled Duration of the BAD state (s)

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

55 Uploads to panther.cs cs.ucla.edu (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 Goodput (KB/s) Westwood+ New Reno 0 Wed Feb 26 13:35: Wed Feb 26 19:38: Wed Feb 26 22:53: Thu Feb 27Thu Feb 27Thu Feb 27Thu Feb 27 01:41: :10: :11: :23: Date

56 Uploads to panther.cs cs.ucla.edu (2) File size=32mb Westwood+ New Reno 60 Goodput (KB/s) Fri Feb 21 18:15: Sat Feb 22 06:04: Sat Feb 22 20:26: Sun Feb 23 07:24: Date Sun Feb 23 19:06: Mon Feb 24 03:52:

57 Uploads to panther.cs cs.ucla.edu (3) File size=32mb Westwood+ New Reno Goodput (KB/s) Fri Mar 14 18:59: Sat Mar 15 06:09: Sat Mar 15 13:29: Sat Mar 15 22:20: Date Sun Mar 16 09:57: Mon Mar 17 02:47:

58 Uploads to panther.cs cs.ucla.edu (4) Westwood+ New Reno File size=32mb Goodput (KB/s) Wed Mar 19 14:15: Wed Mar 19 22:55: Thu Mar 20 02:47: Thu Mar 20 06:08: Thu Mar 20 10:45: Date Thu Mar 20 19:52: Fri Mar 21 01:07: Fri Mar 21 05:29:

59 Main References S. Mascolo,, C. Casetti,, M. Gerla,, S. Lee, M. Sanadidi, TCP Westwood: bandwidth estimation for enhanced transport over wireless ess links, ACM Mobicom 01, and Winet Journal 02 L. A. Grieco, S. Mascolo Performance Comparison of Reno, Vegas, and Westwood+TCP Congestion Control,, ACM Computer Comm. Rev. Vol. 34 No. 2, April 2004 A. Dell Aera Aera,, L. A. Grieco,, S. Mascolo, Linux 2.4 Implementation of Westwood+ TCP with rate-halving: A Performance Evaluation over the Internet, (ICC04), Paris, France, June D. Cavendish, M. Gerla, S. Mascolo, A A Control Theoretical Approach to Congestion Control in Packet Networks to appear IEEE/ACM Transactions on Networking,, October 2004.

60 60 Conclusions Evaluation and comparison of Westwood+, New Reno and Vegas TCP using ns-2 has shown: inter-protocol friendliness of Westwood+ and New Reno whereas Vegas is not able to grab its bandwidth share when coexisting with New Reno or Westwood+; increased intra-protocol fairness in bandwidth allocation of Westwood+ TCP w.r.t. New Reno; improved utilization of lossy links provided by Westwood+ wrt New Reno. measurements collected over the real Internet have shown that Westwood+ improve the goodput with respect to New Reno TCP when the pipe size is larger than few segments.

61 61 Further research Realistic characterization of wireless links still needed in ns-2! Can we expect the same result with Westwood+ over the gigabit Internet?