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

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 24 Feb 2011 19:35:47 -0000

"Inequity of Heavy versus Light Users" use case

It was agreed that the "Inequity" use case from
draft-mcdysan-conex-other-usecases should be included in the WG Concepts and
Use Cases draft. As mentioned in my earlier email, the hope is to trigger a
discussion round the issues raised and to come to a consensus on what
actually needs to appear in the revised draft.

>From the discussion at Beijing it is apparent that the key aspect for
defining heavy and light users here is timescales. The worry people have is
that 20% of users are taking 80% of capacity, often without paying any extra
for doing so. Quoting from Dave McDysan's draft:

   During non-peak periods, the resources of a service or content

   provider are underutilized and the marginal cost of capacity is

   small.

   The access network is provisioned and traffic engineered for peak

   capacity of all users, and when congested, heavy users create 16

   times the congestion of small users.

   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. For example, the light users may pay less

   if they were charged by volume, as described in another use case.

The proposal in the draft was to introduce 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)". The assertion is that this
measure of burstiness would allow heavy users to be identified and hence
free up capacity for the lighter users.

So there are three questions for discussion: 

1) is there a need for a new "congestion measure of burstiness" that would
tag users as "heavy" or "light" over long timescales?

2) how would the system be expected to react differently to heavy and light
users?

3) can the same effect be achieved using current measures of congestion and
current policing mechanisms?

There is also some question as to whether this is the best title for this
use case. At its heart the use case is really concerned with timescales and
so it might be better to include a section on timescales in the draft.

Toby

---

From: STUART VENTERS <[email-masked]>
Date: Thu, 24 Feb 2011 15:55:23 -0600

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)?
 
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'?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Toby Moncaster
Sent: Thursday, February 24, 2011 1:36 PM
To: [email-masked]
Subject: [conex] Discussion of new Use Cases pt 1

It was agreed that the "Inequity" use case from draft-mcdysan-conex-other-usecases should be included in the WG Concepts and Use Cases draft. As mentioned in my earlier email, the hope is to trigger a discussion round the issues raised and to come to a consensus on what actually needs to appear in the revised draft.

>From the discussion at Beijing it is apparent that the key aspect for defining heavy and light users here is timescales. The worry people have is that 20% of users are taking 80% of capacity, often without paying any extra for doing so. Quoting from Dave McDysan's draft:

   small.

The proposal in the draft was to introduce 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)". The assertion is that this measure of burstiness would allow heavy users to be identified and hence free up capacity for the lighter users.

1) is there a need for a new "congestion measure of burstiness" that would tag users as "heavy" or "light" over long timescales?

2) how would the system be expected to react differently to heavy and light users?

3) can the same effect be achieved using current measures of congestion and current policing mechanisms?

There is also some question as to whether this is the best title for this use case. At its heart the use case is really concerned with timescales and so it might be better to include a section on timescales in the draft.

Toby

---

From: John Leslie <[email-masked]>
Date: Thu, 24 Feb 2011 17:11:27 -0500

> 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]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 25 Feb 2011 01:41:57 +0100 (CET)

On Thu, 24 Feb 2011, Toby Moncaster wrote:

> There is also some question as to whether this is the best title for 
> this use case. At its heart the use case is really concerned with 
> timescales and so it might be better to include a section on timescales 
> in the draft.

My impression is that often the 80/20 rule is over long timescales, 
including that they use a lot when marginal cost is low (because no 
congestion occured at that time).

Wouldn't it just make sense to try to achieve equal amount of bandwidth 
access when congestion occurs, instead of trying to penalise people who 
used a lot of bandwidth before congestion occured? This would avoid the 
problem of having to identify "heavy users" over time but instead just 
identify them right now?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: [email-masked] (speakeasy)
Date: Thu, 24 Feb 2011 16:48:10 -0800

> during periods of heavy use -- unless s/he buys better-than the vanilla

