[Iccrg] Proposal for ICCRG operations

[Michael Welzl]

> 2. Several of us have already started discussions on congestion control
> indices, and modifications to these indices, and so on. I think this is
> jumping the gun. I think it would be better to focus first on two issues:

Indeed, what my mail clearly showed right away is that it isn't
an easy task to find an index that we can all live with. On the
one hand, such an index is supposed to simplify things, while
on the other, there will always be somebody who thinks that
parameters x and y should be part of it. In accordance with your
very reasonable request, I hope that we can stop (or perhaps
postpone) this discussion; as I mentioned in the original mail,
I didn't really hope that this would lead to some consensus - all
I wanted is to provide "food for thought". It's nice to see that
there is some agreement that such an index would be a good thing
to have, though, so I'd be glad if we could get back to it at
some later stage.


>     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.

Here's what I decided to write about this issue in my book:


Now that we know the origin and some of the technical implications of
congestion, let us find a way to describe it. There is no `official',
universally accepted definition of network congestion; this being said, the
most elaborate attempt was probably made in (Keshav 1991a). Here is a slightly
simplified form of this definition, which acknowledges that the truly important
aspect of network performance is not some technical parameter but user
experience:

A network is said to be congested from the perspective of a user if the
service quality noticed by the user decreases due to an increase in network
load.

(Keshav 1991a) is your ph.d. thesis, of course.


>     B. What's wrong with TCP's congestion control scheme. Does someone have
> a concise summary that they can post here? I am sure this will be a
> cut-and-paste job for someone who has written a paper on congestion control
> recently :-)

That's a hard one - especially the "concise" part. There are many things that
could be said for and against the way TCP works today - on the one hand, I tend
to agree with what has just been said by others about TCP first creating
congestion in order to undo it afterwards. On the other, the strength about
both TCP and IP is the general applicability of these protocols, so when we say
"this is wrong about TCP", we should immediately ask ourselves "would TCP work
at least as good as today in any (future) environment we can think of if we
were to change this?".

In the light of these requirements, I would at least hesitate to say "yes, we
need it to take delay as a congestion measure" ... perhaps, but maybe not, if
we think of link layer ARQ etc.

By the way, I couldn't come up with a scenario where HighSpeed TCP would NOT
work at least as good as TCP works today... so considering the change that was
done for this protocol might be a starting point.


> Lets see if we can reach consensus on these two issues in a week's time.
> These will also form parts 1 and 2 of the consensus document. I ask for your
> co-operation in keeping the discussion to these two issues.

Okay!

Cheers,
Michael