Subject: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 4 Mar 2011 11:37:37 -0500

Hi,

As documented in the IETF79 Beijing meeting minutes it was agreed that the concepts from the section titled "Inequity of Heavy versus Light Users"  from draft-mcdysan-conex-other-usecases should be included in the WG Concepts and Use Cases draft.

After much discussion (that ranged well beyond this topic, and spawned several other threads that are not addressed by this proposed text), Toby proposed adding a new section to the use case draft and I volunteered to draft content based upon the original draft as well as the relevant list discussion from the thread titled "Discussion of new Use Cases pt 1," along with relevant text from the spawned threads. I tried to list all of the people whose inputs I used to draft this text and am requesting the use-case draft authors to include your names in the Acknowledgement section (if it was not already there).

The title of the proposed new section X has been changed to represent the principal aspects of the use case, namely statistical multiplexing over longer timescales.

Thanks,

Dave
-----------------------------------------------------------------

X.  Statistical multiplexing over Longer Timescales

In this use case the assumption is that "flat rate" or "bandwidth tier" pricing is in place. A simplifying assumption is made that there is no very long term (e.g., monthly) usage tier pricing in place.

X.1 Problems Encountered in Existing Networks

The principal problem addressed by this use case is that 20% of the users generate 80% of the traffic volume and create unfairness with certain resource sharing [Varian], often without paying any extra for doing so when "flat rate" or "bandwidth tier" pricing is in effect. The timescale over which this difference in traffic volume exists can range from seconds, to many minutes to hours. The peak rate at which a user can send may be set by the physical transmission system, a non-work conserving scheduler, and/or a policer.

The access network is usually not provisioned and traffic engineered for the peak rate for all users but is instead provisioned assuming statistical multiplexing where a longer term (many seconds to minutes to hours) average capacity is assumed for all users during the busy period. The many minutes timescale is commonly used by network operators to determine when a portion of a network is near congestion [section 3.3, Bauer]. During non-busy periods, the service provider network is underutilized and hence there is no congestion of shared resources.

During busy periods where congestion (i.e., loss or ECN marking) of a shared resource (e.g., a queue or scheduler) can occur, heavier users may send at speeds up to the peak rate while lighter users may send at a rate much less than the peak rate. The result is that all users see the same congestion (i.e., loss or ECN marking probability) although the lighter users are sending at much less than the peak rate. Furthermore, when the shared resource is congested, heavy users create much more congestion volume than light users. In this sense, the response of current networks is "unfair," which is also called "economic congestion" [section 3.4, Bauer].

The above situation occurs in flat rate pricing where all user flows share the same resource (e.g., queue, scheduler).

In many networks a non work conserving scheduler (e.g., a shaper) implements a per-user peak rate over an interval O(100 ms). See Appendix B of [DSL Forum TR-059] for a DSL specific example of non-work conserving schedulers. Similar techniques are used in access network equipment across a range of access technologies. Thus, the "bandwidth tier" incentive is that a user pays more if he/she wants more peak rate bandwidth.

Such non-work conserving schedulers create apparent congestion (i.e., loss or ECN marking) within their queue(s) which impact only a single user that need to be considered in the set of conex use cases. Further discussion on this topic is covered in the section "Self-Congestion versus Inter-User Congestion."

X.2 Conex Objectives for a Solution to this Problem

The general objective for conex is to provide better information for a provider to address the "unfairness" or "economic congestion" problem described in the previous section.

A specific objective is to achieve a "fairness" measure of bandwidth delivered in proportion to the user peak rate when congestion of a shared resource occurs.

A specific objective is to distinguish heavier users from lighter users over a the statistical multiplexing time interval that can range from seconds, to minutes, to hours so that network provider traffic management functions can provide "fairer" allocation of bandwidth.

A desirable objective is to distinguish between "self-congestion" and "inter-user congestion" so that users could use a mechanism external to conex to "go faster" in the event that only "self-congestion" is limiting their throughput.

X.2 Self-Congestion versus Inter-User Congestion

If the user sends at more than the shaper 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." There is also the case when congestion occurs at a shared resource, which causes "inter-user-congestion," where congestion volume from one user impacts other users. Note that "Self-Congestion" can occur when "Inter-User Congestion" occurs. However, a heavier user may not create "self-congestion" (i.e., loss or ECN marking) if that user sends at slightly less than a shaper peak rate (e.g., using LEDBAT).

There are (at least) three approaches for addressing this issue. Approaches 1, 2.a require no change to the conex abstract mechanism [wg-abstract-mechanism]. Approach 2.b would require signaling of additional information to the receiver (could be done separately from conex), and approach 3 may be able to use the conex abstract mechanism, albeit potentially in a different configuration.

1. Treat "self-congestion" the same as "inter-user congestion" since they both create congestion as perceived by the flow user.

2. Signal more information to the receiver about the cause of loss since
the remedy differs:
  a. For a shared queue, use current draft of abstract mechanism signals
to reduce load and choose packets for different treatments.
  b. For a queue dedicated to a receiver (e.g., shaper) signal information that the shaper peak rate is the bottleneck to the receiver, so that somehow (specific mechanism may not fit within the current conex wg charter) the user could make a request to "go faster."

3. Process and generate conex information at the network element which implements the shaper, which has knowledge of the configured peak rates for the users as well as local shared resource congestion. This network element can also use information about upstream shared resource congestion as delivered buy the conex protocol.

Note that during busy periods "self congestion" may not be the limiting factor, but during non-busy periods it will be the biggest source of apparent congestion.

X.3 Potential Support Using Abstract Mechanism

[Editorial Note from Dave: The following was derived list comments as well as a private input from Toby Moncaster.]

The following scenario assumes that all user flows implement conex. The case where not all flows implement conex still needs to be addressed. (Some form of localized "conex-like" marking may handle this case, since heavier users may have a significant incentive to not implement conex). Also to be addressed is the scenario where heavy users do not create congestion (e.g., using LEDBAT), but there is still a significant difference in average rate, or burstiness (peak/average).

Using the abstract mechanism a heavier user  never gets a chance to build up any congestion credit, which will not impact their service during non-busy periods. However, at peak times it means their service is degraded long before a light user sees any impact. In turn this means the congestion seen by the light user is less, meeting an important objective.

