[e2e] TCP un-friendly congestion control

[Constantine Dovrolis]

Lisong, thanks for reading the paper.

The important point here is that, when S>C*T_m, the queue
in the tight link is building up, which means that the
Round-Trip Time of our connection increases as well. In
other words, the "effective RTT" of the transfer increases
beyond T_m when the transfer's window becomes larger
than C*T_m. Also, the connection can only send one window
worth of data per effective RTT, not per T_m. It is also
important to realize that the socket buffer size S imposes an
upper bound on how large the transfer's send window
can become.

Please let me know if this is still not clear.

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 Sat, 7 Jun 2003, Lisong Xu wrote:

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