Subject: Re: [conex] Discussion of new Use Cases pt 1

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 1 Mar 2011 09:58:42 -0000

Hi Dave,

inline

> -----Original Message-----
> From: Mcdysan, David E [mailto:[email-masked]]
> Sent: 01 March 2011 01:38
> To: Toby Moncaster; 'Alissa Cooper'
> Cc: [email-masked]
> Subject: Re: [conex] Discussion of new Use Cases pt 1
> 
> Hi Toby,
> 
> A few responses in line below.
> 
> Thanks,
> 
> Dave
> 
> On 2/26/11 7:50 AM, "Toby Moncaster" <[email-masked]> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of Alissa Cooper
> >> Sent: 26 February 2011 12:21
> >> To: Mcdysan, David E
> >> Cc: [email-masked]
> >> Subject: Re: [conex] Discussion of new Use Cases pt 1
> >>
> >> Hi Dave,
> >>
> >> Couple of questions inline...
> >>
> >> On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote:
> >> > The proposed measure from the text that Toby sent from my draft
> for
> >> > this
> >> > use case is that of burstiness (I.e., peak/average) where the
> >> > incentive
> >> > peak is the"flat rate" or "bandwidth tier" purchased.
> >> > ...
> >> >
> >> > Let me illustrate by an example. If conex could send longer-term
> user
> >> > burstiness to the congested shared resource, then a mechanism (to
> be
> >> > described in the mechanism draft) at that point could
> >> > drop more traffic from class B non-bursty users so that bandwidth
> >> > tends
> >> > to equalize between the two user classes
> >> > Implement a bandwidth tier AND burst duration pricing scheme, with
> >> > appropriate mechanisms to provide a burst duration longer than the
> >> > shapers
> >> > widely used today
> >> >
> >>
> >> It seems to me that there are two different approaches being taken
> to
> >> what is or is not in scope for both the use cases and the mechanism
> >> definition:
> >>
> >> Approach #1:
> >> a. Assume that the CONEX mechanism will be used exclusively to
> signal
> >> the amount of congestion encountered by previous packets on the same
> >> flow
> >> b. Document the different uses to which that signal could be put
> >> (traffic management, incentivizing scavenger services, etc.) in the
> >> use cases draft
> >> c. Document how the signal is set in the mechanism draft
> >
> >This is certainly the approach in draft-ietf-conex-concepts-uses and
> the
> >co-authors of that document assumed this was what the charter was
> looking
> >for.
> 
> See my response to Allison and the meeting minutes from IETF 79 and
> IETF
> 78.

I will wait to see if Alissa replies or not

> 
> >
> >>
> >> Approach #2:
> >> a. Assume that the metric that CONEX will signal is open for
> >> discussion, or that the mechanism may signal multiple different
> metrics
> >> b. Document use cases for a variety of different potential metrics
> in
> >> the use cases draft (congestion encountered previously on same flow,
> >> long-term user burstiness as you describe above, possibly others)
> >> c. Document how network nodes could respond to CONEX signals to
> >> effectuate particular outcomes (dropping more traffic from non-
> bursty
> >> users as you describe above)
> >
> >The potential problem with this approach is that there is no end to
> the
> >possible metrics that we could explore. In theory we are meant to be
> >submitting the Use Cases document by March this year! So we do need to
> be
> >sensible about what is in and out of scope.
> >
> >>
> >> It seems as though you are taking approach #2 whereas others may be
> >> taking approach #1, and these two approaches probably need to be
> >> reconciled. I don't see how the same mechanism can signal both
> >> congestion previously experienced on the path and peak/average
> sending
> >> rate (although I'm happy for you or someone else to explain how it
> can
> >> be done). If it can't be done, then it seems like we are talking
> about
> >> signaling two different metrics.
> >
> >I certainly favour approach 1, and this seems to better match with our
> >charter. On the other hand there is potential for looking at broader
> >definitions of congestion within the use cases document. One of the
> big
> >issues facing the WG is defining congestion in a sensible fashion.
> >
> >I agree that Dave's peak/average rate signal doesn't seem to fit into
> the
> >same sort of signalling framework. For one thing Dave seems to just
> imply
> >this would be a binary state.
> 
> 
> I.m not sure I understand this comment. Could you please expand on what
> are the states.

If I understood you correctly, you were suggesting that users would be
classified as "heavy" or "not heavy", with their traffic marked
appropriately?

> 
> >However I think it may be possible to derive
> >something that gives the same information as Dave is looking for
> without
> >needing an additional explicit signal.
> 
> This is a good example of how I would see the use case and mechanism
> drafts inter-relating. If the same mechanism signaling can be used to
> meet
> other use cases, then IMHO then this makes the abstract mechanism more
> attractive. However, if the use case cannot be (well) handled by the
> abstract mechanism, then that is also useful information.

I agree it would be good to have some idea of how broad the applicability of
the abstract mechanism is. I actually think that there is very little real
disagreement between what we are both saying. The only significant
difference seems to be you are suggesting an explicit measure of long-term
"heaviness" of use, whereas I feel that such a measure can be derived from
the short term congestion measure.