Additional local computations are done as follows. Over a  time period related to the statistical multiplexing interval (e.g., many seconds to minutes to hours) total up the number of bytes that have been congestion marked and the total number of bytes sent per user. Compute the ratio of congested bytes to total bytes.

The total is a measure of the average rate per user (averaged over the time period of the total).

For example, quantizing users into classes using one threshold on total and and another threshold on ratio results in a grid that identifies four distinct classes of user as follows:

+----------------+-------------+-------------+
|   Total volume>|             |             |
|v Ratio         |    Large    |    Small    |
+----------------+-------------+-------------+
|   High         | Heavy User  | Bursty User |
+----------------+-------------+-------------+
|   Low          | LEDBAT User | Light User  |
+----------------+-------------+-------------+

X.4 Additional Support Using other Measures and Mechanisms

An additional congestion measure of burstiness (e.g., ratio of peak rate to average rate over a longer interval than the tiered bandwidth shaper) would allow nodes upstream from the node implementing the shaper to implement traffic management. This measure could be derived from signals in the abstract mechanism but would require (a majority) of the heavier senders and receivers to implement conex and also would only work if loss or ECN marking occurs. Heavier users may have a significant incentive to not implement conex, and some additional mechanism to address this issue may be required. Also, signaling a measure of the burstiness (or something related to it) would address the scenario where no loss or ECN marking occurs.

As an alternative, if a "light weight" TCP proxy were implemented at the network element containing the shaper (e.g., an access router) and an upstream network element (e.g., a router at ingress to the service provider network), then potentially a conex control loop could be created between these network elements to provide fairer treatment between heavier and lighter users during congested intervals. In this case, a subset of conex features could potentially be used since this would be a closed domain where the signals could be implicitly trusted. The burstiness measure could be communicated using TCP extensions between these proxies.

There is also the aspect of "self congestion" when a non-work conserving scheduler (e.g., shaper) is employed at the access node. Even when "inter-user congestion" is not occurring (e.g., during a non-busy period), "self congestion" may occur. However, as discussed in the section on "Self Congestion versus Inter-User Congestion," using current mechanisms (i.e., implicitly determined loss or ECN marking) the receiver cannot tell the difference between "self-congestion" and "inter-user congestion." Adding a signal to the abstract mechanism could be quite useful so that a receiver can inform the sender regarding the cause of congestion, and enable the sender (or the receiver) to communicate with the network element controlling the shaper parameters enabling the flow to "go faster." using some non-conex mechanism.

---------------------

[Editorial Note: Please add the following]

Acknowledgements

Add the following:  Stuart Venters, Mikael Abrahamsson, Mirja Kuehlewind,  João Taveira Araújo, Caitlin Bestler, Steven Bauer, …

[Editorial Note: My thanks for inputs from authors, folks already listed in Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich Woundy, …]

References

[DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services," September 2003, http://www.broadband-forum.org/technical/download/TR-059.pdf

[Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78 Technical Plenary, 29 July 2010

[Bauer] Steven Bauer, David Clark, William Lehr,  "The Evolution of Internet Congestion," Massachusetts Institute of Technology, 2009

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 4 Mar 2011 17:46:49 -0000

Hi Dave,

Thanks for this text. I haven’t actually read through it yet. I will
incorporate it in the new version of the draft which I am hoping to release
by next weekend.

I will also update the acknowledgements list (something we had been asked to
do already by the WG chairs).

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mcdysan, David E
Sent: 04 March 2011 16:38
To: [email-masked]
Subject: [conex] Proposed Text for New Section in Use Case Draft -
Statistical multiplexing over Longer Timescales

Hi,

As documented in the IETF79 Beijing meeting minutes it was agreed that the
concepts from the section titled "Inequity of Heavy versus Light Users"
from draft-mcdysan-conex-other-usecases should be included in the WG
Concepts and Use Cases draft. 

After much discussion (that ranged well beyond this topic, and spawned
several other threads that are not addressed by this proposed text), Toby
proposed adding a new section to the use case draft and I volunteered to
draft content based upon the original draft as well as the relevant list
discussion from the thread titled "Discussion of new Use Cases pt 1," along
with relevant text from the spawned threads. I tried to list all of the
people whose inputs I used to draft this text and am requesting the use-case
draft authors to include your names in the Acknowledgement section (if it
was not already there).

The title of the proposed new section X has been changed to represent the
principal aspects of the use case, namely statistical multiplexing over
longer timescales.

Thanks,

Dave

In this use case the assumption is that "flat rate" or "bandwidth tier"
pricing is in place. A simplifying assumption is made that there is no very
long term (e.g., monthly) usage tier pricing in place.

The principal problem addressed by this use case is that 20% of the users
generate 80% of the traffic volume and create unfairness with certain
resource sharing [Varian], often without paying any extra for doing so when
"flat rate" or "bandwidth tier" pricing is in effect. The timescale over
which this difference in traffic volume exists can range from seconds, to
many minutes to hours. The peak rate at which a user can send may be set by
the physical transmission system, a non-work conserving scheduler, and/or a
policer. 

The access network is usually not provisioned and traffic engineered for the
peak rate for all users but is instead provisioned assuming statistical
multiplexing where a longer term (many seconds to minutes to hours) average
capacity is assumed for all users during the busy period. The many minutes
timescale is commonly used by network operators to determine when a portion
of a network is near congestion [section 3.3, Bauer]. During non-busy
periods, the service provider network is underutilized and hence there is no
congestion of shared resources. 

During busy periods where congestion (i.e., loss or ECN marking) of a shared
resource (e.g., a queue or scheduler) can occur, heavier users may send at
speeds up to the peak rate while lighter users may send at a rate much less
than the peak rate. The result is that all users see the same congestion
(i.e., loss or ECN marking probability) although the lighter users are
sending at much less than the peak rate. Furthermore, when the shared
resource is congested, heavy users create much more congestion volume than
light users. In this sense, the response of current networks is "unfair,"
which is also called "economic congestion" [section 3.4, Bauer].

The above situation occurs in flat rate pricing where all user flows share
the same resource (e.g., queue, scheduler). 

In many networks a non work conserving scheduler (e.g., a shaper) implements
a per-user peak rate over an interval O(100 ms). See Appendix B of [DSL
Forum TR-059] for a DSL specific example of non-work conserving schedulers.
Similar techniques are used in access network equipment across a range of
access technologies. Thus, the "bandwidth tier" incentive is that a user
pays more if he/she wants more peak rate bandwidth. 

Such non-work conserving schedulers create apparent congestion (i.e., loss
or ECN marking) within their queue(s) which impact only a single user that
need to be considered in the set of conex use cases. Further discussion on
this topic is covered in the section "Self-Congestion versus Inter-User
Congestion."

The general objective for conex is to provide better information for a
provider to address the "unfairness" or "economic congestion" problem
described in the previous section.  

A specific objective is to achieve a "fairness" measure of bandwidth
delivered in proportion to the user peak rate when congestion of a shared
resource occurs. 

A specific objective is to distinguish heavier users from lighter users over
a the statistical multiplexing time interval that can range from seconds, to
minutes, to hours so that network provider traffic management functions can
provide "fairer" allocation of bandwidth.

A desirable objective is to distinguish between "self-congestion" and
"inter-user congestion" so that users could use a mechanism external to
conex to "go faster" in the event that only "self-congestion" is limiting
their throughput.

If the user sends at more than the shaper 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." There is also the case when
congestion occurs at a shared resource, which causes
"inter-user-congestion," where congestion volume from one user impacts other
users. Note that "Self-Congestion" can occur when "Inter-User Congestion"
occurs. However, a heavier user may not create "self-congestion" (i.e., loss
or ECN marking) if that user sends at slightly less than a shaper peak rate
(e.g., using LEDBAT). 

There are (at least) three approaches for addressing this issue. Approaches
1, 2.a require no change to the conex abstract mechanism
[wg-abstract-mechanism]. Approach 2.b would require signaling of additional
information to the receiver (could be done separately from conex), and
approach 3 may be able to use the conex abstract mechanism, albeit
potentially in a different configuration. 

1. Treat "self-congestion" the same as "inter-user congestion" since they
both create congestion as perceived by the flow user.

the remedy differs:

  b. For a queue dedicated to a receiver (e.g., shaper) signal information
that the shaper peak rate is the bottleneck to the receiver, so that somehow
(specific mechanism may not fit within the current conex wg charter) the
user could make a request to "go faster."

3. Process and generate conex information at the network element which
implements the shaper, which has knowledge of the configured peak rates for
the users as well as local shared resource congestion. This network element
can also use information about upstream shared resource congestion as
delivered buy the conex protocol.

Note that during busy periods "self congestion" may not be the limiting
factor, but during non-busy periods it will be the biggest source of
apparent congestion.

[Editorial Note from Dave: The following was derived list comments as well
as a private input from Toby Moncaster.]

The following scenario assumes that all user flows implement conex. The case
where not all flows implement conex still needs to be addressed. (Some form
of localized "conex-like" marking may handle this case, since heavier users
may have a significant incentive to not implement conex). Also to be
addressed is the scenario where heavy users do not create congestion (e.g.,
using LEDBAT), but there is still a significant difference in average rate,
or burstiness (peak/average).

Using the abstract mechanism a heavier user  never gets a chance to build up
any congestion credit, which will not impact their service during non-busy
periods. However, at peak times it means their service is degraded long
before a light user sees any impact. In turn this means the congestion seen
by the light user is less, meeting an important objective. 

Additional local computations are done as follows. Over a  time period
related to the statistical multiplexing interval (e.g., many seconds to
minutes to hours) total up the number of bytes that have been congestion
marked and the total number of bytes sent per user. Compute the ratio of
congested bytes to total bytes. 

The total is a measure of the average rate per user (averaged over the time
period of the total).

For example, quantizing users into classes using one threshold on total and
and another threshold on ratio results in a grid that identifies four
distinct classes of user as follows:

|   Total volume>|             |             |

An additional congestion measure of burstiness (e.g., ratio of peak rate to
average rate over a longer interval than the tiered bandwidth shaper) would
allow nodes upstream from the node implementing the shaper to implement
traffic management. This measure could be derived from signals in the
abstract mechanism but would require (a majority) of the heavier senders and
receivers to implement conex and also would only work if loss or ECN marking
occurs. Heavier users may have a significant incentive to not implement
conex, and some additional mechanism to address this issue may be required.
Also, signaling a measure of the burstiness (or something related to it)
would address the scenario where no loss or ECN marking occurs.

As an alternative, if a "light weight" TCP proxy were implemented at the
network element containing the shaper (e.g., an access router) and an
upstream network element (e.g., a router at ingress to the service provider
network), then potentially a conex control loop could be created between
these network elements to provide fairer treatment between heavier and
lighter users during congested intervals. In this case, a subset of conex
features could potentially be used since this would be a closed domain where
the signals could be implicitly trusted. The burstiness measure could be
communicated using TCP extensions between these proxies.

There is also the aspect of "self congestion" when a non-work conserving
scheduler (e.g., shaper) is employed at the access node. Even when
"inter-user congestion" is not occurring (e.g., during a non-busy period),
"self congestion" may occur. However, as discussed in the section on "Self
Congestion versus Inter-User Congestion," using current mechanisms (i.e.,
implicitly determined loss or ECN marking) the receiver cannot tell the
difference between "self-congestion" and "inter-user congestion." Adding a
signal to the abstract mechanism could be quite useful so that a receiver
can inform the sender regarding the cause of congestion, and enable the
sender (or the receiver) to communicate with the network element controlling
the shaper parameters enabling the flow to "go faster." using some non-conex
mechanism.

---------------------

Acknowledgements

Add the following:  Stuart Venters, Mikael Abrahamsson, Mirja Kuehlewind,
João Taveira Araújo, Caitlin Bestler, Steven Bauer, …

[Editorial Note: My thanks for inputs from authors, folks already listed in
Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich Woundy,
…]

References

[DSL Forum TR-059] Technical Report DSL Forum TR-059, "DSL Evolution -
Architecture Requirements for the Support of QoS-Enabled IP Services,"
September 2003, http://www.broadband-forum.org/technical/download/TR-059.pdf

[Varian] Hal Varian, Google, "Congestion pricing principles," IETF 78
Technical Plenary, 29 July 2010

[Bauer] Steven Bauer, David Clark, William Lehr,  "The Evolution of Internet
Congestion," Massachusetts Institute of Technology, 2009

---

From: John Leslie <[email-masked]>
Date: Fri, 4 Mar 2011 15:43:35 -0500

Mcdysan, David E <[email-masked]> wrote:
>...

   Thanks to Dave for the effort to put this together -- it's a real
challenge to organize one's thoughts on something this complex.

   Nonetheless, I found it quite hard to understand, largely because of
mixing ideas and lack of definitions of some important terms.

   I volunteer to give it an editing pass this weekend; and will send
the result privately to Dave before posting to the list.

   In particular:

- I quite despair of defining "fairness" -- I think it a lost cause, and
  will try to substitute "economic congestion" where that seems to be
  the intent.

- "congestion" seems to be used in several different senses. I will try
  to substitute "queue filling" where that is appropriate.

- I'm not sure there is a need to separate out Approach 2a from 2b.
  The distinction is very confusing to me. I'll edit it out and we can
  see whether it needs to go back in (but later in the presentation).

- I believe that re-ordering the presentation can cut the number of
  words considerably at the same time it becomes easier for the average
  reader to grok.

- As I proceed, I'll put some questions to Dave privately. If Dave and
  I fail to reach agreement, most of these will probably be posted to
  the list later.

   This is an editing pass only -- not an attempt to push my views on
the issues involved. I'm likely to raise that sort of questions later.

--
John Leslie <[email-masked]>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 8 Mar 2011 13:24:25 +0100

Hi David,

sorry, reading the text I really don't see the problems you are talking about:

1. self-congestion vs. inter-user congestion
- First, there is no difference between having a shaper or having a limited 
access bandwidth. 
- Second, the principle of TCP congestion control is to probe for available 
bandwidth until congestion occurs. That's nothing bad because thats the only 
feedback TCP has. And as long as you are alone on the link, the number of 
losses/marking will be very small. If you even want to avoid these congestion 
markings than you can go for something like LEDBAT which will keep the queue 
small and no congestion will occur. If there is only self-congestion its 
under the user's control how much congestion he/she will cause. Where's the 
problem?

2. heavy vs. light users
Heavy user in general are not a problem, only heavy unresponsive user are. And 
heavy unresponsive user will have a high congestion volume (whereas light or 
LEDBAT user will have a small congestion volume). Thus the congestion volume 
given by the ConEx mechanism is the only metric needed to figure out who are 
the bad guys!

3. congestion vs. congestion volume
Somewhere your text is saying "The result is that all users see the same 
congestion...". That's not true. The point is that a heavy unresponsive user 
is seeing more losses/marking than a light user because he/she is sending 
with a higher rate over a longer period of time. ConEx is not only giving a 
notification that there has been a congestion event, ConEX is giving a 
congestion volume. And if you have dropper the ones with a high congestion 
volume will consume their allowances quickly and will be penalized by the 
dropper afterwards. Thus if you have ConEX you can have a dropper instead of 
the shaper and this will actually allow you to penalize the bad guys (whereas 
a shaper will penalize the heavy users, which is the wrong metric as e.g. 
LEDBAT user are nice guys). 

Mirja

On Friday 04 March 2011 17:37:37 Mcdysan, David E wrote:
> people whose inputs I used to draft this text and am requesting the
> use-case draft authors to include your names in the Acknowledgement section
> (if it was not already there).
>
> The access network is usually not provisioned and traffic engineered for
> the peak rate for all users but is instead provisioned assuming statistical
> periods, the service provider network is underutilized and hence there is
> no congestion of shared resources.
>
> During busy periods where congestion (i.e., loss or ECN marking) of a
> shared resource (e.g., a queue or scheduler) can occur, heavier users may
> send at speeds up to the peak rate while lighter users may send at a rate
> much less than the peak rate. The result is that all users see the same
> congestion (i.e., loss or ECN marking probability) although the lighter
> users are sending at much less than the peak rate. Furthermore, when the
> shared resource is congested, heavy users create much more congestion
> volume than light users. In this sense, the response of current networks is
> "unfair," which is also called "economic congestion" [section 3.4, Bauer].
>
> In many networks a non work conserving scheduler (e.g., a shaper)
> implements a per-user peak rate over an interval O(100 ms). See Appendix B
> of [DSL Forum TR-059] for a DSL specific example of non-work conserving
> schedulers. Similar techniques are used in access network equipment across
> a range of access technologies. Thus, the "bandwidth tier" incentive is
> that a user pays more if he/she wants more peak rate bandwidth.
>
> A specific objective is to distinguish heavier users from lighter users
> over a the statistical multiplexing time interval that can range from
> seconds, to minutes, to hours so that network provider traffic management
> functions can provide "fairer" allocation of bandwidth.
>
> congestion at a shared resource, then other users are not impacted, and in
> a sense this user creates "self-congestion." There is also the case when
> "inter-user-congestion," where congestion volume from one user impacts
> other users. Note that "Self-Congestion" can occur when "Inter-User
> Congestion" occurs. However, a heavier user may not create
> "self-congestion" (i.e., loss or ECN marking) if that user sends at
> slightly less than a shaper peak rate (e.g., using LEDBAT).
>
> that the shaper peak rate is the bottleneck to the receiver, so that
> somehow (specific mechanism may not fit within the current conex wg
> charter) the user could make a request to "go faster."
>
> The following scenario assumes that all user flows implement conex. The
> case where not all flows implement conex still needs to be addressed. (Some
> form of localized "conex-like" marking may handle this case, since heavier
> users may have a significant incentive to not implement conex). Also to be
> Using the abstract mechanism a heavier user  never gets a chance to build
> up any congestion credit, which will not impact their service during
> non-busy periods. However, at peak times it means their service is degraded
> long before a light user sees any impact. In turn this means the congestion
> seen by the light user is less, meeting an important objective.
>
> abstract mechanism but would require (a majority) of the heavier senders
> and receivers to implement conex and also would only work if loss or ECN
> marking occurs. Heavier users may have a significant incentive to not
> implement conex, and some additional mechanism to address this issue may be
> required. Also, signaling a measure of the burstiness (or something related
> to it) would address the scenario where no loss or ECN marking occurs.
>
> features could potentially be used since this would be a closed domain
> where the signals could be implicitly trusted. The burstiness measure could
> be communicated using TCP extensions between these proxies.
>
> sender (or the receiver) to communicate with the network element
> controlling the shaper parameters enabling the flow to "go faster." using
> some non-conex mechanism.
>
>
> ---------------------
>
> September 2003,
> http://www.broadband-forum.org/technical/download/TR-059.pdf
>
> [Bauer] Steven Bauer, David Clark, William Lehr,  "The Evolution of
> Internet Congestion," Massachusetts Institute of Technology, 2009

-- 
-------------------------------------------------------------------
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: Tue, 8 Mar 2011 09:53:17 -0500

Hi Mirja,

Some responses in line in attempt to understand your points and identify
where existing conex mechanisms solve some of the problems and highlight
those which are (not yet) completely solved.

Thanks,

Dave

>- First, there is no difference between having a shaper or having a

I think we tried to capture this point of view in item 1 in section X.2,
but I am not sure if I understand your statement completely.

"Treat "self-congestion" the same as "inter-user congestion" since they
both create congestion as perceived by the flow user."

There were other points of view expressed on the list which were captured
in points 2 and 3. Please review those.

What I am seeing is that people have different perspectives based upon
their experience and motivations. IMHO, it is OK if not all people have
the same the same opinion on the relevance of use cases. If we used the
reasoning that everyone had to agree on each use case, then we could end
up with very few use cases. For example, a number of people have expressed
the point of view that policing is unnecessary and should not be done for
various reasons. Should we remove the policing use case based upon this
reasoning?

>losses/marking will be very small.

Not if the rate exceeds the bottleneck.

>If you even want to avoid these congestion

See X.2 case 2b. A user could request to "go faster."
>given by the ConEx mechanism is the only metric needed to figure out who

Section X.3 (largely written by Toby) tries to capture similar reasoning
of how the current mechanisms could be used. I think adding text on how
best to address unresponsive users to that section would be good.

X.3 also mentions the case where heavy users do not create congestion as
currently defined in conex (I.e., loss, ECN marking) which is not covered
in the current mechanism.

>congestion...". That's not true.

See definitions in section 3 - Congestion = probability of loss or (ECN)
marking. Using this definition the above statement is true.

>The point is that a heavy unresponsive user
>with a higher rate over a longer period of time.

I think what you may mean is that congestion volume (as defined in section
3 (this definition could use some clarification)) differs between
heavy/light users, with which I agree.

>ConEx is not only giving a

I think this general approach could be used to expand X.3 and refer the
"dropper" (I think this is called ingress policing, or traffic management
in the current draft). We also have the issue with this approach mentioned
earlier that some wg members have expressed the opinion that they don't
want to implement policers. I am OK listing this as an option for
operators, for the reasons mentioned above.

However, there are still the unresolved problems of unresponsive users and
those who do not create observable congestion (as it is currently defined).

>> João Taveira Araújo, Caitlin Bestler, Steven Bauer, Š
>>
>> Š]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 8 Mar 2011 18:16:55 +0100

