Fast TCP Cheng JinDavid WeiSteven Low Caltech Infocom, March 2004 Offense Team: Santa & Animesh

Comp 629, Spring 2004Santa & Animesh Delay-based Approach In general, Equation-based approach is needed for steady-state and high utilization Congestion measure – delay, loss, … We agree with the argument : Delay-based approach is better than loss-based approach Multi-bit information compared to one-bit Earlier detection of impending congestion More frequent feedback possible

Comp 629, Spring 2004Santa & Animesh Is the approach novel? NO. Delay-based approaches have been proposed for the last 15 years Including their earlier paper last year Half the theory of this paper is a copy of their earlier paper, IEEE CCW 2000

Comp 629, Spring 2004Santa & Animesh (Just) A few Prior Art Raj jain, A Delay-based approach for congestion avoidance in interconnected heterogeneous computer network. ACM Sigcomm, ‘89 Martin, Nilsson and Rhee, Delay-based congestion avoidance for TCP, IEEE ToN, June 2003 Sisalem and Schulzrinne, The Loss-Delay Adjustment Algorithm: A TCP friendly adaptation Scheme. NOSSDAV, ‘98 Rejaie, Handley, Estrin, RAP:An end-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet. Infocom ‘99 Floyd et. al., Equation based congestion control for unicast applications. Sigcomm ’00 Brakmo and Peterson, TCP Vegas: end-to-end congestion avoidance on a global internet. IEEE JSAC, Oct 1995 Choe and Low, Stabilized Vegas. Infocom ‘03

Comp 629, Spring 2004Santa & Animesh Comparison with WHAT ??? Compared their approach to 3 other loss- based approaches. Why not delay-based approaches Other approaches? Particularly, TCP-Vegas Explicit Congestion Notification (ECN) Sneaking suspicion: Did they actually compare, and was on the losing side?

Comp 629, Spring 2004Santa & Animesh Inter-Protocol Fairness All transport protocols should be TCP friendly for compatible with a deployed standard TCP-friendliness – Maintaining arrival rate to at most some constant over the square root of the packet loss rate No claim for TCP-friendliness in this paper

Comp 629, Spring 2004Santa & Animesh TCP-Friendly

Comp 629, Spring 2004Santa & Animesh Deployment Issues A proposal should have incremental deployment characteristic. Lot of excellent proposals have not seen the day of light because of this Examples: TCP-Vegas, SACK, Multicast So, just yet another paper…read & forget

Comp 629, Spring 2004Santa & Animesh Evaluation Flaws Wrong comparison choices Incomplete evaluation

Comp 629, Spring 2004Santa & Animesh Intra-Protocol Fairness - Showed better fairness index but themselves claim it not being 1. - Compare against HSTCP, STCP which were protocols optimized for high throughput and not fairness - Why not compare against TCP WestWood and Easy RED or TCP-Vegas ? TCP WestWood and Easy RED to improve Fairness in high speed networks. PfHSN’02

Comp 629, Spring 2004Santa & Animesh Intra-Protocol Fairness Contd. Maintaining intra-protocol fairness when some of the connections have large propagation delay is difficult. Global Fairness of Additive-Increase and Multiplicative-Decrease With Heterogeneous Round- Trip Times. Infocom 2000 FAST-TCP fails here, but TCP Vegas was shown to successful.

Comp 629, Spring 2004Santa & Animesh Inter-Protocol Fairness TCP Vegas paper clearly demonstrates their effectiveness in being TCP friendly using : When Reno competes with Vegas, Vegas’s flow does not throttle Reno. Also the total retransmissions drops when Reno competes with Vegas as compared to Reno against Vegas. Background traffics’s throughput increased by 20% when Reno is competing with Vegas as compared to Reno competing with itself.

Comp 629, Spring 2004Santa & Animesh Are you afraid to hit the roads ? Are conclusions based on dummynet experiments sufficient ? ns simulation, WAN emulation, real deployment

Comp 629, Spring 2004Santa & Animesh Conclusion Theoretically sound in advocating Delay Based approaches But this is prior work Did not convince me why FAST TCP is the choice as compared to other delay based approaches. Weak and Incomplete Evaluation Fairness issues is questionable Wrong comparison choices Experimental with realistic scenarios necessary

Comp 629, Spring 2004Santa & Animesh TCP-Vegas Expected Rate = Curr wind Size / Min RTT Actual Rate = Bytes sent during RTT / Current RTT Diff (Expected – Actual) should remain within limits