> 
> >
> >>
> >> If we are focused on a single metric, then I think we need to
> document
> >> use cases for that metric. If there are multiple metrics, we should
> be
> >> clear about which use cases make use of which metric. And in either
> >> case, I thought the point of the mechanism draft was to explain how
> >> the chosen metric is measured so that it can be encoded at the IP
> >> layer.
> >
> >I favour concentrating on a single metric relating as closely as
> possible
> >to
> >"real" congestion. But Dave does have a very valid point - for
> whatever
> >reason, many ISPs use a shaper to rate limit traffic to/from their
> >customers. I would argue that at peak times this is probably not the
> >limiting factor, but off-peak it will be the biggest source of
> apparent
> >loss/congestion.
> 
> And as I tried to describe in my Beijing draft, in certain growth and
> restoration scenarios off-peak is the majority of elapsed network
> equipment deployment time.

I will go back to your draft to see if I can understand this a bit better.
Out of interest, do you have a good feel for how things differ between
DOCSIS and xDSL systems? I know that in xDSL there is also shaping at the
BRAS (or DSLAM) to make sure the downlink to the end user is not overloaded.

> 
> >
> >One interesting thought experiment - what if, instead of a shaper, the
> ISP
> >introduces a congestion marking system. Then it can rate limit traffic
> by
> >marking it before the traffic needs to be disrupted. The only problem
> then
> >is how to deal with non-responsive traffic.
> 
> This idea is not complete, but I think it is in the direction I
> mentioned
> above of having a description of how one mechanism could be used in a
> different way to meet the needs of a use case.

The idea is very far from complete! I wanted to try and get people thinking
about how adaptable the ConEx approach might be... As I say, our views on
this are not all that different in practise.

Toby

> 
> >
> >Toby
> >
> >>
> >> Alissa
> >>
> >> >
> >> > Thanks,
> >> >
> >> > Dave
> >> >
> >> >
> >> > On 2/24/11 5:11 PM, "John Leslie" <[email-masked]> wrote:
> >> >
> >> >> STUART VENTERS <[email-masked]> wrote:
> >> >>>
> >> >>> Let me make sure I understand this use case and it's desired
> >> >>> outcome:
> >> >>>
> >> >>> Consider 2 users A, and B.
> >> >>>   A sends at a low rate all the time.
> >> >>>   B sends only a congestion causing bunch during busy times.
> >> >>>   A sends many more bytes per month than B
> >> >>>
> >> >>> Which is the 'heavy' user (I think B)?
> >> >>
> >> >>  I don't think we should assume that...
> >> >>
> >> >>> Are we looking for a way for service providers to determine
> >> >>> 'equitable'
> >> >>> costs for these behaviors, or a way to make the system
> forwarding
> >> >>> behavior for these two load is somehow 'equitable'?
> >> >>
> >> >>  To some degree, Dave has to speak for himself, but IMHO this
> issue
> >> >> is
> >> >> about being able (under ConEx) to better inform a provider's
> >> >> decision.
> >> >> I'm nearly positive Dave doesn't mean for us to argue what
> balance
> >> >> between
> >> >> these two is "equitable".
> >> >>
> >> >>  At first blush, it would seem "B" should "expect" congestion
> >> losses,
> >> >> while "A" might not. Current non-ConEx methods tend to punish "A"
> >> >> more
> >> >> than "B"; and I do suspect Dave is suggesting a different balance
> >> >> might
> >> >> be appropriate.
> >> >>
> >> >>  Nonetheless, IMHO "A" should expect congestion losses to
> increase
> >> >> during periods of heavy use -- unless s/he buys better-than the
> >> >> vanilla
> >> >> best-effort service.
> >> >>
> >> >> --
> >> >> John Leslie <[email-masked]>
> >> >> _______________________________________________
> >> >> conex mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/conex
> >> >
> >> > _______________________________________________
> >> > conex mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/conex
> >> >
> >>
> >>
> >> _______________________________________________
> >> conex mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/conex
> >

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 2 Mar 2011 08:11:08 -0500

Hi Toby,

In line, snipping some material already covered.

Dave

On 3/1/11 4:58 AM, "Toby Moncaster" <[email-masked]> wrote:

>Inline

Snipped

>classified as "heavy" or "not heavy", with their traffic marked

NOw I understand your point. I was proposing burstiness as (one possible)
measure of "heaviness." It could be quantized as two values, and the title
"heavy vs light" does imply this. However, I would not want to preclude
more levels of quantization or a conex response that was some related to
such a "heaviness" measure in a more continuous manner.

>the short term congestion measure.

I am OK with a comparable measure that can be derived from the abstract
mechanism draft. But we should agree as to what the form of the result of
such a variation would like. That is, what are the characterisitics.

>BRAS (or DSLAM) to make sure the downlink to the end user is not