Hi Dave,

I'm not saying that there are no further use cases and there are definitely  
relevant discussions on the list. There are also points of your draft which 
should definitely included into the use case draft. But the text you just 
provided kind of confused me; I still try to figure out what the actual 
problem is your use cases will solve. 

> both create congestion as perceived by the flow user."
I'm just saying that there is "self-congestion" because that's the way TCP is 
designed. There will be "self-congestion" with a shaper or without. 

> various reasons. Should we remove the policing use case based upon this
Yes, it is okay to have different opinion about the relevance of a use case. 
But I'm still one step before that. I don't understand the problem which your 
use case(s) could solve. As long as there is no problem, there is no use case 
from my point of view. And if there is no use case at all, we don't need to 
talk about the relevance. 
Again, don't get me wrong, I think there are valid points in the draft you 
presented, but a can't really follow the text you just sent.

> Not if the rate exceeds the bottleneck.
If the sending rate exceeds the bottleneck rate, yes, there will be 
losses/markings but the number of losses/marking will be small if TCP 
congestion control is used (in the self-congestion case). Actually there will 
be exactly one loss per loss event with TCP Reno.
In the case of inter-user congestion, e.g. a second flow is slow-starting, 
there will be more losses/marking.

> See X.2 case 2b. A user could request to "go faster."
The user could also request a higher congestion allowance, but this is a 
signaling mechanism on top of ConEx. Let's first design ConEx! 

