[Iccrg] Comments on definitions of congestion

S. Keshav keshav at uwaterloo.ca
Tue Feb 7 00:29:52 GMT 2006


I am commenting on the mail from the last couple of days on the definition
of congestion. As my previous mail from today shows, I believe it should be
user-centric and using the notion of utility.

keshav
-----

1. Nandita Dukkipati writes:
* A network-centric definition of congestion: Congestion is anything that
deviates significantly from an efficient and fair usage of the network
resources --- mostly network bandwidth and buffers.
* User-centric definition: From an user's view point what really matters is
how quickly does my flow finish, so congestion is long flow-completion
times. Often, it isn't the per-packet latency that users care about, but
just how fast the entire flow completes.
---
I am not sure there a network-centric definition makes any sense! A network
is for its users, not a thing-in-itself. If users are satisfied, then the
network is working, otherwise it is a not-work :-)

A user-centric definition that only takes flow completion times is
meaningless for voice traffic.

----
2. John Leslie writes:
   To me, congestion is the condition where a packet can't be sent
"immediately" (meaning perhaps that it can't be queued as the next
packet to be sent).

   Clearly, many if not most Internet applications are perfectly happy
with some time in the queue; and it is arguable that some "smallish" time
in queue should be called "uncongested".

   I do not agree, however, that a definition of "congestion" should
be based on packets actually being dropped.

--
You seem to imply that congestion happens any time the arrival rate exceeds
the service rate. However, this ignores the ability of buffers to rate-match
and smooth over transients. If a small buffer allows transient overloads and
this happens 'under the radar' from the perspective of a user, why would you
call the network congested?

----
3. Kewin Stoeckigt writes:
I understand congestion
as some sort of "sudden interruption"...that means, at one point,
packets are delayed (higher delay than usual/expected), dropped, etc.
However, if the delay = constant (without packet loss), I wouldn't call
this necessarily congestion.
---
You imply that congestion is associated with a sudden interruption. This is
somewhat imprecise. Do you mean the variance in the interarrival times at
the receiver goes beyond a threshold? If so, what is a universally
agreed-upon threshold?

---
4. Michael Welzl writes:
There is no `official',
universally accepted definition of network congestion; this being said, the
most elaborate attempt was probably made in (Keshav 1991a).
--
Thanks for the reference, Michael! You made my day :-)

----
5. Damon Wischik writes:
...congestion should be measured by (A) drop probability,
which seriously impacts flows that last only one or two packets, by sending
them into timeout; and (B) queueing delay, which hurts real-time traffic;
and (C) correlation of losses, since bursts of loss also hurt real-time
traffic; and (D) inability to accomodate a reasonable volume of very short
non-responsive transactions (I hesitate now to call them "flows" when
they're really just "impulses").
---
I guess this is answering the question: How should we measure congestion?
rather than What is congestion. Please see my thesis excerpt on why I think
this measure the effects of congestion, rather than what is congestion.

----
6. Yong Xia writes:
Congestion happens when demand exceeds capacity.
 
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. 
---- 
This has the same problem as John Leslie's definition, i.e. it ignores the
effect of buffers.

---
7. Tom Petch writes:
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.

---
Exactly, and that is why congestion needs to be defined from a user
perspective.

---






More information about the Iccrg mailing list