Add a 3rd user, C:

   C sends all the time, but has perfectly implemented a pre-standard LEDBAT-style
   algorithm such that C sends *lots* of data when the network is idle and next to none
   when the network is busy.

Is C a heavier user than A, or B?

To replay some discussions from RE-ECN, the congestion cost to the network is a function
of how deep in the queue a packet lands. The pricing strategies may vary, but I find it very
difficult to justify a conclusion that a packet low on the queue "costs more" than one higher
on the queue.

The problem with measuring total bandwidth versus peak is that you would actually penalize
a flow for avoiding congestion successfully. That would certainly be counter-productive.

---

From: STUART VENTERS <[email-masked]>
Date: Thu, 24 Feb 2011 20:05:05 -0600

>> or C
  C is an interesting user he is both really behaved in terms of causing little congestion and also probably getting more bytes per month that even user A.  Perhaps the right question is not to pick the heavy users, but rather the heavy congestion users.

>>the congestion cost to the network is a function of how deep in the queue a packet lands.
  I guess this is the same as the time the packet spends in queues in the network.

On a related issue:
So if there is few fields in the IPV6 header that are available in the forwarding path, how about the TTL field.
   Maybe decrement is extra counts for extra time in a queue.

-----Original Message-----
From: speakeasy [mailto:[email-masked]]
Sent: Thu 2/24/2011 6:48 PM
To: John Leslie
Cc: STUART VENTERS; [email-masked]
Subject: Re: [conex] Discussion of new Use Cases pt 1

Add a 3rd user, C:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 25 Feb 2011 03:06:21 +0100 (CET)

On Fri, 25 Feb 2011, João Taveira Araújo wrote:

> This can be done with variants of fair queuing, but it doesn't provide 
> the incentives for bulk traffic to be shifted to avoid congestion. Why 
> throttle now if you'll both suffer now and not reap any benefits later? 
> There is an overview of the design space in section 3 of 
> http://bobbriscoe.net/projects/refb/polfree_rearch08.pdf .

If each user gets equal share of the traffic then the incentive to mark 
bulk traffic as such is that that perticular user will have a much better 
interactive traffic experience when that person uses both at the same 
time at time of congestion.

Also, if there is a congestion usage cap, the bulk marked traffic wouldn't 
be counted as part of that cap, I guess?

---

From: João Taveira Araújo <[email-masked]>
Date: Fri, 25 Feb 2011 11:38:40 +0900

> be counted as part of that cap, I guess?

I was assuming you would just mark packets experiencing congestion rather than use LE marked traffic. In that case the rate at which lower-than-best-effort traffic experiences congestion should be lower simply because it is more conservative and backs off. Over time the amount of congestion caused might be the same as competing interactive traffic, but the rates at which congestion volume is consumed is different.

In theory this allows for a whole range of behaviour rather than trying to classify traffic into specific categories, which is my main concern with simply marking traffic as "bulk". That just fragments what we have now in two. And what we have now is the Orwellian "all types traffic are equal, but some types of traffic are more equal than others".

J

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 25 Feb 2011 09:17:44 -0500

There are several ideas being combined here and it may be best to separate
them and agree on some more precise terminology. First, assume that the
users are in the same QoS class and that the incentive is the"flat rate"
or "bandwidth tier" pricing. That is, there is no long term usage tier
pricing in place.

In many networks a non work conserving scheduler (e.g., a shaper)
implements the peak rate over an interval O(100 ms). Thus, the "bandwidth
tier" incentive is that a user pays more if he/she wants more peak rate
bandwidth. If the user sends at more than the purchased peak rate and
there is no congestion at a shared resource, then other users are not
impacted, and in a sense this user creates "self-congestion." The current
conex WG use case draft focuses on the case when congestion occurs at a
shared resource, which causes "inter-user-congestion."

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. Typically,
statistical multiplexing is assumed since many of the user traffic
patterns exhibit high burstiness and network share resources are not
provisioned at potential congestion points such that all users can send at
the peak rate. If the shared resource points are provisioned such that all
users can send at the peak rate (I.e., their bandwidth tier) then only
"self-congestion" can occur and "inter-user-congestion" cannot occur.

