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

[John Leslie]

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.

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

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

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

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

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

   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>