This is a different aspect. It was covered in the time of day reuse
section of my Beijing draft. As suggested in the WG minutes draft I plan
to write a short individual draft on this topic and submit by 3/7. I will
include/ clarify this point in that short draft. I plan to include some of
the material from the thread related to ledbat and some of the problem
statement comments from Mikael Abrahamsson.

>this are not all that different in practise.

Agreed. I would be open to jointly develop some text off-list that
describes the derivation you mention and mapping to the abstract mechanism
and then publishing that proposed text to the list.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 2 Mar 2011 17:49:54 +0100

Hi Dave,

> >> >something that gives the same information as Dave is looking for without

I agree with Toby here. You can derive something like "heaviness" 
or "burtiness" from the (long-term evaluation of) ConEx information. Thus the 
use case would be that those information can be derived. The use case should 
_NOT_ cover _HOW_ those information will be derived as this is a different 
mechanism and out of scope.

Mirja

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 2 Mar 2011 13:04:08 -0500

Hi Mirja,

On 3/2/11 11:49 AM, "Mirja Kuehlewind"
<[email-masked]> wrote:

>> >I agree it would be good to have some idea of how broad the
>>applicability
>> >of

I don't believe that saying a derivation is possible is sufficient. I
believe the working group needs to see some level of description of the
derivation to confirm this assertion. (It is not immediately obvious to
me.) If you are saying that the derivation need not be a description to
the level of detail of the abstract mechanism draft, then I agree. I
believe that John Leslie made the point that the use case draft would be a
good place to capture such derivation (outlines), and I agree with that
recommendation on wg document organization and content

Thanks,

Dave

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 2 Mar 2011 23:36:28 -0800

> such a "heaviness" measure in a more continuous manner.

Burstiness is only "heavy" when it is uncorrelated with network congestion.
An ideal LEDBAT-algorithm would be perceived as being 'bursty'. Therefore
I believe equating any form of burstiness that  a router could measure with
being a "heavy" user is a poor metric.

--
Caitlin Bestler
[email-masked]

--
Caitlin Bestler
[email-masked]
http://www.asomi.com/CaitlinBestlerResume.html

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 3 Mar 2011 09:19:28 -0000

> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: 03 March 2011 07:36
> To: Mcdysan, David E
> Cc: Toby Moncaster; 'Alissa Cooper'; [email-masked]

<SNIP>

> being a "heavy" user is a poor metric.

But when coupled with a measure of their actual contribution to congestion
(what we call congestion volume in the draft) it gives a very good measure.
You essentially end up with 4 groups - heavy users (high congestion, high
burstinesss), LEDBAT users (low congestion, low burstiness), "bursty" users
(low congestion, high burstiness) and light users (low congestion, low
burstiness).

Toby

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 09:31:40 -0500

Hi Caitlin,

You are reading this out of context of the earlier posts where burstiness
is meaningful only when congestion is occurring. Also, a burst user is
light, not heavy. I will merge the earlier posts along with the
clarification I provided to Toby in the new section Toby and I proposed so
that the context will be there.

Thanks,

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 3 Mar 2011 09:35:11 -0500

Hi Toby,

Agree that the coupling of burstiness with congestion is the region of
interest.

Will continue to work with you offline to fill in the subsection in the
proposed new section of the use case draft that would cover a mapping of
current measures into conex.

I haven't seen any objections to adding this new section, but I may not
get to this until Sunday.

Thanks,

Dave

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 3 Mar 2011 09:59:47 -0800

> (low congestion, high burstiness) and light users (low congestion, low

Agreed, that sort of classification would avoid the problem.

--
Caitlin Bestler
[email-masked]

---

From: John Leslie <[email-masked]>
Date: Thu, 3 Mar 2011 15:52:54 -0500

Mcdysan, David E <[email-masked]> wrote:
>>>> applicability of the abstract mechanism is. I actually think that
>>>> there is very little real disagreement between what we are both
>>>> saying. The only significant difference seems to be you are
>>>> suggesting an explicit measure of long-term "heaviness" of use,
>>>> whereas I feel that such a measure can be derived from the short
>>>> term congestion measure.
>>>
>>> I am OK with a comparable measure that can be derived from the
>>> abstract mechanism draft. But we should agree as to what the form of
>>> the result of such a variation would like. That is, what are the
>>> characterisitics.

   (I'm hoping Dave will capture some of this in the language he's
drafting.)

>> or "burtiness" from the (long-term evaluation of) ConEx information.
>> Thus the use case would be that those information can be derived.
>> The use case should _NOT_ cover _HOW_ those information will be
>> derived as this is a different mechanism and out of scope.

   I don't fully agree with Mirja here...

> I don't believe that saying a derivation is possible is sufficient.
> I believe the working group needs to see some level of description
> of the derivation to confirm this assertion.

   I tend to agree. Further, I think there's little point of _only_
showing how it "could" be derived -- I think a use-case should talk
about how such a derivative could be _used_.

> (It is not immediately obvious to me.)

   Nonetheless, I think Dave should make the first pass at sending
text.