So, now consider two (classes of) users A and B during a time period where
congestion of a shared resource is occurring causing
"inter-user-congestion":
 Class A sends at an average rate much less than the peak rate of his/her
bandwidth tier (i.e., is VERY bursty and statistically multiplexable)
 Class B sends at an average rate that is near the peak rate of his/her
bandwidth tier for a time period much longer than the shaper queue depth,
potentially causing "self-congestion" as well (i.e., is NOT bursty and NOT
statistically multiplexable) (Note that LEDBAT would avoid
"self-congestion")

For the cited example, if 20% of the class B users send 80% of the traffic
during the (relatively long) interval during which the shared resource is
congested, then class B is sending 16x the traffic as compared with the
class A users.

What typically happens today at the congested shared resource(s) is that
user classes A and B will experience similar packet drop probabilities,
and hence similar goodput (as contributed to by "inter-user-congestion")

I agree with John "this issue is about being able (under ConEx) to better
inform a provider's decision." I would add that this also could enable
other forms of incentives (I.e., selective traffic management, and/or a
another form of pricing)

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

Thanks,

Dave

On 2/24/11 5:11 PM, "John Leslie" <[email-masked]> wrote:

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

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 25 Feb 2011 09:19:12 -0500

I agree that nne mechanism that could use the proposed burstiness measure
is "to try to achieve equal amount of bandwidth access when congestion
occurs" (at a shared resource).

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 25 Feb 2011 09:23:01 -0500

When the incentive is "flat rate" or "bandwidth tier" then uncongested
periods are irrelevant. When usage tier pricing is in place, then this is
another case which several WG members at the Beijing meeting commented
that this case was out of scope. There has been no subsequent discussion
on the list regarding this topic.

A question on terminology: what does "total bandwidth" mean as used in the
last sentence of your post?

Thanks,

Dave

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 25 Feb 2011 09:38:52 -0500

I think there are other use cases in this thread that we could consider:
 - Interaction between conex and different QoS classes (e.g., LE and
Interactive (BE?) as reported by Conex (Not sure if the current use case
draft covers this sufficiently)
 - Interaction between conex and Usage tier pricing (aka Usage caps) (As I
posted earlier, as documented in the meeting minutes some WG members
voiced belief in Beijing that this was out of WG scope -- appears there is
some WG interest in this topic based upon the posts over the past day).
 - Time shifting of bulk traffic to non-congested intervals (I proposed
this use case in my draft in Beijing, and there was WG interest but as
documented in the meeting minutes WG members voiced belief in Beijing that
this was out of WG scope. I was asked at the meeting to write more up
about this in an individual draft and the WG might later decide to include
it).

In addition to the WG member verbal feedback documented in the Beijing
meeting notes, it would be good to hear from the list regarding the types
of use cases they would like to address.

Thanks,

Dave

On 2/24/11 9:38 PM, "João Taveira Araújo" <[email-masked]> wrote:

>I was assuming you would just mark packets experiencing congestion rather
>than use LE marked traffic. In that case the rate at which
>lower-than-best-effort traffic experiences congestion should be lower
>simply because it is more conservative and backs off. Over time the
>amount of congestion caused might be the same as competing interactive
>traffic, but the rates at which congestion volume is consumed is
>different.
>
>In theory this allows for a whole range of behaviour rather than trying
>to classify traffic into specific categories, which is my main concern
>with simply marking traffic as "bulk". That just fragments what we have
>now in two. And what we have now is the Orwellian "all types traffic are
>equal, but some types of traffic are more equal than others".
>
>J

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 25 Feb 2011 15:59:49 +0100 (CET)

> about this in an individual draft and the WG might later decide to include

Personally I currently see the following problems:

Users cause self-congestion on their access link and AQM doesn't exist. 
There should be recommendations on what devices should do to provide a 
good end user experience (less-than-be for background transfers, have 
separate queues for small packets (might be easy way to catch 
SYN/ACK/VOIP), ECN/WRED behaviour and other things that can be agreed 
upon). This ties into the "buffer bloat" arguments that are going around. 
I believe we in the ISP industry as a whole has failed to provide adequate 
handling of queues for user traffic to create a good user experience under 
self-congestion.

Same as above but for the shared links. My thinking is that Less-than-BE 
would automatically be shifted away from peak hour if shared congestion 
occurs since it's less prioritized than BE, so it'll be painfully slow 
when other shared congestion occurs. So we should look closely at how to 
provide the best end-user experience under shared congestion, without 
starving out some users completely. I believe the scheme should follow the 
KISS principle as much as can be done, the more advanced the proposal is, 
the less likely is that it'll be deployed in any timely manner.

Remember ECN still after 10 years isn't widely deployed in ISP 
infrastructure. It's most of the time not enabled on end-systems either...

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 26 Feb 2011 12:21:16 +0000

Hi Dave,

Couple of questions inline...

On Feb 25, 2011, at 2:17 PM, Mcdysan, David E wrote:
> peak is the"flat rate" or "bandwidth tier" purchased.
> ...
>

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

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)

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.

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.

