Subject: Re: [conex] FW: New Version Notification for draft-mcdysan-conex-other-usecases-00

From: "Toby Moncaster" <[email-masked]>
Date: Sun, 7 Nov 2010 18:40:06 -0000

Hi David,

As promised, here is a quick review of your document. It's a good thing that
more people are trying to come up with alternative use cases for ConEx. This
simply highlights how powerful a concept congestion exposure is... 

My top-level comment would be that many of the things you talk about are
orthogonal to or supplementary to ConEx. ConEx is a low-level metric that
also introduces the concept of using re-feedback for metrics. You seem to be
suggesting that re-feedback could be used for other metrics...

Your first 3 sections provide a good background to the motivations behind
congestion exposure, so I am not going to give comments on them. Jumping to
section 4:

4.1 Inequity of heavy versus light users. You seem to be suggesting that
there is a need to measure the relative "burstiness" of users. You seem to
accept that in the short term the policer proposed in ["Policing Freedom to
Use the Internet Resource Pool"; Jacquet, Briscoe, Moncaster; 2008] is able
to overcome the inequity between heavy and light users. However I would
suggest that such a policer also achieves this same result over longer time
scales. Since it is based on a token bucket, a heavy user that is always
creating congestion is likely to be constantly running with a less than full
bucket. Thus, if congestion increases suddenly (for instance when a light
user comes online), the heavy user runs out of credit first and so is
throttled. If there isn't sufficient congestion for the heavy user to be
running down their bucket then there seems little point in stopping them
using the network. To give a (definitely bad) analogy: Just because someone
only uses their car at weekends doesn't meant they have a right to take
priority over their neighbour that uses their car all day every day.

4.2 Usage Tier/ Volume Feedback. This section seems to be orthogonal to the
question of congestion exposure. If I understand you right you are
suggesting that by improving the signalling to users (using some form of
forward signalling) you are able to apply volume charging/capping more
effectively because you allow them to avoid nasty surprises. This is very
similar to what seems to be done by many mobile phone companies and indeed
does make it more acceptable for users to have variable billing or fixed
monthly caps beyond which they are billed. However as I say, this is a
separate issue to congestion exposure (see all Bob's stuff about why volume
!= congestion).

4.3  Feedback on Time of Day, Day of Week Charging. No one is (or should be)
claiming that ConEx is a magic bullet that will avoid the need for operators
to provision more capacity. What ConEx gives is an ability to better target
the upgrades to where they will do the most good. One of the main aims of
the policer (mentioned above) is to try and persuade users to shift demand
to periods when congestion is lower. Clearly most users would need clever
applications to help them do this, but this was one of the core concepts in
re-ECN and holds true for ConEx.

4.4 Recharging for Implementing Congestion Pricing. To me this is not
strictly a use case for ConEx, rather it is a possible commercial model that
might encourage certain content providers to push harder for ConEx to be
deployed... Having said that, it is clearly a sensible idea.

Hope the comments are useful, and I think it would be sensible if the two
use case drafts ended up being combined in some fashion. Perhaps those of
you that are in Beijing can have a go at bashing something out?

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mcdysan, David E
> Sent: 17 October 2010 17:31
> To: [email-masked]; marcelo bagnulo braun; [email-masked]
> Subject: [conex] FW: New Version Notification for draft-mcdysan-conex-
> other-usecases-00
> 
> 
> Hi,
> 
> I submitted the following -00 draft today for discussion on the list
> and am requesting an agenda slot for the IETF 79 meeting.
> 
> http://www.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt
> 
> Thanks,
> 
> Dave
> 
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: Sunday, October 17, 2010 12:26 PM
> To: Mcdysan, David E
> Subject: New Version Notification for draft-mcdysan-conex-other-
> usecases-00
> 
> 
> A new version of I-D, draft-mcdysan-conex-other-usecases-00.txt has
> been successfully submitted by Dave McDysan and posted to the IETF
> repository.
> 
> Filename:	 draft-mcdysan-conex-other-usecases
> Revision:	 00
> Title:		 Proposed Additional Use Cases for Congestion
> Exposure
> Creation_date:	 2010-10-17
> WG ID:		 Independent Submission
> Number_of_pages: 7
> 
> Abstract:
> This draft proposes some use cases for inclusion in the conex Working
> group charter's deliverable for an informational RFC covering use case
> description. These use cases are in addition to and/or complement those
> described in [UseCases], and focus on forms of congestion exposure that
> involve resources other than queues and timeframes other than real-
> time.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 8 Nov 2010 00:51:41 -0500

Hi Toby,

Thank you for the comments.

A few responses and proposals on how to move forward in line below prefixed by DM. My Webmail client does not format a response in the usual way.

Thanks,

Dave

________________________________________
From: Toby Moncaster [[email-masked]]
Sent: Sunday, November 07, 2010 1:40 PM
To: Mcdysan, David E; [email-masked]; 'marcelo bagnulo braun'; [email-masked]
Subject: RE: [conex] FW: New Version Notification for draft-mcdysan-conex-other-usecases-00

Hi David,

DM- I parse this comment in parentheses using wording from the conex charter as follows.  Conex is a low-level (IP), re-feedback/metric ("senders inform the network about  the congestion encountered by previous packets on the same flow"). Still not sure I understand what you mean by "metric."

Your first 3 sections provide a good background to the motivations behind
congestion exposure, so I am not going to give comments on them. 

DM - As mentioned in my response to Alissa, I view this section as a statement of motivation and objectives. IMO, the use cases should strive to meet as many of these objectives as possible within the bounds of the charter.

Jumping to section 4:

to overcome the inequity between heavy and light users. 

DM - IMHO, I agree with posts by other operators and comments made in conex sessions that policing could result in user disssatisfaction. However, it may be a valid use case for some scenarios and operators. I explicitly chose to not mention policing as the type of response to be used since this was already covered in the moncaster use case draft.

However I would
using the network. 

DM - A (deeper) token bucket seems to be a valid mechanism to measure burstiness. Other mechanisms may be possible in software, not requiring changes to existing hardware. 

To give a (definitely bad) analogy: Just because someone
only uses their car at weekends doesn't meant they have a right to take
priority over their neighbour that uses their car all day every day.

DM - Here I am viewing the longer term usage tier as a congestible resource, in which case it is not orthogonal. From the user perspective their expenditures are subject to congestion (i.e., overload) and this in fact may be much more important to many users than congesting a queue.

4.3  Feedback on Time of Day, Day of Week Charging. No one is (or should be)
claiming that ConEx is a magic bullet that will avoid the need for operators
to provision more capacity. 

DM - Why not?

What ConEx gives is an ability to better target the upgrades to where they will do the most good. One of the main aims ofthe policer (mentioned above) is to try and persuade users to shift demand
to periods when congestion is lower. 

DM - Policing as a form of congestion pricing is a valid mechanism, but I believe it will create increased operational expense in the form of an operatopr needing to handle and increased level of complaints.

Clearly most users would need clever applications to help them do this, but this was one of the core concepts in
re-ECN and holds true for ConEx.

DM - Having Conex enable such clever mechanisms is of interest to me.

DM - Good suggestion, and thanks for your comments. IMO it is not essential that every operator see a need to implement every use case since the situation differs in a number of factors.

Toby

---

From: John Leslie <[email-masked]>
Date: Mon, 8 Nov 2010 10:38:40 -0500

> http://www.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt

   From section 4.1 Inequity of Heavy versus Light Users:
] 
] A congestion measure of burstiness (e.g., ratio of peak rate to
] average rate over a longer interval than the tiered bandwidth shaper
] or policer) could be helpful in this use case. In general, a bursty
] packet flow is light (e.g., web surfing) and a non-bursty packet flow
] is heavy (e.g., viewing a lengthy HD video). The destination could
] perform this measure and feed it back to the sender...

   I'm not sure I correctly follow the context here. I think David is
