[Iccrg] Proposal for ICCRG operations

[Saverio Mascolo]

On Mon, 2006-02-06 at 10:55 -0500, Tim Shepard wrote:
> > On Sat, 2006-02-04 at 15:56 -0500, John Leslie wrote:
> > > Tim Shepard <shep at alum.mit.edu> wrote:
> > > > To: "S. Keshav" <keshav at uwaterloo.ca>
> > > > 
> > > >> What's wrong with TCP's congestion control scheme
> > > > 
> > > > The problem with TCP's congestion control scheme is that it builds a
> > > > standing queue at the point of congestion, which increases the delay.
> > > 
> > >    I'd go farther than than: the fundamental problem with TCP's
> > > congestion control scheme is that it never measures congestion.
> > > 
> > >    That said, I agree with Tim that building a queue (of unknown length)
> > > at the point of congestion is not very smart congestion control.
> > > 
> > > > A better congestion control scheme would control the queue length,
> > > > with a target of zero (or very few) packets, thereby minimizing the
> > > > impact on delay.
> > 
> > by targetting a queue level of few packets we  have that each flow gets
> > a constant fraction of the buffer space. In a FIFO queue this translates
> > in the same fraction of used bandwdith.
> 
> Why is that?
> 
> I don't think that is necessarily true.  It may be true for some kinds
> of control schemes, but it is not necessarily true for all kinds of
> control schemes.

let assume  that you have a buffer of 10 packets and two connections: A
and B. Let assume that target queue is 6 packets for flow A and  4 for
flow  B. Then flow A would get 6/10-th of the bandwdith and B 4/10-th.

i have read somewhere, maybe on s. floud homepage, a note on "why
control queue length should not be a target". i am not sure, but i think
she had  similar arguments.

in other words, if you control queue at fixed value you would prevent
other flows to join.

-s