[Iccrg] Proposal for ICCRG operations
nwnetworks at dial.pipex.com
Mon Feb 6 15:55:44 GMT 2006
----- 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.
More information about the Iccrg