[e2e] TCP un-friendly congestion control

[Constantine Dovrolis]

taking Craig's last point one step further: many people
argue today that TCP cannot saturate network paths with
a high bandwidth-delay product, and that a new version
of TCP (or a new transport protocol) is needed.
That may not be necessarily true however.

We recently designed a socket buffer sizing technique
that aims to drive a bulk TCP transfer to its maximum
feasible throughput. The basic idea is that if the socket
buffer size is appropriately limited, the connection
can saturate its path but without causing network buffer
overflows and subsequent window reductions. An important point
about this technique is that it does not require any
changes in TCP; all the work is done at the application-layer,
through socket buffer sizing, receive-rate measurements,
and out-of-band RTT measurements. The technique (called
SOBAS) does not also require any prior knowledge
of the path's bandwidth/buffering characteristics.

If you're interested in the whole story, the paper is
available at:

http://www.cc.gatech.edu/~dovrolis/Papers/sobas.pdf

Random losses, i.e., losses that can occur independent
of our connection's window, are still a problem.
One way to deal with them, assuming again that we can't
change TCP, is to use a few parallel TCP connections.
This may not be strictly-speaking "TCP friendly",
but it is a pragmatic approach to avoid large
window reductions upon the occurence of random losses.


Constantinos

--------------------------------------------------------------
Constantinos Dovrolis | 218 GCATT | 404-385-4205
Assistant Professor | Networking and Telecommunications Group
College of Computing | Georgia Institute of Technology
dovrolis at cc.gatech.edu
http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/

On Fri, 6 Jun 2003, Craig Partridge wrote:

> OK, let me get on my high horse here for a moment.
>
> The original poster asserted that in an environment where the network
> went at 1 Gbps and had 50ms of delay, TCP was hopeless.
>
> The point I was trying to drive home is that it is not hopeless.  That
> you have to define the environment far more carefully before you assert
> that TCP can or cannot do the job.  One of my frustrations these days is
> people who fail to be careful.  I was trying to encourage care in the
> problem statement.
>
> Thanks!
>
> Craig
>
>