Alissa

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 26 Feb 2011 12:50:11 -0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Alissa Cooper
> Sent: 26 February 2011 12:21
> To: Mcdysan, David E
> Cc: [email-masked]

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.

> 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.

> 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. 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.

> the chosen metric is measured so that it can be encoded at the IP

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.

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.

Toby

---

From: John Leslie <[email-masked]>
Date: Sat, 26 Feb 2011 09:56:16 -0500

Toby Moncaster <[email-masked]> wrote:
> To: "'Alissa Cooper'" <[email-masked]>,
> 

   Agreed.

> submitting the Use Cases document by March this year! So we do need to
> be sensible about what is in and out of scope.

   While I believe there's still some room for discussion what we mean
by "congestion", I don't believe there's any room (left) for discussion
that we mean to record anything other than congestion expected during
transit of the packet in question (with some wiggle room for quantized
encoding a-la ECN). There just aren't enough bits.

   ConEx-aware boxes along the way are _very_ likely to aggregate our
ConEx markings, over time and/or over flows. A use-cases document can
discuss such things, whereas a mechanism document is probably more
limited.

>> 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.

   IMHO, discussion of a use-cases document has some leeway here --
not in what the metric will signal, but in what may be done based on
aggregations of that metric. I do not believe Dave McDysan has exceeded
that leeway -- though discussing use-cases in the absence of an agreed
metric _does_ tend to lead to confusion...

> definitions of congestion within the use cases document. One of the
> big issues facing the WG is defining congestion in a sensible fashion.

   Clearly, we do have to produce a use-cases document, though I would
prefer that at least an "abstract mechanism" could be agreed to as a
basis for it.

   I tend to take a long-term view which says whatever we settle on for
a mechanism should allow for future extensions. (Thus I am very much
at home with desires for different ways to measure "congestion".)

>> the chosen metric is measured so that it can be encoded at the IP

   I am hesitant to go the path of labeling use-cases according to what
metric best serves them. IMHO, our use-cases document should only include
things achievable with a particular metric, which I have been assuming
to be congestion-expected-during-transit.

   I do spend time thinking about "concrete" mechanisms, but I'm not sure
it would help to discuss them now. Certainly such discussion doesn't
belong in this thread.

> 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.

   Certainly, ConEx will need to operate in an environment where such
"shaping" occurs. I am considerably less sure how (if at all) it should
be discussed in a use-cases document. To me, it is "congestion" even if
it is not resource-congestion. Congestion-expected markings could better
inform decisions about "shaping". The issues about whether ConEx marking
is considered at any point of congestion are much the same...