talking about "heavy users" during peak usage:
] 
] However, during peak use periods, a heavy user may send at near the
] bandwidth tier while light users may send intermittently. There is a
] need for a means for service providers to equitably assign costs to
] heavy versus light users.

   I don't think we want to go into the question of "equitably" assigning
costs; but there is a valid question of what information we could gather
that would assist a provider in that question.

   I think most of us would agree that if the "heavy user" backs off
during congestion, s/he shouldn't be charged "congestion costs" during
the period of back-off.

   Does David think we need to specifically gather to what extent this
"heavy user" backs off? (Speaking only for myself, I don't see that need.)

   In any case, David talks of "burstiness" as
] 
] ratio of peak rate to average rate over a longer interval than the
] tiered bandwidth shaper or policer

which presumably is a per-flow measurement. I'm curious what David thinks
a provider would do with such a per-flow measure.

   To my provider-centric view, "burstiness" would decay with aggregation;
and I'd be concerned only after some aggregation had already occurred.

   Also, it makes quite a difference (to me) whether we're talking about
a point near the sender or near the receiver. Near the receiver, most
of the aggregation is long-since done, while near the sender, relatively
little has been done. I'm having difficulty seeing what metric could
serve both cases...

   David, presumably, is talking about a _charging_ mechanism (which I
guess might charge sender, receiver, or both). While I have no interest
in such a charging mechanism myself, I wouldn't want to prohibit it.
Maybe it would help me understand if David described one or two examples
of such a charging mechanism...

   Absent such a description, I tend to think of charging sender only,
