TCP Westwood (with Faster Recovery)TCP Congestion ControlCongestion Window of a TCP Connection Over TimeShortcomings of current TCP congestion controlNew Proposal:TCP with “Faster Recovery”TCP FR: Algorithm OutlineExperimental ResultsFR/Reno ComparisonGoodput in presence of UDP Different Bottleneck SizesWireless and Satellite NetworksExperiment EnvironmentGoodput Comparison with Reno (Sack)Friendliness with RenoCurrent Status & Open IssuesExtra slides followLosses Caused by UDP Different RTTLosses Caused by UDP Differerent Number of ConnectionsTCP over Lossy links Different Bottleneck SizeBursty traffic differerent number of connectionsFairness of TCP WestwoodTCP Westwood (with Faster Recovery)Claudio Casetti ([email protected])Mario Gerla ([email protected])Scott Seongwook Lee ([email protected])Saverio Mascolo ([email protected])Medy Sanadidi ([email protected])Computer Science DepartmentUniversity of California, Los Angeles, USATCP 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)Congestion Window of a TCP Connection Over TimeShortcomings 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 bottleneckNew 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 thresholdTCP 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=1Experimental 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 linksFR/Reno Comparison00.020.040.060.080.10.120.140.160 100 200 300 400 500 600 700 800normalized throughputTime (sec)1 TCP + 1 On/Off UDP (ON=OFF=100s) 5 MB buffer - 1.2s RTT - 150 Mb/s Cap.FRRenoGoodput in presence of UDPDifferent Bottleneck Sizes01234560 20 40 60 80 100 120 140 160Goodput [Mb/s]Bottleneck bandwidth [Mb/s]FRRenoSackWireless and Satellite Networks02000 004000 006000 008000 001e+061.2e+061.4e+061e-10 1e-09 1e-08 1e-07 1e-06 1e-05 0.0001 0.001goodput (bits/s)bit error rate (logscale)TahoeRenoFRlink capacity = 1.5 Mb/s - single “one-hop” connectionExperiment EnvironmentR o u t e rS o u r c eL i n ke m u l a t o rD e s t i n a t i o nS o u r c e100M100M• 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.Goodput Comparison with Reno (Sack)goodput vs. pipesize01230.02 0.27 0.52 1.02 2.52 5.02pipesize(Mb)goodput(Mb/Sec)WestwoodReno withSack•Bottleneck capacity 5Mb•Packet loss rate 0.01•Larger pipe size corresponds to longer delaygoodput vs. loss rate00.510 0 0 0 0Packet Loss Rate goodput (Mb/Sec)WestwoodReno withSack•Link delay 300ms•Bottleneck bandwidth 5Mb•Concurrent on-off UDP trafficFriendliness 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.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 flowsExtra slides followLosses Caused by UDPDifferent RTT0.811.21.41.61.822.22.42.60 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Goodput [Mb/s]one-way RTT (s)FRRenoSackLosses Caused by UDPDiffererent Number of Connections012345678910110 5 10 15 20 25 30Goodput [Mb/s]no. of connectionsFR1RenoSackTCP over Lossy linksDifferent Bottleneck Size0.11100 20 40 60 80 100 120 140 160Goodput [Mb/s]Bottleneck bandwidth [Mb/s]FRRenoSackBursty trafficdiffererent number of connections024681012140 5 10 15 20 25 30Goodput [Mb/s]no. of connectionsFRRenoSackFairness 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