150 likes | 164 Vues
This research paper from Caltech Infocom discusses the effectiveness of a delay-based approach in managing congestion in TCP networks compared to loss-based approaches. It explores the advantages of delay-based methods, such as earlier congestion detection and more frequent feedback. The study compares this approach with previous methods and emphasizes the importance of inter-protocol and intra-protocol fairness. The paper highlights the need for continued evaluation and experimentation to ensure the practicality and effectiveness of delay-based congestion control in real-world scenarios.
E N D
Fast TCP Cheng Jin David Wei Steven Low Caltech Infocom, March 2004 Offense Team: Santa & 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
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
(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
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?
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
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
Evaluation Flaws • Wrong comparison choices • Incomplete evaluation
Intra-Protocol Fairness • 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
Intra-Protocol Fairness Contd. Maintaining intra-protocol fairness when some of the connections have large propagation delay is difficult. • GlobalFairness of Additive-Increase and Multiplicative-Decrease With Heterogeneous Round-Trip Times. Infocom 2000 FAST-TCP fails here, but TCP Vegas was shown to successful.
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.
Are you afraid to hit the roads ? • Are conclusions based on dummynet experiments sufficient ? • ns simulation, WAN emulation, real deployment
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
TCP-Vegas • Expected Rate = Curr wind Size / Min RTT • Actual Rate = Bytes sent during RTT / Current RTT • Diff (Expected – Actual) should remain within limits