and only based on total volume of congestion-expected marked traffic.
In my analysis, any user (heavy or light) that gets out of the way
during congested times doesn't deserve to be charged for the congestion
avoided.

   A "heavy" user might or might not be willing to get out of the way.
Real-time audio/video would be disinclined to get out of the way --
thus deserving a congestion charge. "Video-on-demand" could get out of
the way "briefly", thus deserving a lesser charge. Background downloads
could get out of the way for hours on end, thus deserving essentially
no congestion charge. But all of these are "heavy" users; and I don't
follow how David's "burstiness" measure would help distinguish them.

--
John Leslie <[email-masked]>

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 8 Nov 2010 19:39:12 -0500

Hi John,

Some responses in line below prefixed by DM.

Thanks for the thoughtful questions and comments.

Regards,

Dave

________________________________________
From: John Leslie [[email-masked]]
Sent: Monday, November 08, 2010 10:38 AM
To: Mcdysan, David E
Cc: [email-masked]
Subject: "Burstiness"

DM - Yes, that is what I intended (the following is from the paragraph prior to the one above from the draft.
]

DM - Agreed.

DM - I think what you describe is a specific mechanism, which is already described in the moncaster use case draft. As I mentioned earlier in response to Alissa, I tried not to go too much into mechanism since the topic was use cases, but let me try now to briefly describe what I had in mind.I was thinking that instead of only charging on short term average bandwidth of a shaper as is done today and results in the 80/20 experience reported by Varian that shaping and possibly charging is based upon longer term metrics, such as the burstiness. In the next section 4.2 I mention that usage tier accounting partially addresses this issue, but 

"does not address situation where heavy users send at a high rate,
      but only for a fraction of the usage measurement interval (e.g.,
      only for a few hours or days during a month)."

DM - Also note that "queue congestion" may not actually occur during a peak period. IMO customers should not experience different behaviors depending upon the state of capacity provisioned in the network, which could occur with the way that conex is currently defined.

DM - No, see above.

DM - See above.

DM - Not on a per flow basis. The non-work conserving shaper is the resource that can be congested, not an aggregate interface. I think that congestion of an aggregate interface is a different use case than what I have in mind, and may already be covered in the moncaster draft.

DM - Agreed. see above, I think there at least two cases: per flow near receiver and aggregate at other points (e.g., between ISPs).

DM - Fairf comment. I made a first pass at such a description above. 

DM - This is a valid use case, but not what I had in mind.

