1. TCP Westwood (with Faster Recovery) Claudio Casetti (casetti@polito.it) Mario Gerla (gerla@cs.ucla.edu) Scott Seongwook Lee (sslee@cs.ucla.edu) Saverio Mascolo (mascolo@deemail.poliba.it) Medy Sanadidi (medy@cs.ucla.edu) Computer Science Department University of California, Los Angeles, USA

2. TCP Congestion Control Based on a sliding window algorithm Two stages: –Slow Start, initial probing for available bandwidth (“exponential” window increase until a threshold is reached) –Congestion Avoidance,”linear” window increase by one segment per RTT Upon loss detection (coarse timeout expiration or duplicate ACK) the window is reduced to 1 segment (TCP Tahoe)

3. Congestion Window of a TCP Connection Over Time

4. Shortcomings of current TCP congestion control After a sporadic loss, the connection needs several RTTs to be restored to full capacity It is not possible to distinguish between packet loss caused by congestion (for which a window reduction is in order) and a packet loss caused by wireless interference The window size selected after a loss may NOT reflect the actual bandwidth available to the connection at the bottleneck

5. New Proposal:TCP with “Faster Recovery” Estimation of available bandwidth (BWE): –performed by the source –computed from the arrival rate of ACKs, smoothed through exponential averaging Use BWE to set the congestion window and the Slow Start threshold

6. TCP FR: Algorithm Outline When three duplicate ACKs are detected: –set ssthresh=BWE*rtt (instead of ssthresh=cwin/2 as in Reno) –if (cwin > ssthresh) set cwin=ssthresh When a TIMEOUT expires: –set ssthresh=BWE*rtt (instead of ssthresh=cwnd/2 as in Reno) and cwin=1

7. Experimental Results Compare behavior of TCP Faster Recovery with Reno and Sack Compare goodputs of TCP with Faster Recovery, TCP Reno and TCP Sack –with bursty traffic (e.g., UDP traffic) –over lossy links

8. FR/Reno Comparison 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0100200300400500600700800 normalized throughput Time (sec) 1 TCP + 1 On/Off UDP (ON=OFF=100s) 5 MB buffer - 1.2s RTT - 150 Mb/s Cap. FR Reno

9. Goodput in presence of UDP Different Bottleneck Sizes 0 1 2 3 4 5 6 020406080100120140160 Goodput [Mb/s] Bottleneck bandwidth [Mb/s] FR Reno Sack

10. Wireless and Satellite Networks 0 200000 400000 600000 800000 1e+06 1.2e+06 1.4e+06 1e-101e-091e-081e-071e-061e-050.00010.001 goodput (bits/s) bit error rate (logscale) Tahoe Reno FR link capacity = 1.5 Mb/s - single “one-hop” connection

11. Experiment Environment New version of TCP FR called “TCP Westwood” TCP Westwood is implemented in Linux kernel 2.2.10. Link emulator can emulate: link delay loss event Sources share bottleneck through router to destination.

12. Goodput Comparison with Reno (Sack) Bottleneck capacity 5Mb Packet loss rate 0.01 Larger pipe size corresponds to longer delay Link delay 300ms Bottleneck bandwidth 5Mb Concurrent on-off UDP traffic

13. Friendliness with Reno Goodput comparison when TCP-W and Reno share the same bottleneck –over perfect link –5 Reno start first –5 west start after 5 seconds –100 ms link delay Goodput comparison when TCP-W and Reno share the same bottleneck –over lossy link(1%) –3 Reno start first then 2 Westwood –100 ms link delay TCP-W improves the performance over lossy link but does not catch the link.

14. Current Status & Open Issues Extended testing of TCP WEswoh Friendliness/greediness towards other TCP schemes Refinements of bandwidth estimation process Behavior with short-lived flows, and with large number of flows

15. Extra slides follow

16. Losses Caused by UDP Different RTT 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 00.10.20.30.40.50.60.70.80.91 Goodput [Mb/s] one-way RTT (s) FR Reno Sack

17. Losses Caused by UDP Differerent Number of Connections 0 1 2 3 4 5 6 7 8 9 10 11 051015202530 Goodput [Mb/s] no. of connections FR1 Reno Sack

18. TCP over Lossy links Different Bottleneck Size 0.1 1 10 020406080100120140160 Goodput [Mb/s] Bottleneck bandwidth [Mb/s] FR Reno Sack

19. Bursty traffic differerent number of connections 0 2 4 6 8 10 12 14 051015202530 Goodput [Mb/s] no. of connections FR Reno Sack

20. Fairness of TCP Westwood Cwnds of two TCP Westwood connections –over lossy link –concurrent UDP traffic –timeshifted –link delay 100ms Concurrent TCP-W connections goodput –5 connections (other2 are similar) –link delay 100ms.