[Iccrg] RE: Iccrg Digest, Vol 4, Issue 10
Fil Dickinson
Fil.Dickinson at optus.com.au
Sun Feb 26 21:58:24 GMT 2006
Hi,
I do not agree with the definition of congestion, but am glad that people are trying to tackle the issue. Although defing it is a challenge, coming up with a metric for measurement may be even harder.
I consider network congestion to be based on resource limits. That is to say
'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.'
Or in the syntax similar to that used
'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.'
The problem of measurement is much harder and interestingly, I don't specifically put this down to the problems of elastic versus inelastic as some have. To me it is difficult to measure because it is very much perception based and we are trying to describe it according to its impact upon a user. Were it elastic like file transfer the results of congestion are less obvious but perhaps more frustrating. The reason for this is people perceive an acceptable level of performance based on experience and expectation (and to some degree their own level of patience). If a file transfer experiences consistant congestion then the performance will be less than optimal, but the throughput consistant. Therefore they may perceive it slow or fast by comparison to another experience (or based upon their perceived urgency of completion). However, were it inelastic like VoIP, then the impacts of congestion to the end user would be obvious and we may be able to borrow from the work done on MOS in order to come up with a measure here for all flow types.
Fil Dickinson
-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of iccrg-request at cs.ucl.ac.uk
Sent: Saturday, 25 February 2006 10:56 PM
To: iccrg at cs.ucl.ac.uk
Subject: Iccrg Digest, Vol 4, Issue 10
Send Iccrg mailing list submissions to
iccrg at cs.ucl.ac.uk
To subscribe or unsubscribe via the World Wide Web, visit
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
or, via email, send a message with subject or body 'help' to
iccrg-request at cs.ucl.ac.uk
You can reach the person managing the list at
iccrg-owner at cs.ucl.ac.uk
When replying, please edit your Subject line so it is more specific than "Re: Contents of Iccrg digest..."
Today's Topics:
1. Congestion control definition and requirements of a new
protocol (S. Keshav)
2. Re: Congestion control definition and requirements of a new
protocol (John Leslie)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Feb 2006 17:34:58 -0500
From: "S. Keshav" <keshav at uwaterloo.ca>
Subject: [Iccrg] Congestion control definition and requirements of a
new protocol
To: iccrg <iccrg at cs.ucl.ac.uk>
Message-ID: <BAYC1-PASMTP12FCAD702A07C3E7DC96B4C0F30 at CEZ.ICE>
Content-Type: text/plain; charset="ISO-8859-1"
Folks,
Its been quiet on this list for a while. Can I take it as consensus on the following:
A. Definition of Congestion:
Network congestion is a state of degraded performance from the perspective of a particular user. A network is said to be congested from the perspective of a user if that user's utility has decreased due to an increase in network load.
B. Problems with TCP congestion control:
1. In a high bandwidth-delay product environment, high throughputs can only be achieved if the packet loss rate is unrealistically low.
2. TCP has low throughput under lossy environments because it uses loss as an indication of congestion.
3. Due to additive increase, it takes a long time for a flow to ramp up to transient increases in available capacity which results in unnecessarily long flow-completion times.
4. Even when the flow is capable of completing within a round-trip time, slow-start makes flows last multiple round-trip times just to find their fair share rate. Many flows complete before they exit slow-start phase.
5. TCP fills up all available buffers at the bottleneck links, which results in long latency.
6. TCP shares bandwidth inversely proportional to flow RTTs
7. TCP builds a standing queue at the point of congestion, which increases the delay.
-------
If we agree on this, (and if you do not, this is the time to speak up) I would like to propose that we discuss the requirements of a new congestion control protocol, both theoretically and practically.
To start off this debate, I would like to state the following top level requirements.
First, given the definition of congestion, I argue that the proposed protocol should allow two things: decoupling and observability.
0 Decoupling means that the traffic from one user should not affect (or minimally affect) other users.
0 Observability means that users should be able to observe the network state in some fashion, so that they can control their input so as to not cause overload and a consequent decrease in utility.
Second, in addition to these, the new mechanism should also not suffer from the seven problems with TCP.
Comments?
thanks
keshav
------------------------------
Message: 2
Date: Fri, 24 Feb 2006 20:51:38 -0500
From: John Leslie <john at jlc.net>
Subject: Re: [Iccrg] Congestion control definition and requirements of
a new protocol
To: "S. Keshav" <keshav at uwaterloo.ca>
Cc: iccrg <iccrg at cs.ucl.ac.uk>
Message-ID: <20060225015138.GN94025 at verdi>
Content-Type: text/plain; charset=us-ascii
S. Keshav <keshav at uwaterloo.ca> wrote:
>
> A. Definition of Congestion:
>
> Network congestion is a state of degraded performance from the
> perspective of a particular user.
This really won't do.
We need to define something we can measure.
And unless we measure something appreciably smaller than what a user will notice, there's no hope of controlling congestion very well.
> B. Problems with TCP congestion control:
>
> 1. In a high bandwidth-delay product environment, high throughputs
> can only be achieved if the packet loss rate is unrealistically low.
Better to place this after #3, or even combine it with #3.
> 2. TCP has low throughput under lossy environments because it uses
> loss as an indication of congestion.
The "problem" is that TCP uses packet loss as its only measure of congestion. That TCP fails to fill a pipe in the presence of any other packet loss is a result.
> 3. Due to additive increase, it takes a long time for a flow to ramp up
> to transient increases in available capacity which results in
> unnecessarily long flow-completion times.
This is correct, but could probably be better worded. The problem is that additive increase prevents filling the pipe when another flow stops.
"Flow-completion times" may not give the right connotations.
> 4. Even when the flow is capable of completing within a round-trip time,
> slow-start makes flows last multiple round-trip times just to find
> their fair share rate. Many flows complete before they exit slow-start
> phase.? ?
I'm not sure any flow _is_ capable of completing within a round-trip time. (There's a separate problem with saying "fair-share rate", since the "stable" rate which flows eventually reach isn't especially stable and is heavily influenced by round-trip time, which many folks wouldn't see as "fair".
That many flows complete before finishing slow-start is a real problem, and is well-stated.
> 5. TCP fills up all available buffers at the bottleneck links, which
> results in long latency.?
Better to say that TCP must inflate latency before generating the packet loss which will signal congestion. (It's not necessarily true that "all available buffers" are filled first.)
> 6. TCP shares bandwidth inversely proportional to flow RTTs
Better, I think, to say that TCP punishes long round-trip times, causing users to perceive congestion more often than necessary.
> 7. TCP builds a standing queue at the point of congestion, which
> increases the delay.
This should be combined with #5. I'm not sure what words we should add to make this point clear.
> -------
>
> If we agree on this, (and if you do not, this is the time to speak up)
> I would like to propose that we discuss the requirements of a new
> congestion control protocol, both theoretically and practically.
>
> To start off this debate, I would like to state the following top
> level requirements.
>
> First, given the definition of congestion, I argue that the proposed
> protocol should allow two things: decoupling and observability.
>
> - Decoupling means that the traffic from one user should not affect
> (or minimally affect) other users.
This is clearly impossible. Perhaps you mean that when one flow ramps up, other flows should not ramp down any more than necessary to accomodate a proportional share of the increase.
> - Observability means that users should be able to observe the network
> state in some fashion, so that they can control their input so as to
> not cause overload and a consequent decrease in utility.
I'm not at all sure I understand. Do you mean that minimal congestion should be reported to applications so that they can choose alternative communication methods and/or paths which are not congested?
> Second, in addition to these, the new mechanism should also not suffer
> from the seven problems with TCP.
I think, if we list problems, this should come first. But if we state it this way (including by reference instead of listing again the features to avoid), we need to word this list more carefully.
I'd prefer to restate -- I think it will read more smoothly.
--
John Leslie <john at jlc.net>
------------------------------
_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
End of Iccrg Digest, Vol 4, Issue 10
************************************
More information about the Iccrg
mailing list