[e2e] TCP un-friendly congestion control

[Lisong Xu]

Hello, Constantine:

Just went through your paper
(http://www.cc.gatech.edu/~dovrolis/Papers/sobas.pdf), very interesting. But
I have a question about it.  Maybe I misunderstood something.

By my understanding, as long as the S > C*T_m (that is, the sending rate is
greater than the bandwidth-delay product), sooner or later, we will get
packet losses, no matter how big the capacity of the buffer (B_t) is.

For example, in case 2 ( C*T_m < S <= C*T_m + B_t)  in the appendix,
since S is greater than C*T_M, so there is a backlog. In the paper, the
backlog is S-C*T_m. But this is not true.

After one RTT, the backlog Q is S-C*T_m. But after another RTT, the Q is
2*(S-C*T_m). then 3*(S-C*T_m), ....., and finally, we will get packet
losses.

Thanks,

Lisong


----- Original Message -----
From: "Constantine Dovrolis" <dovrolis at cc.gatech.edu>
To: "Craig Partridge" <craig at aland.bbn.com>
Cc: <end2end-interest at postel.org>; "Ravi Shanker Prasad"
<ravi at cc.gatech.edu>; "Manish Jain" <jain at cc.gatech.edu>
Sent: Saturday, June 07, 2003 3:23 PM
Subject: Re: [e2e] TCP un-friendly congestion control


>
> 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
> >
> >
>
>