DM - The feedback I had in mind is to senders regarding the congestion experienced by a non-work conserving shaper that in addition to a short term rate also has the characteristic of allowed burstiness over a longer-time interval. It is congestion of this per user/flow interface that would enable a form of charging more suited to the heavy/light users reported by Varian and observed on the networks with which I have access to such measurements.

---

From: John Leslie <[email-masked]>
Date: Mon, 8 Nov 2010 20:27:13 -0500

(Hopefully I'm picking out the right sections of David's response...)

Mcdysan, David E <[email-masked]> wrote:
> [John Leslie wrote:]
> DM - I think what you describe is a specific mechanism, which is already
> described in the moncaster use case draft.

   I was not intending to describe a mechanism...

> As I mentioned earlier in response to Alissa, I tried not to go too much
> into mechanism since the topic was use cases, but let me try now to
> briefly describe what I had in mind. I was thinking that instead of only
> charging on short term average bandwidth of a shaper as is done today
> and results in the 80/20 experience reported by Varian that shaping and
> possibly charging is based upon longer term metrics, such as the
> burstiness. In the next section 4.2 I mention that usage tier accounting
> partially addresses this issue, but 
> 

   Do I understand that David intends this to change the mechanism for
charging _receivers_?

> DM - Also note that "queue congestion" may not actually occur during a
> peak period. IMO customers should not experience different behaviors
> depending upon the state of capacity provisioned in the network, which
> could occur with the way that conex is currently defined.

   I must be misunderstanding: how can users _avoid_ a different experience
during a period of significant congestion?

> DM - Not on a per flow basis. The non-work conserving shaper is the
> resource that can be congested, not an aggregate interface.

   A reference to "non-work conserving shaper" would help, I think.

> DM - Agreed. see above, I think there at least two cases: per flow near
> receiver and aggregate at other points (e.g., between ISPs).

   (Hopefully I interpret this correctly: that David is thinking about
near-the-receiver and "charging" the receiver.)

> DM - The feedback I had in mind is to senders regarding the congestion
> experienced by a non-work conserving shaper that in addition to a short
> term rate also has the characteristic of allowed burstiness over a
> longer-time interval.

   I'm guessing here -- that David's "non-work conserving shaper" is
dropping some packets or otherwise marking as congestion some traffic
which isn't actual queue congestion. Please correct me if I'm guessing
wrong...

