[Iccrg] Congestion control definition and requirements of a new protocol

[louise.burness]

> -----Original Message-----
> From: iccrg-bounces at cs.ucl.ac.uk 
> [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of John Leslie
> Sent: 25 February 2006 01:52
> To: S. Keshav
> Cc: iccrg
> Subject: Re: [Iccrg] Congestion control definition and 
> requirements of a new protocol
> 
> 
> S. Keshav <keshav at uwaterloo.ca> wrote:
> > 
> > A. Definition of Congestion:
> > 
> > Network congestion is a state of degraded performance from the 
> > perspective of a particular user.
> 
>    This really won't do.
> 
>    We need to define something we can measure.
> 
>    And unless we measure something appreciably smaller than 
> what a user will notice, there's no hope of controlling 
> congestion very well.


Bob Briscoe did a definition of congestion of a resource and a path in
A.1 of
http://www.sigcomm.org/sigcomm2005/paper-BriJac.pdf


> 
> > B. Problems with TCP congestion control:
> > 
> > 1. In a high bandwidth-delay product environment, high throughputs
> >    can only be achieved if the packet loss rate is unrealistically 
> > low.
> 
>    Better to place this after #3, or even combine it with #3.
> 
> > 2. TCP has low throughput under lossy environments because it uses
> >    loss as an indication of congestion.
> 
>    The "problem" is that TCP uses packet loss as its only 
> measure of congestion. That TCP fails to fill a pipe in the 
> presence of any other packet loss is a result.
> 
> > 3. Due to additive increase, it takes a long time for a 
> flow to ramp up
> >    to transient increases in available capacity which results in
> >    unnecessarily long flow-completion times.
> 
>    This is correct, but could probably be better worded. The 
> problem is that additive increase prevents filling the pipe 
> when another flow stops. "Flow-completion times" may not give 
> the right connotations.

And we need to think about what we really want - AIMD was chosen (from
memory) because of the way it converged quite quickly to a stable and
fair state without any complex network management (at least compared to
other options), so its only a "problem" in certain circumstances.


> 
> > 4. Even when the flow is capable of completing within a 
> round-trip time,
> >    slow-start makes flows last multiple round-trip times 
> just to find
> >    their fair share rate. Many flows complete before they 
> exit slow-start
> >    phase.? ?
> 
>    I'm not sure any flow _is_ capable of completing within a 
> round-trip time. (There's a separate problem with saying 
> "fair-share rate", since the "stable" rate which flows 
> eventually reach isn't especially stable and is heavily 
> influenced by round-trip time, which many folks wouldn't see 
> as "fair".
> 
>    That many flows complete before finishing slow-start is a 
> real problem, and is well-stated.
> 
> > 5. TCP fills up all available buffers at the bottleneck links, which
> >    results in long latency.?
> 
>    Better to say that TCP must inflate latency before 
> generating the packet loss which will signal congestion. 
> (It's not necessarily true that "all available buffers" are 
> filled first.)
> 
> > 6. TCP  shares bandwidth inversely proportional to flow RTTs
> 
>    Better, I think, to say that TCP punishes long round-trip 
> times, causing users to perceive congestion more often than necessary.

I understood the origional point better

> 
> > 7. TCP builds a standing queue at the point of congestion, which
> >    increases the delay.
> 
>    This should be combined with #5. I'm not sure what words 
> we should add to make this point clear.

TCP deliberatly compromises delay in order to maximise overall
throughput. There are big buffers in the network to allow TCP to do
this. It deliberatly pushes the network to the edge of congestion as
this is the way to achieve maximum throughput (probable proviso on long
lived flows etc). TCP was designed to support long lived, delay
insenstive flows operating on links that had low delay-bandwidth
products and low non-congestive losses in a way that minimised
requirements on networks.

> 
> > -------
> > 
> > If we agree on this, (and if you do not, this is the time 
> to speak up) 
> > I would like to propose that we discuss the requirements of a new 
> > congestion control protocol, both theoretically and practically.
> > 
> > To start off this debate, I would like to state the following top 
> > level requirements.
> > 
> > First, given the definition of congestion, I argue that the 
> proposed 
> > protocol should allow two things: decoupling and observability.
> > 
> > - Decoupling means that the traffic from one user should not affect
> >   (or minimally affect) other users.
> 
>    This is clearly impossible. Perhaps you mean that when one 
> flow ramps up, other flows should not ramp down any more than 
> necessary to accomodate a proportional share of the increase.
> 
That's what TCP tries to do after all!

Decoupling is not impossible,you can do it with circuit switching

> > - Observability means that users should be able to observe 
> the network
> >   state in some fashion, so that they can control their 
> input so as to
> >   not cause overload and a consequent decrease in utility.

Again, you are restating what TCP already tries to do
> 
>    I'm not at all sure I understand. Do you mean that minimal 
> congestion should be reported to applications so that they 
> can choose alternative communication methods and/or paths 
> which are not congested?
> 
> > Second, in addition to these, the new mechanism should also 
> not suffer 
> > from the seven problems with TCP.
> 
>    I think, if we list problems, this should come first. But 
> if we state it this way (including by reference instead of 
> listing again the features to avoid), we need to word this 
> list more carefully. I'd prefer to restate -- I think it will 
> read more smoothly.
> 
> --
> John Leslie <john at jlc.net>
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>