Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 4 Apr 2011 08:07:13 -0400

As I mentioned in the status presentation last Thursday, I planned to send
a paragraph to the conex wg list with proposed text for an additional
paragraph to be placed at the end of section 5.1.

I am responding to point 1 Alissas' Email on this subject, since I think
her note summarizes wg consensus on this topic well. (Also note that this
closely aligns with the text cited from the reference [Bauer09]).

The remainder of section 6 relating to this topic would be removed, with
discussion required to determine whether the wg sees value in keeping
section 6.2 (possibly in an Appendix), or removing that as well. The
formulation of this approach by Toby helped me better understand conex,
but if that is not wg consensus, then so be it.

"Traffic measurements over time scales longer than that of
policers/shapers involving conex information can be used to adjust the
token bucket parameters of these policers and adjust parameters of
shapers. These longer time scale conex related measurements can also
provide other uses [Bauer09, pg.18-19], such as; achieve better
understanding user traffic requirements, provide a better basis for
planning investments, enable better service customization, or achieve
better matching of costs and usage. When measurement is done in a network
element that implements a shaper, the amount which self congestion
contributes to overall congestion may be estimated for similar uses. These
traffic management techniques employing conex information may help address
the challenging problem where a small percentage of users (e.g., 20%)
generate a large portion of the traffic (e.g., 80%) [Varian09]. "

Also, based upon some misunderstanding of terminology that was apparent on
the list, I propose that the RFC 2475 definition of "shaper" be added to
section 3.1, existing approaches.

Thanks,

Dave

On Friday3/25/11 4:37 AM, "Alissa Cooper" <[email-masked]> wrote:

>In my reading of section 6, it presents 2 distinct issues:
>
>1) Long time scales: A use case (or perhaps a few variations on the
>same use case) for the conex signal as currently described in abstract-
>mech, wherein conex helps network operators to manage congestion,
>conduct traffic shaping, and capacity-plan over periods much longer
>than network speeds (e.g., minutes/hours/days/months)
>
>2) Shaper presence: A suggestion that conex could signal the presence
>of a traffic shaper (in addition to or instead of how the conex signal
>is currently described in abstract-mech) and a use case for such a
>signal wherein recipients of the signal can use it to request that
>sender's traffic shaper parameters be altered
>
>I think the issue of long time scales, which is described in the
>introductory text to section 6 and briefly in 6.1 and 6.2, could
>instead be succinctly addressed by adding a couple of sentences to 5.1
>to explain that the use of conex for managing "heavy" users could
>occur over shorter or longer time scales and could have the added
>affect of helping operators to do longer-term capacity planning.
>
>Signaling the presence of a shaper seems to me to be a separate animal
>altogether, and one over which there is some obvious disagreement. But
>at least half of section 6 seems to be devoted to the idea that
>operators would have uses for aggregating conex information over long
>time frames, and I think those uses could be incorporated with a brief
>addition to section 5.1.
>
>Alissa
>
>On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote:
>
>> Hi Nandita,
>>
>> A few responses to your questions on the new section in line below
>> prefixed by DM which were previously posted to the list that I
>> believe (at least partially) address your comments.
>>
>> I propose that the working group work toward how to organize/merge/
>> move the new text better into the existing outline.
>>
>> Thanks,
>>
>> Dave
>>
>> From: Nandita Dukkipati <[email-masked]>
>> Date: Thu, 17 Mar 2011 03:28:25 -0400
>> To: Toby Moncaster <[email-masked]>, John Leslie <[email-masked]>,
>> Bob Briscoe <[email-masked]>, "Woundy, Richard"
>><[email-masked]
>> >, David McDysan <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>> Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01
>>
>> On reading the latest draft, I have three high level comments
>> roughly in the following order of importance-
>>
>> ***
>> Statistical Multiplexing over different timescales.
>> This reads like a rambling story. I have read and re-read it, and I
>> am still left wondering -
>> * What is _the_ main point? How about starting the section by
>> stating your main point upfront as opposed leaving it to the reader
>> to figure it out.
>>
>> DM - From my 3/10/11 on the list
>>
>> 1) A few "heavy" users generate most of the traffic and service
>> providers
>> want to better assign the cost (of provisioning an upgrade) for the
>> time
>> when congestion is anticipated to occur. Existing mechanisms, flat
>> rate,
>> bandwidth tier shapers, and usage tiers do not completely address the
>> service provider objective and/or are not popular with users.
>>
>> 2) In some service provider networks shapers are implemented to
>> limit the
>> maximum bandwidth per user. Although overflow or marking in the shaper
>> queue appears as congestion to the receiver,  this "self-congestion"
>> differs from congestion of a shared resource since a remedy could be
>> to
>> indicate to the user that changing the shaper rate (i.e., "go faster")
>> would alleviate "self-congestion."
>>
>> * Why and how is this use case distinct from that of traffic
>> management which already seems to have a broad scope? Is it really
>> distinct?
>>
>> DM - From my 3/11/11 post to the list
>>
>> Editorially, this (section 5.1) could be a place to state the
>> problem with an additional
>> reference to [Varian].
>>
>> Editorially, bandwidth tier pricing could be added to section 3.1,
>> Existing approaches.
>>
>> I am now thinking that editorially a separate section is not a good
>> idea,
>> since the points can be merged into the existing outline, in at
>> least the
>> places mentioned above.
>>
>> I think adding that the use case needs to meet service provider
>> economic
>> congestion needs as well as be acceptable to users is an important
>> point
>> not in the current text. Traffic management (aka policing) may have
>> the
>> problem that it may not be popular with user. There has already been
>> negative feedback on the list regarding policing (IMO, Traffic
>> management
>> is a better term).
>>
>>
>> * [minor] Why not make this use case a part of Sec. 5?
>>
>> DM  the minutes recorded adding the agreement to add this as a new
>> section. (A new subsection, and or merging thoughts with other use
>> cases (e.g., as suggested above) is what I believe the wg needs to
>> discuss.
>>
>> ***
>> Partial versus full deployment.
>> Clearly, it belongs to this draft. But why is it a part of use
>> cases? Looks out of place to me.
>>
>> ***
>> Sec 4. Exposing congestion.
>> ³We argue that congestion needs.... More specifically, a network
>> needs to be able to measure how much congestion any particular
>> traffic expects to cause between the monitoring point in the network
>> and the destination ("rest-of-path congestion"). This would be a new
>> capability.²
>>
>> Could you add more clarity and explanation on why local congestion
>> information at any given node is not sufficient. Why does a node
>> require congestion information from a monitoring point to the
>> destination to be able to manage its own congestion? A succinct
>> explanation and/or an example will go a long way.
>>
>> _______________________________________________
>> conex mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/conex
>
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 6 Apr 2011 00:39:48 +0200

Hi Dave,

thx, I really like your text proposal. I guess the term 'self congestion' 
needs to be defined as well...? But otherwise this text make the use case 
very clear to me!

Mirja

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 6 Apr 2011 09:56:33 -0400

Hi Mirja,

Thank you for the feedback.

A definition of "self congestion" was added to section 1 of use-cases-01
as follows:

   Congestion takes two distinct forms.  The first results from the
   interaction of traffic from one set of users with traffic from other
   users, causing in a reduction in service (a cost) for all of them.
   the second, often referred to as "self-congestion", occurs when an
   increase in traffic from a single user causes that user to suffer a
   worse service (for instance because their traffic is being "shaped"
   by their ISP, or because they have an excessively large buffer in
   their home router).  ConEx is principally interested in the first
   form of congestion since it involves informing those other users of
   the impact you expect to have on them.

Editorially, possibly the description of these terms should be in
definitions, but as I mentioned in Prague this was new text that the wg
should review.

Thanks,

Dave

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 06 Apr 2011 22:16:18 +0100

David,

I had meant to say earlier that I don't think 
self-congestion is a good term for this concept. 
The words self-congestion suggest your own 
activity is congesting yourself, which might mean 
you are overloading your own DSL line, or your own home network.

When your own actions have taken you out of 
contract with a policy enforcing device which is 
discarding your traffic, that is not congestion 
so congestion is a bad word to use for it. And 
the discards are only indirectly caused by the 
self, so self is not a good word either.

Policy-drop or policy-induced discard or some 
similar phrase would be a better term for this.

I'm currently offline, so I cannot search to see 
if there is already a commonly used term for this.

Bob

> >> >> explanation and/or an example will go a long way.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 18 Apr 2011 10:04:46 -0400

Hi Bob,

Responses in line below.

Thanks,

Dave

>you are overloading your own DSL line, or your own home network.

Those are cases that the term was intended to cover.
>if there is already a commonly used term for this.

Using another term  is fine with me, but please put the term in the
definitions section of the draft and change the references from "self
congestion" to the new term.

>> >> Also, based upon some misunderstanding of terminology that was
>>apparent
>> >>on