> It is congestion of this per user/flow interface that would enable a
> form of charging more suited to the heavy/light users reported by
> Varian and observed on the networks with which I have access to such
> measurements.

   What "charging" is "suitable" is not in-scope here.

   However, (if I'm guessing correctly) "congestion" which isn't actual
queue-based congestion is probably still "congestion" which may deserve
to be made visible throughout the path under a ConEx protocol.

   A few questions come to mind:

- is there some action to be taken by any point other than receiver and
  sender?

- is there an intent to collect and correlate this information elsewhere?

- does David have in mind some specific metric useful under a different
  business model?

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 9 Nov 2010 21:16:51 -0500

Hi JOhn,

Dave

________________________________________
From: John Leslie [[email-masked]]
Sent: Monday, November 08, 2010 8:27 PM
To: Mcdysan, David E
Cc: [email-masked]
Subject: Re: "Burstiness"

DM - More specifically, as described in the draft as a measure of congestion that could be used for charging (or policing).

DM - As I understand the current conex use case, if the provisioned capacity >> offered load then congestion (i.e., Pr[drop or ECN marking]) is small and any congestion action (e.g., policing, pricing) will also be small. If the offered load approaches provisioned capacity then the congestion is larger and congestion action will be larger. Hence, a user sending the same traffic at different points in time will experience different behaviors. As mentioned by others in meetings and on the list, a typical provider practice is to provision capacity such that congestion is small.

DM - I had thought of adding a reference to BBF (formerly DSL Forum) TR-059, but thought this was a specific mechanism. Reading the -02 moncaster draft, there is less mechanism than -01 but there is still a fair amount that assumes a specific mechanism. After having written this draft I have a better appreciation for the difficulty involved with separating these concepts.

DM - In the "heavy/light user inequity use case, yes. In the recharging use case, it would be a third party (e.g., the sender).

DM - What I had in mind is providing feed forward (and feedback) on a longer time scale than per packet. IMO, a longer term view makes an experimental protocol implementable in software versus a per packet method which probably requires hardware or microcode changes. 

DM - I suggest that we need to agree as a wg and get AD consensus as to what the charter statement means by excluding "billing." The moncaster -02 use case draft mentions charging, payment, and econmics in many places and we should apply the charter interpretation consistently.

DM - Yes! That is what I had in mind.

DM - I have some ideas on these, but I think they seem more like mechanism. As I stated in response to Alissa, if the wg finds (some aspects) of the proposed use cases interesting then I (inviting any others willing and having time to work on this) to draft out some abstract mechanisms.
--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Wed, 10 Nov 2010 16:32:57 -0500

Mcdysan, David E <[email-masked]> wrote:
> DM - As I understand the current conex use case, if the provisioned
> capacity >> offered load then congestion (i.e., Pr[drop or ECN marking])
> is small and any congestion action (e.g., policing, pricing) will also
> be small.

   Hopefully zero...

> If the offered load approaches provisioned capacity then the congestion
> is larger and congestion action will be larger. Hence, a user sending
> the same traffic at different points in time will experience different
> behaviors.

   Yes. (with or without ConEx...)

> As mentioned by others in meetings and on the list, a typical provider
> practice is to provision capacity such that congestion is small.

   Again, hopefully zero in the "normal" case.

> DM - I had thought of adding a reference to BBF (formerly DSL Forum)
> TR-059,

   (48 pages)

> but thought this was a specific mechanism.

   (I don't find "conserving shaper" in there, and the two mentions of
"shaper" don't seem helpful.)

> Reading the -02 moncaster draft, there is less mechanism than -01 but
> there is still a fair amount that assumes a specific mechanism. After
> having written this draft I have a better appreciation for the difficulty
> involved with separating these concepts.

   Thank you!

> DM - In the "heavy/light user inequity use case, yes. In the recharging
> use case, it would be a third party (e.g., the sender).

   I don't mean to exclude "sender-pays" -- I'm trying to understand the
use case(s) you're proposing.

   (I really have read the draft several times, including another full
reading before replying to this...)

> DM - What I had in mind is providing feed forward (and feedback) on a
> longer time scale than per packet.

   This strikes me as a funny thing to ask for at the IP layer...

> IMO, a longer term view makes an experimental protocol implementable
> in software versus a per packet method which probably requires hardware
> or microcode changes. 

   My own view is that initially deployment will only be at specific
boundaries, and can be done by a dead-stupid device which only forwards
packets from a known interface to another known interface, never waiting
for the whole packet before forwarding. The processing needed could
easily be done in software under these circumstances. At OC-48 this is
trivial; at OC-192 (roughly 10-gig ethernet) I believe it's still cheap
enough.

>> Varian and observed on the networks with which I have access to such

   I'm failing to understand why anything beyond aggregating from per-
packet information (using a device running in the end-user's timezone)
would help at all.

   In particular, I think the end-user (being charged for packets
received) is in a far better position to judge his/her priorities than
a sender perhaps 12 timezones away; and is in far better control (by
limiting ACKs) than a sender which has little incentive to implement
each provider's (changing) pricing rules.

> DM - I have some ideas on these, but I think they seem more like
> mechanism.

   As of today, draft-moncaster is still an individual draft; and I feel
an obligation not to promise something I don't understand and can't
imagine a way to deliver.

   I don't require settling on a "final" mechanism (nor do I object in
principle to gathering information we don't yet know how to use), but
absent some kind of answers to questions like these, I'm not prepared
to add David's use-cases before this becomes a WG draft.

   (Of course, if the WG has consensus to add them _when_ this becomes
a WG draft, I'm willing to help edit them in...)

> As I stated in response to Alissa, if the wg finds (some aspects) of
> the proposed use cases interesting then I (inviting any others willing
> and having time to work on this) to draft out some abstract mechanisms.

   Hopefully, the WG can discuss that this morning.