TCP Westwood: Efficient Transport for High-speed wired/wireless Networks

1. TCP Westwood: Efficient Transport for High-speed wired/wireless Networks 2009

2. TCP Westwood(Mobicom 2001) Key Idea: • Enhance congestion control via theRate Estimate (RE) • Samples are determined from ACK inter-arrival times and info in ACKs regarding amounts of bytes delivered • Estimate is computed at the sender by sampling and exponential filtering • RE is used by sender to properly setcwnd and ssthresh after packet loss (indicated by 3 DUPACKs, or Timeout)

3. Bottleneck packets Receiver Sender ACKs measure Internet Rate Estimation (BE-> RE) • Ideally, would like to determine the connection fair share of the bottleneck bandwidth • Since fair share is difficult (to define or determine), we instead estimate the achieved rate: Rate Estimate (RE)

4. dk tk-1 tk “Original” Rate estimation (BE-> RE) • First TCPW version used a “bandwidth like” estimator (BE) given by: sample exponential filter filter gain RE/BE Estimation is similar to Keshav Packet Pair estimation

5. TCP Westwood: the control algorithm • TCPW Algorithm Outline: • When three duplicate ACKs are detected: • set ssthresh=BE*RTTmin(instead of ssthresh=cwin/2 as in Reno) • if (cwin > ssthresh) set cwin=ssthresh • When a TIMEOUT expires: • set ssthresh=BE*RTTmin(instead of ssthresh=cwnd/2 as in Reno) and cwin=1 Note: RTTmin= min round trip delay experienced by the connection

6. Extensions to TCP • End-to-end congestion control • Selective acknowledgements: TCP SACK • Delay-based congestion avoidance: TCP Vegas • TCP-Friendly Rate Control: TFRC • Binomial Congestion Control • Router - assisted Congestion Control • Active Queue Mgmt. (AQM) and RED • Explicit congestion notification: ECN • eXplicit Control Protocol: XCP • Discriminating between congestion losses and other losses: cross-layer signaling and guesses losses

7. Related TCP + Bdw estimation work • Bandwidth estimate used by Vegas and Keshav PP • TCP Vegas monitors Bdw and RTT to infer the bottleneck queue; then, from queue it derives feedback to congestion window • Expected = window size / round trip time • Actual = acks / round trip time • Queues (bottleneck) ~ expected - actual • Keshav’s Packet Pair scheme also monitors bandwidth to estimate the bottleneck queue and compare to common queue target; it adjusts source rate • Main difference: TCP Westwood does not need common queue target; it enforces fair share instead.

8. TCP Westwood Benefits What do we gain by using RE “feedback” in addition to packet loss? (a) ability to distinguish random loss from buffer loss, i.e. better performance with random loss (ie, loss caused by random errors as opposed to overflow) -- exponential filtering (b) using RE to estimate bottleneck bdw during slow start -- estimate the achieved rate

9. TCPW and random loss • Reno overreacts to random loss (cwin cut by half) • TCPW less sensitive to random loss • (1) a small fraction of “randomly” lost packets minimally impacts the rate estimate RE • (2) Thus, cwin = RE x RTT remains unchanged • As a result, TCPW throughput is higher than Reno and SACK in presence of random loss

10. TCPW in presence of random loss: Analysis and Simulation

11. TCPW in a wireless lossy environment • Efficiency: Improvement significant on high (Bdw x Length) paths • Fairness: better fairness than RENO under varying RTT • Friendliness: TCPW is friendly to TCP Reno

12. NASA Workshop Demo (From Steve Schultz, NASA) Internet Throughput Measurement

13. TCPW Friendliness • Friendliness: fairness across different TCP flavors “Friendly share” principle: TCPW is allowed to recover the bandwidth wasted by NewReno because of “blind” window reduction • TCPW original RE (BE) filter has Friendliness Problem…. • 5 connections total (TCPW + RENO) ; • Average throughput per connection is shown in the next slide

