Subject: [conex] Missing concept from conex-concepts-uses ?

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Mar 2011 18:51:05 +0000

John, Toby,

Altho we're co-authors, I thought I would straight off open this 
thought up to the whole list, as the w-g owns this doc.

I just started re-reading the draft with my "Mr Skeptical" hat on. In 
other words, I put myself in a devil's advocate frame of mind where I 
start off hating it and have to be convinced.

I immediately noticed it doesn't start from "What's the problem with 
over-provisioning?"

Also, I just did a presentation to L2/L3 colleagues which started 
with why congestion is not strongly related to utilisation, and they 
all found it really difficult to 'get it'. This seems to be a cause 
of confusion for people coming from non-transport backgrounds.  I 
think I've worked out how to explain it (John, I know this is one of 
your bug-bears too).

Do you agree it would be useful to have a brief discussion of these 
issues near the start?

I can propose some text, if you want.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Mar 2011 15:47:15 -0400

> I immediately noticed it doesn't start from "What's the problem with 

   (It does at least mention _a_ problem with over-provisioning...)

> Do you agree it would be useful to have a brief discussion of these 

   Speaking for myself, yes.

> I can propose some text, if you want.

   By all means, send text!

--
John Leslie <[email-masked]>

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 25 Mar 2011 09:03:59 -0400

Hi,

I also read over the use case and abstract mechanism drafts yesterday and
agree with Bob and John that the motivation could be better stated. The
description of the congestion problem(s) to be solved and some definitions
of various views of congestion from the reference [Bauer09] may help
provide the motivation which could be better stated in the wg draft.

The following three quotes from sections 3.3 and 3.4 of [Bauer09] capture
the essence of what I believe is a significant motivational factor for (at
least some) service providers:

"Network operators tend to adopt another definition of congestion. They
define
"congestion" in terms of the load on a network over a particular period of
time. (See
Figure 4.) Ask a network operator how "congested" part of their network
is, and they will respond with the average utilization of a link over some
period of time. This period of time is typically on the order of minutes
or longer."

Snipped

"From the MIT Dictionary of Modern Economics23:
"When an increase in the use of a facility or service which is used by a
number of people would impose a cost (not necessarily a monetary cost) on
the existing users, that facility is said to be Œcongested'."

Snipped

"Is this economic definition of congestion close to the network operators'
definition based
upon usage levels? The answer to this depends upon how one interprets the
size of the
increase in load needed to cause the delays or drops and the time period
in which this
increase has to occur. If one believes that traffic might increase by 25%
in the next six
months and the network is currently at 80% utilization then a network
might be deemed
congested now since the projected increase will assuredly cause delays or
drops over that
longer duration time period.25

25 There might also be an opportunity cost born by a network operator if
the network is loaded to a level that precludes them from accepting or
attracting new subscribers. Thus, a network might be perceived to be
"congested" if it is near the point where additional traffic would trigger
a business decision to deploy additional capacity. Historically, some
network operators adopted a rule-of-thumb that additional capacity would
be deployed if the average link utilization during the busy period of the
day exceeded 50% of the link capacity."

Editorially, the essence of these quotes could be paraphrased more
succinctly, attribution given to [Bauer09] and merged with the text at the
bottom of page 3 in the Introduction of the use case wg draft. (I also
propose aligning the time frame in the second sentence of the paragraph at
the bottom of page 3 to be "months to years" as stated in [Bauer09, p.6]
instead of a "few months" as stated in the current text. Also, the
reference to Moore's law in that paragraph seems unnecessary.)

Editorially, I suggest including the URL to this paper in the References
section of the wg draft:

http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf

Thanks,

Dave

On 3/23/11 3:47 PM, "John Leslie" <[email-masked]> wrote:

   By all means, send text!

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

---

From: John Leslie <[email-masked]>
Date: Fri, 25 Mar 2011 12:02:55 -0400

> least some) service providers:

   Actually Bauer_Clark-Lehr_2009 gives four definitions of interest:

Queueing theory definition:
" In queuing theory, traffic congestion is said to occur if the arrival
" rate into a system exceeds the service rate of the system at a point
" in time.

Textbook definition:
" Congestion of a network router is said to occur if packets are dropped,
" The buildup of packets in a queue is instead described as contention.

Network Operator's definiton:
" Ask a network operator how congested part of their network is and they
" will respond with the average utilization of a link over some period of
" time.

Economic definition:
" When an increase in the use of a facility or service which is used by
" a number of people would impose a cost (not necessarily a monetary
" cost) on the existing users, that facility is said to be congested.

   IMHO, it might be good to include all four before we try to state our
own definition, simply because congestion _does_ mean so many different
things to different observers, and the casual reader is likely to assume
our definition is "vague" due to carelessness. ;^)

> succinctly,

   I think they're succinct enough (as I quoted them above).

> attribution given to [Bauer09] and merged with the text at the
> bottom of page 3 in the Introduction of the use case wg draft.

   Toby has the pen...

> (I also propose aligning the time frame in the second sentence of the
> paragraph at the bottom of page 3 to be "months to years" as stated in
> [Bauer09, p.6] instead of a "few months" as stated in the current text.

   Again, Toby has the pen; but I would dissent: "years" is simply too
long of a time period in the world of Internet (even if some operators
_do_ maintain multi-year upgrade plans).

> Also, the reference to Moore's law in that paragraph seems unnecessary.)

   Toby has the pen... (but I consider the sentence following that one
to be important.)

> http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf

   Toby has the pen...

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Mar 2011 16:19:42 +0000

John,

The important point to make is not just that we have chosen a 
definition, but the reason we have chosen it:

We combine the economic definition with the definition at queuing 
timescales because incentives at these timescales can be extremely 
effective in altering the behaviour of computers that can respond 
that quickly (as TCP does).

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Mar 2011 16:56:39 +0000

John,

>    (It does at least mention _a_ problem with over-provisioning...)

We need to more than mention it. We need to be clear what we want to 
say about it...

Over-provisioning is a fantastic illustration that the problem ConEx 
solves is not only a problem of excess congestion.

For instance, a major motivation of ConEx is to solve the problem 
where an operator over-provisions as the only way to offer decent 
quality. This is an excessive cost problem, not an excessive 
congestion problem.

So, as I keep saying, ConEx is solving an information problem, not a 
congestion problem. It's about revealing whether packets contribute 
or *not* to congestion.

0.00000000000% congestion is a signal, not a problem.

Then other systems can focus on congestion-causing packets *and* 
ignore non-congestion-causing packets. So users don't have to always 
be limited unnecessarily, just because the operator can't be sure 
what to limit.

The problem starts when we set the tone of the introduction by saying 
the problem is excessive congestion, which implies ConEx will (only) 
solve excessive congestion (as in para 1). Then in order to justify 
having started like this, we have to focus on all the negative 
aspects, rather than being able to balance positive and negative and 
shout about the positive.

Bob