> best to address unresponsive users to that section would be good.
There is no need for 4 different types of users. You only have the nice guys, 
who are responsive or anyway just light users or you have the bad guys, who 
are unresponsive and disturb other users.

> in the current mechanism.
Because the differentiation on heavy user and light user is the wrong metric. 
You only need to distinguish between responsive and unresponsive or even 
better between high and low congestion volume.

> marking. Using this definition the above statement is true.
No because heavy unresponsive users (which means high sending rate over a long 
period of time) have a higher probability. Thus they don't see the same 
congestion, they see more marking than a light user (and the quantity is 
important here). Which is perfectly fine.

> operators, for the reasons mentioned above.
Sorry I meant policer. 

> those who do not create observable congestion (as it is currently defined).
Which problem? ConEx will give you exactly the information needed to 
distinguish those two classes of user. There is no additional mechanism 
needed!

I have the feeling that in the text you provided, there are several points 
mixed up. Maybe we can try to separate them again in smaller parts...?

Mirja 

tel: +49(0)711/685-67973

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 8 Mar 2011 12:36:46 -0500

Hi Mirja,

John Leslie had some trouble understanding the problem statement and I am
working on a substantial rewrite with him. He had difficulty understanding
some of this text. Also, he had some perspectives that differed from mine,
which in the spirit of including all points of view I am OK with him
adding these.

Would probably be best to wait on his rewrite and continue the discussion
based upon that text which will hopefully have better descriptions of
concepts such as "self congestion." From your responses it appears that
you have a different interpretation than what was discussed  on the list,
which the text I wrote did not make clear.

It also appears that you are considering the specific case where all flows
employ conex, where the current use case draft includes the case where not
all flows use conex, which needs to be addressed in some way as well.

A few responses in line below.

Thanks,

Dave

>designed. There will be "self-congestion" with a shaper or without.

