[Iccrg] Re: Iccrg Digest, Vol 4, Issue 12
Arjuna Sathiaseelan
arjuna.sathiaseelan at gmail.com
Tue Feb 28 09:27:28 GMT 2006
I am not sure if I am making sense here...can we take delay into
consideration when defining congestion? Say for eg a Bandwidth on
Demand return link such as a DVB-RCS system could take different
delays from 300 ms to 1300 ms - making the overall RTT varying (even
though the forward link delay is constant). So this does not
necessarily mean the network is congested, right?
> 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.'
Regds,
Arjuna
On 2/28/06, iccrg-request at cs.ucl.ac.uk <iccrg-request at cs.ucl.ac.uk> wrote:
> 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. Definition of Congestion (John Leslie)
> 2. Re: Congestion control definition and requirements of a new
> protocol (Filipe Abrantes)
> 3. Re: Congestion control definition and requirements of a new
> protocol (Saverio Mascolo)
> 4. RE: Definition of Congestion (Fil Dickinson)
> 5. Re: Congestion control definition and requirements of a new
> protocol (Tim Shepard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Feb 2006 08:08:01 -0500
> From: John Leslie <john at jlc.net>
> Subject: [Iccrg] Definition of Congestion
> To: Dado Colussi <gdc at iki.fi>
> Cc: iccrg <iccrg at cs.ucl.ac.uk>, Fil Dickinson
> <Fil.Dickinson at optus.com.au>
> Message-ID: <20060227130801.GP94025 at verdi>
> Content-Type: text/plain; charset=us-ascii
>
> 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.
>
> > 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.
>
> 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.
>
> > 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).
>
> 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.)
>
> > 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.
>
> (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 come from the old school, which states that the intelligence
> should be at the edges with the center as simple as possible.
>
> 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...
>
> --
> John Leslie <john at jlc.net>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 27 Feb 2006 13:24:19 +0000
> From: Filipe Abrantes <fla at inescporto.pt>
> Subject: Re: [Iccrg] Congestion control definition and requirements of
> a new protocol
> To: "S. Keshav" <keshav at uwaterloo.ca>
> Cc: iccrg at cs.ucl.ac.uk
> Message-ID: <4402FD83.5080300 at inescporto.pt>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> (see below)
>
> S. Keshav wrote:
> > 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.
> >
>
> Probably combinable with #3. The "limited range of operation" is a term
> I have already seen before and I think it applies the best.
>
> > 2. TCP has low throughput under lossy environments because it uses loss as
> > an indication of congestion.
> >
> Because most of the wireless media have automatic repeat request (ARQ)
> mechanisms, transmission errors result in doubling (or multiplying for
> some other factor) the delay of that wireless hop in question. So, using
> loss in such media is probably ok, unlike rtt measurements.
>
> > 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.
> Combinable with #7 isn't it?
>
> >
> > 6. TCP shares bandwidth inversely proportional to flow RTTs
> >
> Agreed.
>
> > 7. TCP builds a standing queue at the point of congestion, which increases
> > the delay.
>
>
> I would like to add:
> 8.
> TCP's resultant throughput is unstable, which is inadequate for some
> applications (media apps).
>
>
> > -------
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > Iccrg mailing list
> > Iccrg at cs.ucl.ac.uk
> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> >
>
> --
> Filipe Lameiro Abrantes
> INESC Porto
> Campus da FEUP
> Rua Dr. Roberto Frias, 378
> 4200-465 Porto
> Portugal
>
> Phone: +351 22 209 4266
> E-mail: fla at inescporto.pt
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 27 Feb 2006 19:53:25 +0100
> From: Saverio Mascolo <mascolo at poliba.it>
> Subject: Re: [Iccrg] Congestion control definition and requirements of
> a new protocol
> To: keshav <keshav at uwaterloo.ca>, iccrg <iccrg at cs.ucl.ac.uk>
> Message-ID: <003301c63bcf$1c83b320$703bccc1 at yourf1911fedb6>
> Content-Type: text/plain; charset="iso-8859-1"
>
> hi,
>
> you say: " 1. In a high bandwidth-delay product environment, high throughputs can only
> be achieved if the packet loss rate is unrealistically low."
>
> does anyone know what it is a realistic packet loss rate not due to congestion in gigabit nets?
>
> Saverio
>
>
>
> On 2/24/06, S. Keshav <keshav at uwaterloo.ca> wrote:
> 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
>
>
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060227/eb6d8eaf/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Tue, 28 Feb 2006 09:18:51 +1100
> From: Fil Dickinson <Fil.Dickinson at optus.com.au>
> Subject: [Iccrg] RE: Definition of Congestion
> To: John Leslie <john at jlc.net>, Dado Colussi <gdc at iki.fi>
> Cc: iccrg <iccrg at cs.ucl.ac.uk>
> Message-ID:
> <799B0CDA650143429C5EA103965B59F801A66CC7 at shqw2ke001.optus.com.au>
> Content-Type: text/plain; charset=us-ascii
>
> 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>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 28 Feb 2006 00:36:33 -0500
> From: Tim Shepard <shep at alum.mit.edu>
> Subject: Re: [Iccrg] Congestion control definition and requirements of
> a new protocol
> To: John Leslie <john at jlc.net>
> Cc: iccrg <iccrg at cs.ucl.ac.uk>
> Message-ID: <E1FDxXF-0004kq-00 at alva.home>
>
>
> > > 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.
>
> The way I think about it, it is the standing queues. And those are
> measurable.
>
> I think if we get rid of the standing queues (by controlling
> transmissions into the net, not by dropping packets until the
> standing queue goes away), we will have accomplished the first half
> of what we want to accomplish towards a new and improved congestion
> control scheme.
>
> (One scenario I like to keep in mind is a single TCP transmitting data
> over a path, with no other significant traffic in the net. This
> single TCP will build a standing queue in front of the bottleneck,
> increasing delay (for itself, which probably does not matter, and for
> the other "insignificant" traffic, which might matter).)
>
>
> The other half of what we want to accomplish would involve fairness,
> the ability to do traffic engineering, et cetera.
>
>
> > > 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.)
>
> [....]
>
> > > 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.
>
> Yes, with #7, #5 is redundant. So perhaps we can delete #5 and just
> have #7?
>
> -Tim Shepard
> shep at alum.mit.edu
>
>
>
> ------------------------------
>
> _______________________________________________
> 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 12
> ************************************
>
More information about the Iccrg
mailing list