You are on page 1of 15

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
Santa & Animesh

Comp 629, Spring 2004

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 2004

Santa & 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
Santa & Animesh

Comp 629, Spring 2004

Comparison with WHAT ???

Compared their approach to 3 other lossbased approaches.

Why not delay-based approaches Particularly, TCP-Vegas Explicit Congestion Notification (ECN)

Other approaches?

Sneaking suspicion: Did they actually compare, and was on the losing side?
Santa & Animesh

Comp 629, Spring 2004

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 2004

Santa & Animesh

TCP-Friendly

Comp 629, Spring 2004

Santa & 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 paperread & forget
Santa & Animesh

Comp 629, Spring 2004

Evaluation Flaws

Wrong comparison choices

Incomplete evaluation

Comp 629, Spring 2004

Santa & Animesh

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. PfHSN02
Santa & Animesh

Comp 629, Spring 2004

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 RoundTrip Times. Infocom 2000

FAST-TCP fails here, but TCP Vegas was shown to successful.


Comp 629, Spring 2004 Santa & Animesh

Inter-Protocol Fairness

TCP Vegas paper clearly demonstrates their effectiveness in being TCP friendly using :

When Reno competes with Vegas, Vegass flow does not throttle Reno. Also the total retransmissions drops when Reno competes with Vegas as compared to Reno against Vegas. Background trafficss throughput increased by 20% when Reno is competing with Vegas as compared to Reno competing with itself.
Santa & Animesh

Comp 629, Spring 2004

Are you afraid to hit the roads ?

Are conclusions based on dummynet experiments sufficient ?

ns simulation, WAN emulation, real deployment

Comp 629, Spring 2004

Santa & 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
Santa & Animesh

Comp 629, Spring 2004

TCP-Vegas

Expected Rate = Curr wind Size / Min RTT Actual Rate = Bytes sent during RTT / Current RTT Diff (Expected Actual) should remain within limits

Comp 629, Spring 2004

Santa & Animesh

You might also like