Subject: [conex] What's the problem: excessive congestion or capacity sharing?

From: Bob Briscoe <[email-masked]>
Date: Mon, 12 Jul 2010 02:29:42 +0100

ConEx list,

In trying to write draft-moncaster-conex-concepts-uses, the 
co-authors need wider consensus from the list on how best to 
characterise the problem we are trying to solve.

* One view says the problem should be characterised as excessive congestion.
* Another view says the problem is lack of a good metric for sharing capacity.

The link between the two is that capacity sharing only becomes an 
issue during congestion, but the latter view says congestion doesn't 
have to be excessive for there to still be a capacity sharing problem.

Thoughts anyone?

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Zhu Lei <[email-masked]>
Date: Mon, 12 Jul 2010 09:51:22 +0800

My view is that the TCP does not know if the earlier congestion or capacity
lack would impact the usage of application. It can impact in some cases.
Those earlier congestion is better to be considered in the scope.

Best regards,
Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Bob
Briscoe
发送时间: 2010年7月12日 9:30
收件人: [email-masked]
主题: [conex] What's the problem: excessive congestion or capacity sharing?

ConEx list,

In trying to write draft-moncaster-conex-concepts-uses, the co-authors need
wider consensus from the list on how best to characterise the problem we are
trying to solve.

* One view says the problem should be characterised as excessive congestion.
* Another view says the problem is lack of a good metric for sharing
capacity.

The link between the two is that capacity sharing only becomes an issue
during congestion, but the latter view says congestion doesn't have to be
excessive for there to still be a capacity sharing problem.

Thoughts anyone?

Bob

_______________________________________________
conex mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/conex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Jul 2010 10:16:43 +0200

mmm, i am not sure why excessive congestion as opposed to simply congestion?
If we rephrase this removing the excessive, it results only in 
congestion, which doesn't seem to be very descriptive.

OTOH, the concept of an alternative metric seems to match more my 
current understanding.
So without further context of the discussion, i would go for the second.

Regards, marcelo

El 12/07/10 3:29, Bob Briscoe escribió:
> ConEx list,
>
> In trying to write draft-moncaster-conex-concepts-uses, the co-authors 
> need wider consensus from the list on how best to characterise the 
> problem we are trying to solve.
>

---

From: Matthew Ford <[email-masked]>
Date: Mon, 12 Jul 2010 09:36:20 +0100

I agree with Marcelo. 'Excessive' is a pretty nebulous qualifier. Congestion will come and go at various timescales depending on competing traffic, upgrades, new paths becoming available etc. It's the new metric that is interesting.

Mat

On 12 Jul 2010, at 09:16, marcelo bagnulo braun wrote:

> If we rephrase this removing the excessive, it results only in congestion, which doesn't seem to be very descriptive.
> 
> OTOH, the concept of an alternative metric seems to match more my current understanding.
>> In trying to write draft-moncaster-conex-concepts-uses, the co-authors need wider consensus from the list on how best to characterise the problem we are trying to solve.
>> 
>> The link between the two is that capacity sharing only becomes an issue during congestion, but the latter view says congestion doesn't have to be excessive for there to still be a capacity sharing problem.
>> 
>> Thoughts anyone?
>> 
>> 
>> Bob
>> 
>>

---

From: João Taveira Araújo <[email-masked]>
Date: Mon, 12 Jul 2010 09:43:58 +0100

Hi Bob,

> * Another view says the problem is lack of a good metric for sharing capacity.

