[Iccrg] RE: Definition of Congestion

[Fil Dickinson]

Hi John and Dado. I am responding to both your valued comments in this
one mail. By the way, I found them very enlightening.


>-----Original Message-----
>From: John Leslie [mailto:john at jlc.net] 
>Sent: Tuesday, 28 February 2006 12:08 AM
>To: Dado Colussi
>Cc: Fil Dickinson; iccrg
>Subject: Definition of Congestion
>
>Dado Colussi <gdc at iki.fi> wrote:
>> Fil Dickinson wrote:
>> 
>>> 'Network congestion is a state where there are insufficient
resources 
>>> in a network for a flow that result in excessive delay. This in turn

>>>results in the flow failing to meet minimum effective performance.'
>
>   I read Fil to be saying that "congestion" exists when information
flow is delayed beyond the requirements for effective use of the
network.

Here I was saying that congestion exists when the available resources
for a flow across a network drop below the minimum required for
effective use. These resources may be bandwidth, queues, packet buffers,
processor etc. They may not be reliability, transmission delay, problems
associated with path diversity, routing, reachabilty etc.

>
>> If we consider Keshav's utilities mathematically, we probably see 
>> functions u: X -> Y where X is a set of resource bundles and Y is
some 
>> set with order property. Keshav says that a source experiences 
>> congestion if u(x1) > u(x2) where x1 and x2 are user's resource 
>> bundles before and after an increase in network load. I find this 
>> definition quite elegant and expressive.
>

This expalination is simple and elegant. I agree with this explaination
with one exception and that is load. The network load may stay the same
however the nature of the different flows may change, thus expiring the
available resources for say a certain packet size and rate. The result
will be congestion for those flows that are now resource constrained. In
turn the users will see this as degraded performance.

>   It indeed is true that it is technically possible that an increase
in network load could _increase_ a user's perceived utility.
>
>   More obviously, it is true that different users will have different
utility functions, and some will perceive degradation in the same set of
resource bundles where others do not.

I agree.

>
>> The insufficient resources you suggest are all those resource bundles

>> that don't result in maximum utility when the utility is sensitive to

>> excessive delay (or throughput, as in your second definiton).

Yes, that is a fair understanding in light of Keshev's utilities.

>
>   I assume Dado is referring to:
>]
>] 'Network congestion is a state that occurs when a network element in
] a path reaches a resource limit. A network is said to be congested ]
from the perspective of a user if that user's minimum effective ]
throughput has decreased due to a limit being attained.'
>
>which I read to say that whenever a user's experience is degraded, the
network is by definition "congested". (This does not strike me as a
useful definition.)

Sorry to be confusing but that was not my intended meaning. I was trying
to say that congestion is one of a number of states. There are others
such as loss and transmission delay that may degrede a users
performance. I was not saying that any degradation experienced by a user
is due to congestion.

>
>> However, utility functions differ per application and even per user 
>> basis and are not limited to excessive delay only (or throughput
only).
>
>   I quite agree.

I also agree. The utilities are limited by a number of factors including
other states such as reliability/loss and delay variance.

>
>   (Which is why I prefer to work on things we can measure...)
>
>> Furthermore, the Internet exists for its users and it's more
important 
>> to adjust it for the users than for mere existence. That's why I
think 
>> a user-centric approach is well justified.

I agree that the Internet is for it's users and think a user centric
approach is honourable. I see it as the more complex approach however
and that it will require very tight interpretation of the group "users".
For example I would not want to contribute to engineering the Internet
for "users" whose applications are written in such a way as to make poor
use of the Internet or in fact abuse of the Internet.

>
>   I come from the old school, which states that the intelligence
should be at the edges with the center as simple as possible.

I come from the same school [and may have borrowed the same books from
the library;-)].

>
>   This is not necessarily at odds with Dado and/or Fil: congestion
management has traditionally been an edge function; and anything they
want to try at the edges is fine with me.
>
>   My approach to <iccrg> is that it appears that we may have made the
"backbone" _too_ simple, and I'd like to work on identifying points of
overload and seeing if we can "route around them".
>
>   (Also, the "backbone" _will_ need to protect itself against
excessive loading, possibly by discarding types of traffic which seem to
be failing to apply appropriate congestion management: there are
questions worth studying in how to distinguish this.)
>
>> You're right about the problem of measurement. I think it would be 
>> essential to discuss u, X and Y. If we knew them, u and X in 
>> particular, we would be in a better position to decide what tradeoffs

>> to make in suggesting a framework for measurement. It's not feasible 
>> to find utility functions for each application and user but I do
think 
>> it would be feasible to find a sufficiently expressive classification

>> that would enable us to justify the tradeoffs. I'm not suggesting it 
>> would be easy though.
>
>   I do think it's clear that there's no single utility function. It
may be possible to identify a useful set of functions -- which brings up
the question of how to tell which function to use...
>

I agree with you both on your comments above.

>--
>John Leslie <john at jlc.net>