[e2e] TCP un-friendly congestion control

[Injong Rhee]

Hi.

It is my understanding that in the environments where these protocols
(HSTCP, Scalable TCP, and FAST) are intended to operate -- fast (>1Gbps)
and long distance networks (>50ms) -- TCP friendliness is not a concern
since TCP cannot fully utilize the available network bandwidth. These
protocols try to overcome this under-utilization problem of TCP.
However, if we try to apply this to the general Internet environments
(as it is noted in the announcement by CalTech), I think there could be
some TCP-fairness issues.

Just another note to these types of protocols:

These protocols (HSTCP and Scalable TCP, not sure about FAST since its
spec is not available) assume AQM with a sufficiently large buffer space
at the bottleneck routers. Under drop-tail or small buffer situations,
they cannot guarantee fairness (Scalable TCP) or exhibit very slow
convergence to fairness (HSTCP) even among the flows of their own type.
I am working on a paper on this now. Will make it available soon.

The common assumption that these protocols make is that the networks are
fairly asynchronous causing more loss events for flows with larger
bandwidth shares; therefore, more aggressive MIMD CC would guarantee
fairness to their own flows. I am not sure whether this assumption can
still hold even when the buffer space is not as much as the bandwidth
and delay product. From what I hear from router manufacturers such as
cisco and juniper, the buffer space on the high speed routers in long
distance networks that span over continents (which might show RTT of 100
- 200 ms) could be less than 10-20% of B x D --  in fact, Tom Kelly
reports this lack of buffer space in his techreport. It says that the
connection between CERN, Geneva and Chicago (over 2.4Gbps and 120ms RTT)
can provide at most 9% of B x D. Under this environments, the high-speed
traffic causes a high degree of synchrony, forcing the networks to
behave like drop-tail, at least to the high bandwidth flows. 


Injong Rhee
Computer Science Dept
North Carolina State Univ.
rhee at csc.ncsu.edu
http://www.csc.ncsu.edu/faculty/rhee



-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org] On Behalf Of Tom Kelly
Sent: Friday, June 06, 2003 4:57 AM
To: Michael Welzl
Cc: end2end-interest at postel.org
Subject: Re: [e2e] TCP un-friendly congestion control

Hi,

This is a long email so the quick links are:
http://www.icir.org/floyd/hstcp.html
http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
http://www-control.eng.cam.ac.uk/gv/internet/TR398.pdf

> Now I won't claim to understand all the maths behind Steven Low's
> work either - but, as far as I understood it, it does at least
> require one midpoint modification: active queue management.
> I think that's how stability is ensured.

I might be bold enough to claim that I do understand some of the control

theory behind Steven Low's work. Those interested in wanting to 
understand some control theory relating to networks should read Glenn 
Vinnicombe's clean and concise result on stability of TCP like flow 
controls:
http://www-control.eng.cam.ac.uk/gv/internet/TR398.pdf
Beginners to control theory should get a book on undergraduate control 
and then read the Nyquist stability reference in the above paper. 

As for FAST, it is difficult to comment on an unpublished algorithm.  
Note that publicised is different to published. So to the best of what
can
be inferred, FAST appears to be TCP Vegas with some new parameters and
tweaks that attempt to solve the problems of TCP congestion control in
highspeed wide area networks.

Another approach to improving TCP performance in highspeed wide area
networks is Highspeed TCP by Sally Floyd. See the internet draft at:
http://www.icir.org/floyd/hstcp.html

I have made refinements to Sally's proposal in my Scalable TCP proposal
which adds freely available source code implementation for Linux and
experimental results from a testbed. Scalable TCP is essentially a
parameter setting of Highspeed TCP which makes IMHO a lot of sense from

the scalability, stability, implementation, and evolvability
standpoints.
All of these are available from:
http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
It was interesting to discover that with the hardware/OS setup we had
half 
the problems were with the OS and driver. The net100 project kernel 
instrumentation tools aim to help get a handle on this:
http://www.net100.org/

> I wonder if it's possible to create a TCP-like mechanism that
> would be stable (assuming a fluid model) with no tailored
> active queue management  ... in particular, I wonder if this
> could be shown in the heterogeneous RTT case.

This is a question that has had considerable research effort put in by 
many in the community. I think the answer to this question is yes and
see 
the maths in Glenn's paper above if you want to engineer your own. 

Hope that helps,
Tom