I'd argue option B, simply because "excessive congestion" is an entirely subjective assessment which most network operators will staunchly deny. In part, this may be because they can't see it, but more likely than not a combination of other factors (over-provisioning, TCP's inability to adapt to large pipes fast enough, ...)  means congestion is relatively low.

It's also terribly confusing to advocate congestion is a *good thing* as a by-product of fast and efficient transport on one hand, and on the other complain there is excessive congestion.

I think it would be a lot easier to argue for conex on the basis that where and when this contention does arise, congestion exposure provides the best metric to mediate between sources.

Cheers,
Joao

---

From: John Leslie <[email-masked]>
Date: Mon, 12 Jul 2010 04:56:05 -0400

marcelo bagnulo braun <[email-masked]> wrote:
> El 12/07/10 3:29, Bob Briscoe escribi?:
>>

   Indeed, Bob and I have been exchanging heated emails. He wants to
rewrite the Abstract and Introduction. I don't.

>> * Another view says the problem is lack of a good metric for sharing 

   I think Bob wants to remove all language about "managing congestion"
and replace it with language about "sharing capacity".

   I have some problems with that, because I prefer the dumb network
to the telco model. I would like to emphasize the need to justify
upgrades rather than worry about how the network decides which traffic
deserves priority.

   I also (so far) fail to get as crisp an idea of what Bob means for
the network to do under his "sharing capacity" paradigm.

   In any case, we are up against a posting deadline; and I have
suggested to Bob that we work this out on the ConEx list _after_
the posting deadline.

   Poor Toby has to get _something_ out today!

>> have to be excessive for there to still be a capacity sharing problem.

   I don't actually agree with Bob that there are no capacity-sharing
issues outside times of congestion. (Or perhaps I misunderstand Bob:
is he saying that capacity-sharing is a problem only when there's
congestion, or isn't he?)

> mmm, i am not sure why excessive congestion as opposed to simply

   The language in Toby's current draft is quite close to what was
posted to this list in the -00 draft. I may have missed a case of
"excessive congestion", but I don't offhand remember that term being
used.

   Of course, I believe all the authors agree that some congestion
is at least "normal" if not indeed "essential" to the operation of
the Internet. Bob has a fixation, AFAICT, that if "congestion"
causes problems, it must be "excessive congestion" that's causing
the problems. I, OTOH, don't agree that congestion has to be
"excessive" for it to cause problems, it's merely that those problems
become more serious as congestion increases.

> congestion, which doesn't seem to be very descriptive.

   I have argued in ICCRG that we need to be more careful what we
mean when we say "congestion". We have tried to move in that direction
in defining "congestion" in this draft.

> OTOH, the concept of an alternative metric seems to match more my 

   I don't quite get what you are saying here.

> So without further context of the discussion, i would go for the second.

   Does that mean you recommend Toby accomplish that rewrite today?

--
John Leslie <[email-masked]>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Jul 2010 11:10:05 +0200

El 12/07/10 10:56, John Leslie escribió:
> marcelo bagnulo braun<[email-masked]>  wrote:
>    
it would seem odd to me that a document that describes the use cases for 
exposing congestion doesn't talk about congestion and only talks about 
sharing capacity.

snip

> become more serious as congestion increases.
guessing, i would understand that excessive congestion would mean that 
the overall throughput of the network start to severely decline due to 
retransimissions, and that could be characterized as excessive 
congestion (as opposed to normal losses that keep TCP under control)

In that context, i think that exposing congestion is not only useful 
during excessive congestion, but also a mean to share the available 
resources.

>     I don't quite get what you are saying here.

I mean that exposing e2e congestion to the network is a mean to measure 
the service that the end host is receiving from the network, so i can 
see the metric as being one apsect where the use case should cover

>     Does that mean you recommend Toby accomplish that rewrite today?
no, it is only my opinion on the questions Bob asked to the ml

Regards, marcelo

> --
> John Leslie<[email-masked]>
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 12 Jul 2010 10:22:41 +0100

Hi Bob,

On Jul 12, 2010, at 2:29 AM, Bob Briscoe wrote:

> ConEx list,
>
> In trying to write draft-moncaster-conex-concepts-uses, the co- 
> authors need wider consensus from the list on how best to  

Those two things don't seem quite comparable to me. If the question is,

"what metric is that we cannot currently measure?"

And the answer choices are

* congestion volume, or
* impact on shared capacity

If you think your metric is useful even in times of no congestion  
(however the relevant operator wants to define those times), call it  
impact on shared capacity. If you think your metric is only useful in  
times of congestion, call it congestion volume.

Alissa

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 12 Jul 2010 10:37:28 +0100

OK, Marcelo got in before me... one inline

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of marcelo bagnulo braun
> Sent: 12 July 2010 10:10
> To: John Leslie
> Cc: [email-masked]
> Subject: Re: [conex] What's the problem: excessive congestion or
> capacity sharing?
> 
> authors

Yes, that is exactly the meaning I have in mind when I say "Excessive
Congestion". Perhaps it would be better to talk about "detrimental levels of
congestion" or some such...

Cicero (apparently) said "Never go to excess, but let moderation be your
guide.” Congestion is a good example. If there is no congestion then TCP,
etc have no signal to work with. If there is excessive congestion you get
potential collapse, or at least a significant reduction in utility. And when
congestion is measured by ECN it is pre-empting any damage to capacity
through loss. I am sure Bob could come in here with some good stuff about
the shape of the ECN marking curve...

Anyway, back to re-working the draft for today's deadline...

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 12 Jul 2010 06:36:56 -0400

Hi Bob,

I believe there are a number of use case categories, and you list two at
a very high level. Below is my interpretation of your two scenarios:

- "Excessive Congestion" Other posts have questioned the definition of
"excessive." One definition is the case where queuing delays and
possibly loss occur for (at least) packets with a QoS class with offered
load greater than the configured serving bandwidth/queuing. 

- "Sharing capacity" is quite general and could imply a number of
"sharing" scenarios along some metric for fairness (not sure if this is
what you meant).

IMO, there is at least two other categories which are very important,
and may be a partial answer to the question regarding the definition of
"shared capacity" posed by John Leslie. 

- Feedback on usage as related to subscription parameters: In some
access networks (e.g., wireless) there are charges based upon usage
volume. Charging may also vary by time of day and day of week. Feedback
indicating whether a customer is approaching or has crossed into a new
usage tier is quite important. A method more real time than a customer
receiving a large bill at the end of the month is definitely an
operational problem today.

- Feedback on usage as related to historical usage and current usage
state: Also, in other networks there are periods of peak usage and
periods where there is spare capacity, and this may be charged for at a
lesser rate than peak period. However, the off-peak periods are also
times when service providers perform maintenance, so even though there
is normally spare capacity in the middle of the night, if a failure
occurs during a maintenance window then congestion may result and
feedback to achieve good throughput during such a condition is
desirable. This type of feedback could be used by ledbat style
applications. 

Thanks,

Dave

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bob Briscoe
> Sent: Sunday, July 11, 2010 9:30 PM
> To: [email-masked]
> Subject: [conex] What's the problem: excessive congestion or 
> capacitysharing?
> 
> ConEx list,
> 
> The link between the two is that capacity sharing only 
> becomes an issue during congestion, but the latter view says 
> congestion doesn't have to be excessive for there to still be 
> a capacity sharing problem.
> 
> Thoughts anyone?
> 
> 
> Bob
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 12 Jul 2010 17:33:35 +0100

Alissa,

The distinction I was trying to make was between ultimate problems we 
might solve with exposed congestion (ConEx).

Are we:
- exposing congestion in order ultimately to reduce congestion?
- exposing congestion in order to share capacity better?

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 12 Jul 2010 17:49:11 +0100

Marcelo,

At 10:10 12/07/2010, marcelo bagnulo braun wrote:
>>[JL]    I think Bob wants to remove all language about "managing congestion"
>[MB] it would seem odd to me that a document 
>that describes the use cases for exposing 
>congestion doesn't talk about congestion and only talks about sharing capacity.

[BB] I didn't mean that. I meant we should talk 
about using congestion exposure in order to share 
capacity better (by the deterrent of policing 
based on ConEx and/or voluntary changes to 
transports because congestion-volume minimisation 
becomes the goal of transport design).

I agree with John that the other goal of reducing 
congestion will be realised as a side-effect of 
sharing capacity based on congestion-volume. I 
just think we shouldn't make this the main 
subject, because it is harder to explain this 
emergent property of better capacity sharing - it 
requires us to use economics to explain why less 
'free-riding' by some will reduce congestion for everyone.

>>>[MB] mmm, i am not sure why excessive congestion as opposed to simply
>>>congestion?
>>>
>>[JL]    The language in Toby's current draft is quite close to what was

[BB] I agree with that - 'excessive' was my bad paraphrasing of your position.

>>[JL]    Does that mean you recommend Toby accomplish that rewrite today?
>>
>>
>[MB] no, it is only my opinion on the questions Bob asked to the ml

[BB] The statement of the problem that we are 
arguing over is in the abstract and intro. It 
doesn't affect the rest of the doc.

So it could go out like it is now, but ideally, 
if the ML agrees it should be changed, we would 
want to change it for either tonight or the next rev.

Cheers

Bob

---

From: ken carlberg <[email-masked]>
Date: Mon, 12 Jul 2010 13:23:02 -0400

> - exposing congestion in order to share capacity better?

Does it have to be either/or?  could we start with reducing congestion as the default position, and also have providers be a bit more proactive with their management skills, and therefore help distinguish themselves from their competitors?  

-ken

---

From: Jason Livingood <[email-masked]>
Date: Mon, 12 Jul 2010 16:27:35 -0400

On 7/12/10 1:23 PM, "ken carlberg" <[email-masked]> wrote:

> Does it have to be either/or?  could we start with reducing congestion as the
> default position, and also have providers be a bit more proactive with their
> management skills, and therefore help distinguish themselves from their
> competitors?  

Continuing with Ken's line of thinking, I'd not restrict this now.  Exposing
congestion data could do a number of interesting things, which may include
both of the above.  Also I fear that focusing too much on this will make
this into some sort of philosophical debate concerning the business model
and regulatory positions, which will simply cause us to get stuck and not
address the important technical work.

Jason

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 13 Jul 2010 00:03:29 +0100

Jason,

It's just a question of how we start the ConEx use-cases doc. We have 
to say something succinct about what problem we are trying to solve. 
So we can't just shlve the question for later.

Bob

---

From: Kevin Mason <[email-masked]>
Date: Tue, 13 Jul 2010 22:22:22 +1200

May i suggest that what we are addressing is enhancing capacity sharing under overload.
 
When the volume of traffic offered to the next hop excedes that available capacity the link becomes overloaded. This work is about providing the network with the means to better manage how available capacity is shared by taking action at points on a path other than just at an overloaded next hop, and to signal more effciently to end users and the network preceding the overload point that the path this traffic is using is overloading and if action is not taken excessive congestion will result.
 
Kevin 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bob Briscoe [[email-masked]]
Sent: Tuesday, 13 July 2010 11:03 a.m.
To: Jason Livingood
Cc: [email-masked]
Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing?

Jason,

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 13 Jul 2010 17:02:05 +0100

Toby, John, Rich (co-authors of use-cases I-D),

To me, Kevin's text would be a good basis for introductory text to 
summarise the set of problems that the use-cases are about (e.g. for 
the abstract & Introduction).

Bob

At 11:22 13/07/2010, Kevin Mason wrote:
>When the volume of traffic offered to the next hop excedes that 
>available capacity the link becomes overloaded. This work is about 
>providing the network with the means to better manage how available 
>capacity is shared by taking action at points on a path other than 
>just at an overloaded next hop, and to signal more effciently to end 
>users and the network preceding the overload point that the path 
>this traffic is using is overloading and if action is not taken 
>excessive congestion will result.
>
>Kevin
>
>

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 14 Jul 2010 09:51:37 +0100

I am not convinced this captures everything. It is fine as far as it goes,
but I would prefer to insert something and phrase it more like:

"When the volume of traffic offered to the next hop excedes that available
capacity the link becomes overloaded. This is known as congestion. ConEx is
about providing the network with the means to monitor the state of
congestion throughout the path. This allows networks to better manage how
available capacity is shared by taking action at points on a path other than
just at an overloaded next hop. They can signal to the network preceding the
overload point that the path this traffic is using is overloading and if
action is not taken excessive congestion will result."

I have carefully removed mention of end-users since they already see
congestion information, and as they are the origin of the ConEx information
they are actually the ones doing the signalling. I also feel ConEx is more
about providing the signal which can then be used to encourage upstream
networks and the sender to respond better.

Oh, and I may steal that first sentence and use it to improve the current
definition of congestion in the draft.

This may also re-spark the discussion of "excessive congestion" ;-)

Toby

> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 13 July 2010 17:02
> To: Toby Moncaster; John Leslie; Woundy, Richard
> Cc: [email-masked]; Kevin Mason
> Subject: RE: [conex] What's the problem: excessive congestion or
> capacity sharing?
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 14 Jul 2010 14:55:54 +0100

Toby,

At 09:51 14/07/2010, Toby Moncaster wrote:
>capacity the link becomes overloaded. ..."
>

How about adding two words:

"When the volume of traffic offered to the next hop excedes its available
capacity, however temporarily, the link is said to be congested. ..."

This helps addresses that class of people John L identified who think 
(congestion = high average utilisation).

Bob

---

From: John Leslie <[email-masked]>
Date: Wed, 14 Jul 2010 10:21:46 -0400

> capacity, however temporarily, the link is said to be congested. ..."

   I don't have a problem with such language as part of the definition.
I'm uneasy with putting it outside the Definitions section, and actually
unhappy putting such language _before_ the Definitions section.

   (This is not to say I'd object to removing language in the Introduction
which might seem to say something else.)

> (congestion = high average utilisation).

   I think it's important to start the Definitions section with a crisp
definition of "congestion" which makes it clear we're talking something
which is transient -- in the usual case, at least.

   I don't want anything in the Introduction which might be read as a
competing definition.