This seems like a definitional issue that may be the root of confusion.
Let's look at John's rewrite to understand terminology first.
>> >heavy unresponsive user will have a high congestion volume (whereas
>>light
>> >or
>> >given by the ConEx mechanism is the only metric needed to figure out
>>who
>> >are
>> >the bad guys!
>>
>> >dropper afterwards. Thus if you have ConEX you can have a dropper
>>instead
>> >of

John's rewrite may help here, but looking over the use case draft some of
the parts overlap with existing use cases. There are actually two
important cases that are combined here as well - no per user shapers and
per user shapers that certainly could be separated.
>> >> As documented in the IETF79 Beijing meeting minutes it was agreed
>>that
>> >>the
>> >> pricing is in place. A simplifying assumption is made that there is
>>no
>> >>very
>> >> resource sharing [Varian], often without paying any extra for doing
>>so
>> >>when
>> >> which this difference in traffic volume exists can range from
>>seconds,
>> >>to
>> >> periods, the service provider network is underutilized and hence
>>there
>> >>is
>> >> need to be considered in the set of conex use cases. Further
>>discussion
>> >>on
>> >> congestion at a shared resource, then other users are not impacted,
>>and
>> >>in
>> >> implements the shaper, which has knowledge of the configured peak
>>rates
>> >>for
>> >> users may have a significant incentive to not implement conex). Also
>>to
>> >>be
>> >> The total is a measure of the average rate per user (averaged over
>>the
>> >>time
>> >> period of the total).
>> >>
>> >> For example, quantizing users into classes using one threshold on
>>total
>> >>and

---

From: STUART VENTERS <[email-masked]>
Date: Tue, 8 Mar 2011 19:28:27 +0000

Mirja,

"- First, there is no difference between having a shaper or having a limited access bandwidth. "

A couple of possible differences are:

  Who sets the policies for the buffers behind the restriction.
    For example a customer's router might have priority queueing for specific traffic heading to the cloud.

  A shaper may allow for bursts whereas with a physical link you just get what you got.

Regards,

Stuart

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind
Sent: Tuesday, March 08, 2011 6:24 AM
To: [email-masked]
Subject: Re: [conex] Proposed Text for New Section in Use Case Draft - Statistical multiplexing over Longer Timescales

Hi David,

1. self-congestion vs. inter-user congestion
- First, there is no difference between having a shaper or having a limited access bandwidth.
- Second, the principle of TCP congestion control is to probe for available bandwidth until congestion occurs. That's nothing bad because thats the only feedback TCP has. And as long as you are alone on the link, the number of losses/marking will be very small. If you even want to avoid these congestion markings than you can go for something like LEDBAT which will keep the queue small and no congestion will occur. If there is only self-congestion its under the user's control how much congestion he/she will cause. Where's the problem?

2. heavy vs. light users
Heavy user in general are not a problem, only heavy unresponsive user are. And heavy unresponsive user will have a high congestion volume (whereas light or LEDBAT user will have a small congestion volume). Thus the congestion volume given by the ConEx mechanism is the only metric needed to figure out who are the bad guys!

3. congestion vs. congestion volume
Somewhere your text is saying "The result is that all users see the same congestion...". That's not true. The point is that a heavy unresponsive user is seeing more losses/marking than a light user because he/she is sending with a higher rate over a longer period of time. ConEx is not only giving a notification that there has been a congestion event, ConEX is giving a congestion volume. And if you have dropper the ones with a high congestion volume will consume their allowances quickly and will be penalized by the dropper afterwards. Thus if you have ConEX you can have a dropper instead of the shaper and this will actually allow you to penalize the bad guys (whereas a shaper will penalize the heavy users, which is the wrong metric as e.g.
LEDBAT user are nice guys).

Mirja