14. TCPW TCPW 1.4 1.4 Reno Reno 1.2 1.2 1 1 Average Throughput(Mbps) 0.8 0.8 0.6 0.6 0.4 0.4 0.2 0.2 0 0 0 1 2 3 4 5 0 1 2 3 4 5 No. of Reno connections TCPW & Reno friendliness No link errors Lossy link (1% pkt loss) Average Throughput(Mbps) No. of Reno connections • Average TCPW & Reno throughputs vs. TCPW/Reno mix (5 connections total)

15. dk tk-1 tk TCPW original estimation (BE) • Recall that the first TCPW version used a “bandwidth like” estimator (BE) given by: sample exponential filter filter gain

16. TCPW Rate Estimation (TCP RE) dk-1 dk • Rate estimate (RE) is obtained by aggregating the data ACKed during the interval T (typically = RTT): tk T is the sample interval T sample exponential filter filter gain

17. TCPW RE or BE interaction with RENO One TCPW RE or BE and one Reno share a 5Mbps bottleneck No errors (bottleneck gets saturated) Errors (0.5%), no congestion fair share* fair share BE overestimates fair rate ( = 2.5 Mbps) TCPW BE Not friendly to NewReno! RE underestimates fair rate (=3.6 Mbps) TCPW RE does not improve thruput! (*) TCPW fair share > 50% because NewReno is incapable of getting 50%

18. TCPW with adaptive filter (AF) • Neither RE or BE estimator are optimal for all situations • BE is more effective in random loss • RE is more appropriate in congestion loss (ie, buffer overflow) • KEY IDEA: dynamically select the aggressive estimate (BE) or the conservative estimate (RE) depending on current channel status (congestion or random loss?) • NEEDED: a “congestion measure” that gives us an idea of the most probable cause of packet loss (congestion or random) • The Adaptive Filter actually provides a smooth transition from aggressive to conservative measure

19. Tk Tk TCPW AF: Sampling • Adapting the size of sampling intervals to congestion level measure continuous adaptation No Congestion: Tk = inter ACK Congestion: Tk grows Rate sample

20. TCPW AF: Sampling (cont) • The sample size Tk is continuously adjusted according to current congestion: Max throughput assuming there is no congestion in the network actual achieved throughput Severe Congestion: Tk --> RTT Upon ACK Receipt Sampleinterval Tk ABE Computes Congestion Level Link Under Utilized: Tk --> 0 (ie, inter ACK intrv)

21. TCP Westwood with Agile Probing: Handling Dynamic Large Leaky Pipes-- Problem addressInfocom 2004 • Leaky Pipes: packet loss due to error • Unjustified cwnd cut and premature Slow Start exit • Large Pipes: Large capacity and long delay • Control scheme may not scale • Dynamic Pipes: Dynamic load/changing link bandwidth (Due to change of technologies, e.g., 802.11, Bluetooth, GPRS) • Linear increase limits efficiency

22. Persistent Non-Congestion Detection(PNCD) Persistent Non-congestion detected, Agile Probing invoked Dominant flows leave At around 50 sec

23. Agile Probing • Objective: Guided by ERE(Eligible Rate Estimate), converge fasterto more appropriate ssthresh • adaptively and repeatedly resetsssthresh to ERE*RTTmin • Exponentially increase cwnd if ssthresh >cwnd • Linearly increase cwnd if ERE < ssthresh • Exit Agile Probing when packet loss is detected

24. Agile Probing

25. Lab Measurements Results (FreeBSD Implementation) Startup invokes Agile Probing Persistent Non-Congestion Detection(PNCD) invokes Agile Probing after dominant flow left

26. Summary • Introduced the concept of Rate Estimation and related work • Reviewed end-to-end estimation based congestion control methods • Presented TCP Westwood, and the evolution of “fair rate” estimate to improve the performance; showed simulation results to evaluate the method • Compared TCPW with other methods