> 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.

   That undoubtedly deserves its own thread!

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 28 Feb 2011 20:30:15 -0500

Hi Alissa,

Some responses in line below.

Thanks,

Dave

>the chosen metric is measured so that it can be encoded at the IP layer.

Quoting from the IETF 70 meeting minutes

"ConEx Concepts and Abstract Mechanism
 draft-mathis-conex-abstract-mech-00 "

Snipped
 " MB - not asking about sending to IESG, just asking about adoption - do
          people have comments?
          
          Dave McDysan (DM) - charter related question - first result is
usage
          scenarios document - other docs will not see publication until
that is
          done - have already had questions on list about additional use
cases.
          if we adopt this as the mechanism document then we foreclose
use-case
          discussion. there are use cases being elaborated that aren't
supported
          by the mechanism, so we could be going round in circles here.
          
          MB - are you envisioning additional use cases that could not be
satisfied
          by this mechanism?
          
          DM - yes
          
          MB - is this a little different or a lot?
          
          DM - could be a lot different. this is a good approach for short
          timescales, but could do something longer term, slow path.
          
          MB - so you would like to agree use cases?
          
          Leslie Daigle (LD) - i would like to support adopting mechanism
document.
          just don't use it as a blunt instrument to bludgeon people
proposing new
          use cases.
          
          MB - would that work for DM?
          
          DM - yes, if that decision can be documented.
          
          MB - yes, it will be documented, I will remember."

I interpreted the above as something like Approach 2 was acceptable -- a
use case did not need to align with the currently documented abstract
mechanism. If others have a different interpretation, please respond to
the list.

Also, the way the prior version of the use case draft was written was
closely tied to the (re-ECN) mechanism (Approach 1) and the agreement from
the IETF 78 meeting minutes was to separate these. I provided a detailed
set of comments toward this end.

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 28 Feb 2011 20:38:01 -0500

Hi Toby,

A few responses in line below.

Thanks,

Dave

>co-authors of that document assumed this was what the charter was looking

See my response to Allison and the meeting minutes from IETF 79 and IETF
78. 

>this would be a binary state.

I.m not sure I understand this comment. Could you please expand on what
are the states. 

>However I think it may be possible to derive

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.

>to

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.

>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.

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 28 Feb 2011 21:06:44 -0500

Hi John,

Dave

>discuss such things, whereas a mechanism document is probably more

Good point. I think this is the general direction that Marcello may have
had in mind when he commented during my presentation in Beijing. Not sure
what Marcello, Rich or Bob had in mind here as discussed in the meeting
minutes.  I suggest that we need to work toward some proposed text for the
wg use case draft that describes this.

>prefer that at least an "abstract mechanism" could be agreed to as a

Not sure I understand what you are proposing. The wg decided to take
mechanism largely out of the use case draft in IETF 78, and in IETF 79 the
exclusion of a use case that did not match the adopted abstract mechanism
was explicitly agreed (see meeting minutes snippet in my response to
Allison).

>to be congestion-expected-during-transit.

Metric is mentioned once in the use case document in section 3 in the
context of existing approaches. Are you referring to the measures in
definitions of use cases, or something in the abstract mechanism draft?
(where the term metric is not used at all)

>be discussed in a use-cases document.

I asked this question in IETF 78 of Bob regarding a non-work conserving
scheduler (e.g., shaper), which can experiences the congestion measure as
defined in the current use case draft.

At a minimum I think the statement in the first paragraph of section 4
that describes what I called "inter-user congestion" as "---- congestion
means that your traffic impacts other users, and conversely that their
traffic impacts you." needs to exclude the use case of what I called
"self-congestion" needs to address the use case employed by many ISPs (as
Toby points out).

>To me, it is "congestion" even if

I didn't follow this. Could you please elaborate.