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

[Filipe Abrantes]

Hi,

(see below)

S. Keshav wrote:
> Folks, 
>     Its been quiet on this list for a while. Can I take it as consensus on
> the following:
> 
> A. Definition of Congestion:
> 
> Network congestion is a state of degraded performance from the perspective
> of a particular user. A network is said to be congested from the perspective
> of a user if that user's utility has decreased due to an increase in network
> load. 
> 
> 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.
> 

Probably combinable with #3. The "limited range of operation" is a term 
I have already seen before and I think it applies the best.

> 2. TCP has low throughput under lossy environments because it uses loss as
> an indication of congestion.
> 
Because most of the wireless media have automatic repeat request (ARQ) 
mechanisms, transmission errors result in doubling (or multiplying for 
some other factor) the delay of that wireless hop in question. So, using 
loss in such media is probably ok, unlike rtt measurements.

> 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.
> 
> 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.   
> 
> 5. TCP fills up all available buffers at the bottleneck links, which results
> in long latency. 
Combinable with #7 isn't it?

> 
> 6. TCP  shares bandwidth inversely proportional to flow RTTs
> 
Agreed.

> 7. TCP builds a standing queue at the point of congestion, which increases
> the delay. 


I would like to add:
8.
TCP's resultant throughput is unstable, which is inadequate for some 
applications (media apps).


> -------
> 
> 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.
> 
>     0 Decoupling means that the traffic from one user should not affect (or
> minimally affect) other users.
>     0 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.
> 
> Second, in addition to these, the new mechanism should also not suffer from
> the seven problems with TCP.
> 
> Comments?
> 
> thanks
> 
> keshav
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

-- 
Filipe Lameiro Abrantes
INESC Porto
Campus da FEUP
Rua Dr. Roberto Frias, 378
4200-465 Porto
Portugal

Phone: +351 22 209 4266
E-mail: fla at inescporto.pt