On Friday 04 March 2011 17:37:37 Mcdysan, David E wrote:
> Hi,
>
> As documented in the IETF79 Beijing meeting minutes it was agreed that
> the concepts from the section titled "Inequity of Heavy versus Light Users"
> several other threads that are not addressed by this proposed text),
> Toby proposed adding a new section to the use case draft and I
> volunteered to draft content based upon the original draft as well as
> the relevant list discussion from the thread titled "Discussion of new
> Use Cases pt 1," along with relevant text from the spawned threads. I
> tried to list all of the people whose inputs I used to draft this text
> and am requesting the use-case draft authors to include your names in
> the Acknowledgement section (if it was not already there).
>
> The title of the proposed new section X has been changed to represent
> the principal aspects of the use case, namely statistical multiplexing
> over longer timescales.
>
> Thanks,
>
> Dave
> pricing is in place. A simplifying assumption is made that there is no
> very long term (e.g., monthly) usage tier pricing in place.
>
> The principal problem addressed by this use case is that 20% of the
> users generate 80% of the traffic volume and create unfairness with
> certain resource sharing [Varian], often without paying any extra for
> doing so when "flat rate" or "bandwidth tier" pricing is in effect.
> The timescale over which this difference in traffic volume exists can
> range from seconds, to many minutes to hours. The peak rate at which a
> user can send may be set by the physical transmission system, a
> non-work conserving scheduler, and/or a policer.
>
> The access network is usually not provisioned and traffic engineered
> for the peak rate for all users but is instead provisioned assuming
> statistical multiplexing where a longer term (many seconds to minutes
> to hours) average capacity is assumed for all users during the busy
> period. The many minutes timescale is commonly used by network
> operators to determine when a portion of a network is near congestion
> [section 3.3, Bauer]. During non-busy periods, the service provider
> network is underutilized and hence there is no congestion of shared resources.
>
> shared resource (e.g., a queue or scheduler) can occur, heavier users
> may send at speeds up to the peak rate while lighter users may send at
> a rate much less than the peak rate. The result is that all users see
> the same congestion (i.e., loss or ECN marking probability) although
> the lighter users are sending at much less than the peak rate.
> Furthermore, when the shared resource is congested, heavy users create
> much more congestion volume than light users. In this sense, the
> response of current networks is "unfair," which is also called "economic congestion" [section 3.4, Bauer].
>
> The above situation occurs in flat rate pricing where all user flows
> share the same resource (e.g., queue, scheduler).
>
> implements a per-user peak rate over an interval O(100 ms). See
> Appendix B of [DSL Forum TR-059] for a DSL specific example of
> non-work conserving schedulers. Similar techniques are used in access
> network equipment across a range of access technologies. Thus, the
> "bandwidth tier" incentive is that a user pays more if he/she wants more peak rate bandwidth.
>
> Such non-work conserving schedulers create apparent congestion (i.e.,
> loss or ECN marking) within their queue(s) which impact only a single
> user that need to be considered in the set of conex use cases. Further
> discussion on this topic is covered in the section "Self-Congestion
> versus Inter-User Congestion."
>
> delivered in proportion to the user peak rate when congestion of a
> shared resource occurs.
>
> A specific objective is to distinguish heavier users from lighter
> users over a the statistical multiplexing time interval that can range
> from seconds, to minutes, to hours so that network provider traffic
> management functions can provide "fairer" allocation of bandwidth.
>
> "inter-user congestion" so that users could use a mechanism external
> to conex to "go faster" in the event that only "self-congestion" is
> limiting their throughput.
>
> and in a sense this user creates "self-congestion." There is also the
> case when congestion occurs at a shared resource, which causes
> There are (at least) three approaches for addressing this issue.
> Approaches 1, 2.a require no change to the conex abstract mechanism
> [wg-abstract-mechanism]. Approach 2.b would require signaling of
> additional information to the receiver (could be done separately from
> conex), and approach 3 may be able to use the conex abstract
> mechanism, albeit potentially in a different configuration.
>
> 1. Treat "self-congestion" the same as "inter-user congestion" since
> they both create congestion as perceived by the flow user.
>
> 2. Signal more information to the receiver about the cause of loss
> since the remedy differs:
>   a. For a shared queue, use current draft of abstract mechanism
> signals to reduce load and choose packets for different treatments.
>   b. For a queue dedicated to a receiver (e.g., shaper) signal
> information that the shaper peak rate is the bottleneck to the
> receiver, so that somehow (specific mechanism may not fit within the
> current conex wg
> rates for the users as well as local shared resource congestion. This
> network element can also use information about upstream shared
> resource congestion as delivered buy the conex protocol.
>
> Note that during busy periods "self congestion" may not be the
> limiting factor, but during non-busy periods it will be the biggest
> source of apparent congestion.
>
> [Editorial Note from Dave: The following was derived list comments as
> well as a private input from Toby Moncaster.]
>
> The following scenario assumes that all user flows implement conex.
> The case where not all flows implement conex still needs to be
> addressed. (Some form of localized "conex-like" marking may handle
> this case, since heavier users may have a significant incentive to not
> implement conex). Also to be addressed is the scenario where heavy
> users do not create congestion (e.g., using LEDBAT), but there is
> still a significant difference in average rate, or burstiness (peak/average).
>
> Using the abstract mechanism a heavier user  never gets a chance to
> build up any congestion credit, which will not impact their service
> during non-busy periods. However, at peak times it means their service
> is degraded long before a light user sees any impact. In turn this
> means the congestion seen by the light user is less, meeting an important objective.
>
> related to the statistical multiplexing interval (e.g., many seconds
> to minutes to hours) total up the number of bytes that have been
> congestion marked and the total number of bytes sent per user. Compute
> the ratio of congested bytes to total bytes.
>
> total and and another threshold on ratio results in a grid that
> identifies four distinct classes of user as follows:
>
> An additional congestion measure of burstiness (e.g., ratio of peak
> rate to average rate over a longer interval than the tiered bandwidth
> shaper) would allow nodes upstream from the node implementing the
> shaper to implement traffic management. This measure could be derived
> from signals in the abstract mechanism but would require (a majority)
> of the heavier senders and receivers to implement conex and also would
> only work if loss or ECN marking occurs. Heavier users may have a
> significant incentive to not implement conex, and some additional
> mechanism to address this issue may be required. Also, signaling a
> measure of the burstiness (or something related to it) would address the scenario where no loss or ECN marking occurs.
>
> As an alternative, if a "light weight" TCP proxy were implemented at
> the network element containing the shaper (e.g., an access router) and
> an upstream network element (e.g., a router at ingress to the service
> provider network), then potentially a conex control loop could be
> created between these network elements to provide fairer treatment
> between heavier and lighter users during congested intervals. In this
> case, a subset of conex features could potentially be used since this
> would be a closed domain where the signals could be implicitly
> trusted. The burstiness measure could be communicated using TCP extensions between these proxies.
>
> There is also the aspect of "self congestion" when a non-work
> conserving scheduler (e.g., shaper) is employed at the access node.
> Even when "inter-user congestion" is not occurring (e.g., during a
> non-busy period), "self congestion" may occur. However, as discussed
> in the section on "Self Congestion versus Inter-User Congestion,"
> using current mechanisms (i.e., implicitly determined loss or ECN
> marking) the receiver cannot tell the difference between
> "self-congestion" and "inter-user congestion." Adding a signal to the
> abstract mechanism could be quite useful so that a receiver can inform
> the sender regarding the cause of congestion, and enable the sender
> (or the receiver) to communicate with the network element controlling
> the shaper parameters enabling the flow to "go faster." using some non-conex mechanism.
>
>
> ---------------------
>
> Add the following:  Stuart Venters, Mikael Abrahamsson, Mirja
> Kuehlewind, João Taveira Araújo, Caitlin Bestler, Steven Bauer, ...
>
> Acknowledgements: Toby Moncaster, John Leslie, Alissa Cooper, Rich
> Woundy, ...]
>
> References
>

--
-------------------------------------------------------------------
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
-------------------------------------------------------------------
_______________________________________________
conex mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/conex

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 10 Mar 2011 09:36:00 -0500

Hi Mirja,

I was thinking about your comment below after looking for references on
the "heavy user" problem and think there are at least two smaller problems.

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

I know that John had concerns regarding the length of the text and
splitting it along the above lines would make understanding and discussion
easier. I think that the text I submitted can be split into two along the
above lines.

Thanks,

Dave

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 11 Mar 2011 14:30:54 +0100

Hi Dave,

thanks a lot. This makes the points much clearer. 

I believe that point 1) is already addressed in 5.1. ConEx as a basis for 
traffic management:

  "... In order to ensure all
   customers get some chance to access the network, the "heaviest"
   customers will be subjected to some form of traffic management at
   peak times (typically a rate cap for certain types of traffic)
   [Fair-use].  Often this traffic management is done with expensive
   flow aware devices such as DPI boxes or flow-aware routers.

   ConEx offers a better approach that will actually target the users
   that are causing the congestion..."

