[Fwd: Re: [Iccrg] Congestion control definition and requirements of anew protocol]

[louise.burness]

In-line again, with pruning

> -----Original Message-----
> From: iccrg-bounces at cs.ucl.ac.uk 
> [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Ferenc Kubinszky
> Sent: 01 March 2006 11:48
> To: S. Keshav; iccrg
> Cc: Gabor Nemeth
> Subject: [Fwd: Re: [Iccrg] Congestion control definition and 
> requirements of anew protocol]
> 
> 
> Hi,
> 
> Please find my comments inline.
> 
> 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.
> 
> What does it mean "user's utility has decreased"? Is it an 
> absolute or relative measure? It might be important to 
> distinguish if the source of 
> the increase is the user itself.
> 
> By this definition the network is congested if a user uses 
> the whole capacity of a given link, and an other user will 
> start a flow. Is it really a congestion? This case the 
> network should be congested every time...
> 

I still like the idea of defining congestion caused by a packet at a
single resource as the probability that an event {another packet
lost/marked/delayed beyond specification} if the packet is added to the
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.
> > 
> I agree with this. However new TCPs, like highspeed, 
> scalable, BIC do ~10x better than e.g. reno. But this is a 
> strict constraint for high speed networks.
> 
> > 2. TCP has low throughput under lossy environments because it uses 
> > loss as an indication of congestion.
> 
> Sure. In some networks loss isn't the best congestin 
> detection source. But TCP should somehow know about the 
> congested state of the network (whatever it is). There are 
> other possible measures, like RTT changes, packet inter 
> arrival times etc.

These implicit schemes seem to prove very difficult to implement in
practise - for example all the measures you suggest are affected by the
type of ARQ scheme that the particular wireless link utilises. Explicit
notification is required

 A new congestion control mechanism should 
> combine these wisely. But the problem still remain, namely 
> that the source of these measures is not strictly the 
> congestion. Consider that the packet loss on a link or 
> network mostly convertible to
>    delay (or delay variation, if you wish), and vica versa.
> 
> > > > 
> > 
> > 
> > _______________________________________________
> > Iccrg mailing list
> > Iccrg at cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>