[Iccrg] Proposal for ICCRG operations

[Tom Petch]

----- Original Message -----
From: "Yong Xia" <xy12180 at gmail.com>
To: "S. Keshav" <keshav at uwaterloo.ca>; <iccrg at cs.ucl.ac.uk>
Cc: "Ion Stoica" <istoica at cs.berkeley.edu>; "Lakshminarayanan Subramanian"
<lakme at eecs.berkeley.edu>; "Yong Xia" <xy12180 at gmail.com>
Sent: Monday, February 06, 2006 5:19 AM
Subject: Re: [Iccrg] Proposal for ICCRG operations

> Hi Keshav,
>
> My two cents on the questions you raised:
>
> >>  A. What is the commonly agreed definition for congestion. (I will post
> my suggestion later today). If we do not agree on a definition, then indices
> are meaningless.
>
> Congestion happens when demand exceeds capacity. Queue and loss are the
> *outcome* of congestion, but not congestion itself.
>
> Therefore, in steady state, if there is congestion, queue builds and, up to
> a point, loss is resulted. If there is no congestion, there is no queue and
> no loss due to congestion. On the contrary, queue and loss do not
> necessarily mean congestion happens. There are other reasons that might
> cause queue or loss.
>
> At each link, if the aggregate incoming traffic rate is less than the
> link capacity, then there is no congestion on this link (in steady state).
> In a network, if there is no congestion on all the links, there is no
> congestion in this network.
>
Very much what I was going to get around to saying:-)  Going on from there, I
would say that congestion can occur whereever there is a limited resource;
links, yes, but buffers, cache, processor capacity etc

And while queue and loss may occur, so could delay, delay variation,
re-ordering, any kind of impairment.

As to impact, it depends on the nature of the traffic; what matters to VOIP may
not to file download and v.v.

The best scheme I have worked with was proprietary and many years ago now; it
measured the utilisation of the resource, factored in the traffic type and
generated explicit congestion control when appropriate.

I think that schemes that try to infer congestion from its consequences - eg
packet loss - should always be regarded as second best, even if that is all we
can do at the time.

Tom Petch

 <snip>
>
> Best,
> Yong
>
>