Your point 2), for me, still looks like an mechanism on top of ConEx and thus 
it might be out of scope. Can you phrase based on this use case any new 
requirements for the abstract mechanism design?

Mirja

tel: +49(0)711/685-67973

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 11 Mar 2011 11:48:04 -0500

Hi Mirja,

Some responses in line below.

Dave

>   that are causing the congestion..."

I would say partially addressed, the actual "economic congestion" problem
is not mentioned at all.

Editorially, this 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).

>it might be out of scope.

As I an others have posted, the conex use case document at least needs to
mention the presence of shapers and whether they are in or out of scope.
Specifically, the current text in section 4 seems to say they are out of
scope 

"congestion means that your traffic impacts other users, and conversely
that their traffic impacts you."

However, as a number of wg members have posted, shapers will cause effects
that will appear as congestion.

I would like to see the wg agree on whether this either in or out of scope
-- you  keep making the same point about scope. If you look at the list
several others have said this case at least needs to be described in the
draft, but have expressed concerns as to whether the complexity of adding
to the mechanism will justify the benefit.

Can you please say more as to why you believe it is out of scope.

>Can you phrase based on this use case any new

If the wg decides inclusion of discussion of this use case is in scope,
then I can do this. You seem to be the only person saying it is absolutely
out of scope.

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 15 Mar 2011 11:28:47 +0100

Hi Dave,

> Can you please say more as to why you believe it is out of scope.
I don't say shapers are out of scope. But I don't really see the special case 
about shapers. If they mark or drop a packet, I have to take it as a 
congestion signal because I anyway don't know what in the network and why it 
doing this...

If you want an additional signaling for shaper congestion, I believe that is 
independent of ConEx. Its like having another kind of ECN signal. You can 
simply specify such an additional signaling protocol (every time in the 
future) and add a section how ConEx senders should react to it. I don't 
believe this will change the ConEx mechanism itself. But I'm open for a 
discussion here. But first of all we have to figure out if there is a special 
case about shapers. I still believe no.

The other point is, I'm saying that a mechanism to say "go faster" is out of 
scope. I think a mechanism like this really makes sense (with shapers or 
based on the ConEx signal -> saying "please more ConEx allowance"). But again 
this signaling protocol between the sender and a first hop in the network, 
e.g. the B-RAS, is either independent of ConEx or on top of ConEx. Which 
would mean that we have to standardize ConEx first before we can design 
something on top. This point is clearly something which I believe would make 
sense to recharter for at some point in the future. That is why I proposed to 
keep this case alive in a separate draft.

Mirja

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 15 Mar 2011 09:23:46 -0400

Hi Mirja,

The premise of your scope argument appears to be that a behavior is not
defined in the current abstract mechanism draft. I thought we had
discussion related to this definition of scope in Beijing as documented in
the meeting minutes, which I sent out in response to Alissas' description
on 3/4/11 of Approach 1 and 2. You appear to be pursuing approach 1. I
excerpt the relevant portion of the meeting minutes again below:

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

Snipped

 "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.
          
          RW - agree with LD, adopting this would break the logjam.
appendix of
          moncaster use cases draft could move into this draft. then other
use
          cases could build on that."

I had interpreted silence from the chair, Marcelo Bagnulo (MB), as
consensus when I posted my response to Alissa on 3/4. You seem to be
revisiting the same issue.

Specifically, for the use cases document, I interpret the above as use
cases that would be built upon Conex are in scope. Furthermore, use cases
that do not use currently defined abstract mechanisms are in scope as
well. 

Marcelo, and area directors, please discuss and this time please respond
so that the working group can understand scope and have a common
interpretation of what was agreed in IETF 79, Beijing.

Then, for things that are in scope, the working group can have a technical
discussion.

Thanks,

Dave

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 28 Mar 2011 10:53:12 +0100

Mirja,

I just (late as always) noticed this statement that I have to 
challenge, because it misses the whole essence of ConEx IMO:

>- First, there is no difference between having a shaper or having a limited

There is a world of difference.

If I have 40Mb/s limited access bandwidth on a shared network (e.g. 
cable, or a PON), it's because the operator has to limit my peak 
information rate in order to give other users a committed information rate.

If the operator has ConEx signalling and a ConEx policer in its 
toolkit, if the underlying access link has a physical capacity of 
1Gb/s (say), the operator can allow each customer 1Gb/s peak, not 40Mb/s.

Obviously, if many are trying to use 1Gb/s all at once, they won't 
all be able to use 1Gb/s each. But then, if they don't respond 
themselves (which they normally would) the Congestion policer will 
limit them to a fair share of the network, where 'fair' will depend 
on their long term behaviour in response to congestion, not just instantaneous.

Lesson: We shouldn't assume that MAC layer policies will always 
reflect the way networking was done before the operator could see 
congestion. MAC layer sharing policies are generally possible to 
change at a single point.

Then ConEx could make traffic patterns on a public access network 
much more like on a LAN: with faster transfer bursts that finish 
sooner, so the next one can burst faster.

One could say this hasn't been proved in practice. But when you're on 
a campus LAN accessing some data centre over the Internet, this is 
how things have always worked (except you don't have a ConEx policer 
to limit heavy contributors to congestion).

Bob

PS. Assuming you mean shaper = congestion policer (please can we stop 
using the word "shaper")

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Don Bowman <[email-masked]>
Date: Mon, 28 Mar 2011 10:46:53 +0000

...

> PS. Assuming you mean shaper = congestion policer (please can we stop

FWIW, we use the term 'shaper' as something which has (sometimes large) 
buffering, and is conditioning something of about the right rate into a 
specific output. In general use a shaper doesn't drop much packets,
and is used to gasket a peaky-network into a non-peaky network.

A policer on the other hand forces a peak rate strictly, dropping above it.

So there is indeed another big difference between a limited access bandwidth
(e.g. physically capable of some rate) vs one that is 'shaped' or 'policed'.

In the 'MAC limit' sense, the only latency introduced is that of the MAC-layer
buffers. In e.g. Cable modem this can be pretty significant, often 
64KB @ e.g. 1Mbps == ~1/2s latency.

In the properly-setup shaper case, the latency introduced due to buffering
is something like 2x the jitter of the upstream.

In the (strict) policer case, the latency introduced is 0, and all peaks are 
discarded.

--don