Subject: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC

From: Bob Briscoe <[email-masked]>
Date: Wed, 06 Jul 2011 11:57:01 +0100

ConEx folks,

The proposed table of contents for draft-02 is pasted at the end.
Please react if you object. There will be controversy, but please try 
to recognise that we ought to be converging now.

Here's the rationale for the changes.

2.  Definitions -> Concepts

The "Definitions" section in draft-01 actually introduced the main 
concepts, which is goal #1 of this doc. So Concepts is a better 
section heading.
Then we've added the much-discussed Misconceptions sub-section 
clarifying it's not misconceptions about networking, just about ConEx.

5.  ConEx Use Cases
Removed one use-case (Accounting for Congestion Volume) but really 
just moved it to "Other Use-Cases" so it can be much shorter.

Under "Other Use-Cases", we propose very brief bullets on each of:
* Preventing congestion collapse
* Accounting for congestion
* Interconnection traffic contracts
* Provisioning capacity

The idea is to resolve all the to-and-fro about which use-cases 
should be in or out, by having a "half-in" category.

And possibly (controversial!) we could then even add...
* Mitigating flooding attacks

Note also the change of heading:
      5.3.  ConEx for Intra-Class Quality of Service (QoS)
We'll change the story to emphasise that ConEx doesn't replace 
Diffserv, but it could handle allocation of resources within a class 
(ie bandwidth allocation as opposed to queue scheduling).

6. Deployment Arrangements.

Replaces previous S.5.5.  Partial vs. Full Deployment

It's tough to talk about deployment in a mechanism-neutral way (given 
deployment is about deploying mechanisms!). Nonetheless, the idea is 
to give a plausible story for how the previously mentioned use-cases 
would get incrementally deployed. So it fits in this doc, but it will 
be tough. We have summarised stuff about components and incremental 
deployment in abstract-mech first (I intend to post proposed new text 
for this section to the list shortly).

7.2.  Self Congestion

Rather than diving straight into this detailed area early in the 
Introduction, we've moved it to where it belongs: under 7. Potential Issues.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
      2.2.  Common Misconceptions about ConEx  . . . . . . . . . . . .  7
    3.  Traffic Management . . . . . . . . . . . . . . . . . . . . . .  7
      3.1.  Existing Approaches  . . . . . . . . . . . . . . . . . . .  8
    4.  Exposing Congestion  . . . . . . . . . . . . . . . . . . . . .  9
      4.1.  ECN - a Step in the Right Direction  . . . . . . . . . . . 10
    5.  ConEx Use Cases  . . . . . . . . . . . . . . . . . . . . . . . 11
      5.1.  ConEx as a basis for traffic management  . . . . . . . . . 11
      5.2.  ConEx to incentivise scavenger transports  . . . . . . . . 11
      5.3.  ConEx for Intra-Class Quality of Service (QoS) . . . . . . 12
      5.4.  Other Use-Cases  . . . . . . . . . . . . . . . . . . . . . 13
    6.  Deployment Arrangements  . . . . . . . . . . . . . . . . . . . 13
      6.1.  Deployment Concepts  . . . . . . . . . . . . . . . . . . . 13
      6.2.  Single Receiving Network Scenario  . . . . . . . . . . . . 14
      6.3.  Other Initial Deployment Scenarios . . . . . . . . . . . . 14
    7.  Potential Issues . . . . . . . . . . . . . . . . . . . . . . . 14
      7.1.  Congestion as a Commercial Secret  . . . . . . . . . . . . 14
      7.2.  Self Congestion  . . . . . . . . . . . . . . . . . . . . . 15
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
      8.1.  Information Security . . . . . . . . . . . . . . . . . . . 16
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
    10. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
    11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
      11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 18
    12. Informative References . . . . . . . . . . . . . . . . . . . . 18
    Appendix A.  Changes from previous drafts (to be removed by
                 the RFC Editor) . . . . . . . . . . . . . . . . . . . 19
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Cheers

Bob (& discussed with Rich as co-editor, but still some uncertainties 
- hence asking the list for views)

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Thu, 7 Jul 2011 14:13:03 +0100

Bob,

On the Use cases, I'd say something like:-

Conex enables IP nodes to see information about the whole path congestion, so that it is visible as a useful metric; some of the use cases thereby enabled are:
(1) Inform the operator's traffic management
(2) Side impact - incentivise scavenger transports
(3) Side impact - enable enduser-controlled QoS
(4) Inform the operator's provisioning process
(5) Inform the interconnect agreement between two operators

- i deliberately included the first sentence [before the list]. I think it's important to be clear about what the conex capability is, as these are cases that use that capability. (this may also help clarify what other stuff is needed by a particular use case)
- i think it's much clearer to say what conex directly enables (1, 4, 5) and what it, as a side effect, encourages to happen (2, 3). I think it's helpful to have 'Side impact' in the section title. 
- i think my 3 is the same as your 'intra-class QoS', but is of slightly wider scope & also makes it clearer that it's interesting for the end user. Anyway, what i mean is the flip side of (2) - enable the-opposite-of-scavenger transports.
- 'accounting for congestion' is already covered within (1). The text in S5.3 of the I-D (current version, -01) is slightly philosophical about what things would be like if everyone used conex. I dont think it's needed. If you really want it, how about a section towards the end of the doc that covers longer-terms vision etc. Anyway, it doesnt read like a use case to me. 
- personally i think that (4) is important enough it shouldn't be hidden as a sub-case
- (5) is a bit trickier, as it requres 2 operators to be using conex. Personally i'd prefer to show it as a use case, rather than hide it in 'other use cases'
- i think it's important to get the wording of the section titles right. Eg "Provisioning capacity" is poor (something like " Inform the operator's provisioning process" is better). 
- re " Preventing congestion collapse" - this fails the previous comment. Anyway, it sounds more like a possible benefit than a use case. Dont think it's needed. 
- re " Mitigating flooding attacks". I suspect not mentioning is the pragmatic approach.

Other comments:
'concepts' rather than 'definitions' is great. The current page count in the ToC suggests you only have text under 'definitions'. Suggest you work as much as possible, ie describe the concepts!

'Deployment arrangements' - much better
'self congestion' - agree.

Thanks,
phil 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: 06 July 2011 11:57
To: ConEx IETF list
Subject: [conex] draft-ietf-conex-concepts-uses proposed changes to ToC

ConEx folks,

5.  ConEx Use Cases

	

7.2.  Self Congestion

Cheers

Bob

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

---

From: Michael Menth <[email-masked]>
Date: Thu, 07 Jul 2011 15:43:50 +0200

+1

Am 07.07.2011 15:13, schrieb [email-masked]:
> - i think my 3 is the same as your 'intra-class QoS', but is of slightly wider scope&  also makes it clearer that it's interesting for the end user. Anyway, what i mean is the flip side of (2) - enable the-opposite-of-scavenger transports.
> Bob Briscoe,                                BT Innovate&  Design
>

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 18:45:18 +0100

Phil,

Thanks - v useful feedback.

The only reason for having use-cases under "other" was so we don't 
have interminable arguments again about which use-cases to include. 
We've already decided (I think) not to include these use-cases in 
order to keep the draft focused, so readers go away with one message 
not hundreds. But as there's still pressure to have different 
use-cases, I thought just mentioning them briefly would be a good compromise.

I had already picked up your earlier comment about making use-cases 
1,2,3 follow on from each other, rather than appear independent. 
Flagging that in the headings is a good idea.

more inline...

At 14:13 07/07/2011, [email-masked] wrote:
>Conex enables IP nodes to see information about the whole path 
>congestion, so that it is visible as a useful metric; some of the 
>use cases thereby enabled are:
>- i deliberately included the first sentence [before the list]. I 
>think it's important to be clear about what the conex capability is, 
>as these are cases that use that capability. (this may also help 
>clarify what other stuff is needed by a particular use case)

I was going to put some text between 5. and 5.1 to explain the likely 
sequence of events. So this can go there.

>- i think it's much clearer to say what conex directly enables (1, 
>4, 5) and what it, as a side effect, encourages to happen (2, 3). I 
>think it's helpful to have 'Side impact' in the section title.

'Side impact' sounds a bit off-hand tho. I'll probably use "Consequence"

>- i think my 3 is the same as your 'intra-class QoS', but is of 
>slightly wider scope & also makes it clearer that it's interesting 
>for the end user. Anyway, what i mean is the flip side of (2) - 
>enable the-opposite-of-scavenger transports.

I'll use "Consequence: User-Controlled Intra-Class QoS"

I agree headings are important. Intra-class QoS was to make it clear 
this doesn't threaten vendor's Diffserv products, which has caused 
knee-jerk allergic reactions in the past.

>- 'accounting for congestion' is already covered within (1). The 
>text in S5.3 of the I-D (current version, -01) is slightly 
>philosophical about what things would be like if everyone used 
>conex. I dont think it's needed. If you really want it, how about a 
>section towards the end of the doc that covers longer-terms vision 
>etc. Anyway, it doesnt read like a use case to me.

I only kept it because I assumed the w-g wanted it. I also think it's 
rather whimsical. Given it was actually about an ideal global 
deployment, I would be happy to replace it with a less ambitious 
"Inform Inter-Operator Contracts" section, without implying global deployment.

>- personally i think that (4) is important enough it shouldn't be 

See above - avoid confusing the single main message.

>- (5) is a bit trickier, as it requres 2 operators to be using 
>conex. Personally i'd prefer to show it as a use case, rather than 
>hide it in 'other use cases'

Ditto. We want to leave the message that this would be useful for one 
network to do unilaterally (to get started). Demoting interconnection 
to "other" helps that without losing it.

>- i think it's important to get the wording of the section titles 
>right. Eg "Provisioning capacity" is poor (something like " Inform 
>the operator's provisioning process" is better).

Would "Inform Capacity Provisioning" be acceptable? Pretty obvious 
this is the operator's and that it's a process.

>- re " Preventing congestion collapse" - this fails the previous 
>comment. Anyway, it sounds more like a possible benefit than a use 
>case. Dont think it's needed.

It's a Consequence of traffic management. Use-cases /are/ benefits 
from using ConEx.

By your rules it would be
"Consequence: Operator can Prevent Congestion Collapse"

(In text I was planning on saying:
The Internet is no less vulnerable to congestion collapses now than 
it was in the 1980s [ref]. If a new app that implemented congestion 
control badly rapidly became popular, existing non-congestion-related 
traffic controls would not prevent collapse. Under extreme 
congestion, ConEx-based traffic management would automatically 
override host congestion control and prevent collapse.
)

>- re " Mitigating flooding attacks". I suspect not mentioning is the 

Yup.

>Other comments:
>'concepts' rather than 'definitions' is great. The current page 
>count in the ToC suggests you only have text under 'definitions'. 
>Suggest you work as much as possible, ie describe the concepts!
>

Cheers

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Jul 2011 18:14:22 +0100

All,

Please give feedback on the proposed new Concepts text below that 
precedes the definitions.

Altho the doc is meant to be about concepts, in -01 the main concepts 
were defined but not explained. So, I felt the definitions smacked 
you in the face without any warning, and it wasn't ever explained why 
you needed them.

I've also pasted proposed changes to the definitions section below, 
because I've changed a couple of definitions:
- I've clarified the definition of congestion, because there were 
three conflicting statements: in the introduction, the definitions 
section and abstract-mech.
- I've made a big change to congestion-volume, which was previously 
defined as congestion-rate multiplied by time.

I've also added the units each metric is measured in.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
2.  Concepts

    Despite its central role in network control and management,
    congestion is a remarkably hard concept to define.  [Bauer09]
    provides a good academic background.  For the purposes of ConEx, the
    definition below focuses on how congestion would be measured, rather
    than precisely what it is.  Our definition of congestion is then
    equivalent to the loss probability (or the marking probability if ECN
    is used).

    ConEx is essentially about accountability for congestion (or blame in
    crude language).  The blame for congestion lies equally between too
    little capacity and too much traffic.  On the capacity side,
    congestion itself measures how badly the network provider is to
    blame.  On the traffic side, in a shared network, the blame is split
    among all the users.  Congestion-volume measures how much of each
    user's traffic is to blame for the congestion.  Note that congestion-
    volume is a property of traffic, whereas congestion is a property of
    a link or a path.

Briscoe & Woundy         Expires January 8, 2012                [Page 5]

Internet-Draft         ConEx Concepts & Use Cases              July 2011

    Congestion-volume is a relatively newly defined metric that is
    central to ConEx.  To grasp an intuitive feel for what congestion-
    volume measures, some network operators give you an allowance and
    only count data volume during the peak period against it.  This is
    equivalent to counting your congestion-volume by assuming that
    congestion is 100% during the peak period and 0% otherwise.

    The congestion-volume metric is more refined but broadly equivalent,
    and still as simple to measure as the above time-of-day volume.
    Imagine Alice sends 1GB while the loss-probability is a constant
    0.2%.  Then her contribution to congestion (or congestion-volume) is
    1GB x 0.2% = 2MB.  If she then sends 3GB while congestion is 0.1%,
    this adds 3MB to her congestion-volume.  Her total contribution to
    congestion is then 2MB+3MB = 5MB.

    To measure Alice's congestion-volume no-one has to do all these
    multiplications and additions.  It is simply a matter of counting the
    total volume of Alice's traffic that was discarded (a queue with a
    percentage loss involves multiplication inherently).

    Finally, there is yet another way to cut the blame for congestion.
    Recall that the level of congestion itself measures the provider's
    blame.  However, in an internetwork there are multiple providers.  If
    a data centre network with zero congestion is connected to an access
    network and sends traffic over a link with 0.4% loss probability,
    then clearly all the blame for congestion lies with the access
    network.  However, at another time, there might be 0.1% congestion
    across the data centre and 0.7% across the access, making 0.8% end-
    to-end congestion across the path.

    In order to apportion blame accordingly, ConEx is designed so that a
    meter at the border can see how much of the congestion is on one side
    or other, termed upstream and downstream congestion.

    If A and B are connected within a chain of more than two networks, A
    attributes all congestion beyond B to B, and vice versa.  As far as A
    is concerned, B chooses who to route to, so B takes responsibility
    for its choices.

2.1.  Definitions

    Congestion:  Congestion occurs when any user's traffic suffers
       increased delay, loss or ECN marking as a result of one or more
       network resources becoming overloaded.  For the purposes of ConEx,
       the focus is on concrete signals of congestion (ECN and loss),
       therefore delay is set to one side.  Congestion is measured as the
       probability of loss or the probability of ECN marking, usually
       expressed as dimensionless percentages.

Briscoe & Woundy         Expires January 8, 2012                [Page 6]

Internet-Draft         ConEx Concepts & Use Cases              July 2011

    Congestion-volume:  For any granularity of traffic (packet, flow,
       aggregate, link, etc.), the volume of bytes dropped or marked in a
       given period of time.  Conceptually, data volume multiplied by the
       instantaneous congestion each packet of the volume experienced.
       Usually expressed in bytes (or MB, GB, of course).

    Congestion-rate:  For any granularity of traffic (packet, flow,
       aggregate, link, etc.), the instantaneous rate of traffic
       discarded or marked due to congestion.  Conceptually, the
       instantaneous bit-rate of the traffic weighted by the
       instantaneous congestion it experiences.  Usually expressed in
       b/s.

    Upstream Congestion:  The accumulated level of congestion experienced
       by a traffic flow thus far, relative to a point along its path.
       In other words, at any point the Upstream Congestion is the
       accmulated level of congestion the traffic flow has experienced as
       it travels from the sender to that point.  At the receiver this is
       equivalent to the end-to-end congestion level that (usually) is
       reported back to the sender.

    Downstream Congestion:  The level of congestion a flow of traffic is
       expected to experience on the remainder of its path.  In other
       words, at any point the Downstream Congestion is the level of
       congestion the traffic flow is yet to experience as it travels
       from that point to the receiver.  Aka. Rest-of-Path Congestion.

    Consumer:  A general term representing the contractual entity such as
       a user or business or institution that uses the service of a
       network provider.  There is no implication that the contract has
       to be commercial; for instance the consumers of a University or
       enterprise network service would be students or employees and they
       might well be required to comply with some form of contract or
       acceptable use policy.  There is also no implication that the
       consumer is necessarily an end-consumer.  Where two networks form
       a customer-provider relationship, the term consumer is also
       intended to cover the customer network.

    Network provider:  (also 'operator'): the term is not confined to
       Internet service providers (ISPs) who run commercial public
       networks but is also intended to generalise to operators of
       enterprise, campus and other networks.

    [ConEx-Abstract-Mech] gives further definitions for aspects of ConEx
    to do with protocol mechanisms.

Briscoe & Woundy         Expires January 8, 2012                [Page 7]

Internet-Draft         ConEx Concepts & Use Cases              July 2011

2.2.  Non-Goals of ConEx and Common Misconceptions

[continues as pasted into an earlier thread...]
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Bob

---

From: John Leslie <[email-masked]>
Date: Wed, 13 Jul 2011 12:33:14 -0400

> precedes the definitions.

   Seems good...

>    volume is a property of traffic, whereas congestion is a property of

   "Blame" is a bad paradigm: once it is introduced, it's hard to avoid
degenerating into arguments of where "blame" belongs. We have up to now
tried to avoid such distractions. Thus, I attempt some wordsmithing:
" 
" Congestion is a signal that sender(s) and/or receiver(s) may (or may
" not) be willing to bear a share of the cost of upgrading a congested
" link. But without accountability, the network operator can't quantify
" that willingness. Blaming the network operator is easy, but moot;
" blaming the sender is harder, because you can't tell which sender to
" blame.
" 
" With ConEx accountability, you can quantify which senders intentionally
" sent data over a path known to be congested. While ConEx doesn't
" consider how to assess cost, it does ensure that the needed information
" is right there in the IP packet. Even without any mechanism to assess
" cost, this information better informs any judgment of when to upgrade.

>    congestion is 100% during the peak period and 0% otherwise.

   This is hard to read. Some possible wordsmithing:
" 
" Congestion-volume is a property of traffic central to ConEx. Some
" network operators already do a crude approximation by giving their
" customers a volume allowance during "peak usage". This can be
" thought of as assuming 100% congestion during peak and 0% otherwise.
" We refine that by counting only packets during actual congestion:
" thus assuming 100% congestion for packets marked or dropped, and
" 0% for packets neither marked nor dropped (though in practice we
" need to count packets marked for Congestion-Expected, which lags
" the actual congestion by one Round-Trip-Time).

>    percentage loss involves multiplication inherently).

   I don't think these two paragraphs are needed (but I'm not objecting
to them -- merely suggesting how to get to the point before losing our
readers).

>    to-end congestion across the path.

   I do object to this paragraph. I don't believe it's needed, and I can
see no way to wordsmith it to avoid the "blame" game.

>    or other, termed upstream and downstream congestion.

   Here a simple s/apportion blame accordingly/establish accountability/
should suffice.

>    is concerned, B chooses who to route to, so B takes responsibility

   I could probably improve on this, but I'm not going to try right now.

>       expressed as dimensionless percentages.

   I find "delay is set to one side" confusing: I think it would be
better to say "delay is not considered".

   Also, I find the "Congestion is measured as" sentence a bit misleading.
ConEx actually is about including a Congestion-Expected signal: exactly
how the sender measures the congestion expected is out-of scope. Perhaps:
" 
" Congestion is the probability of loss and/or ECN marking, expressed
" as a dimensionless fraction.

>       Usually expressed in bytes (or MB, GB, of course).

   Nit: s/Conceptually, data volume/Conceptually it is data volume/

>       instantaneous congestion it experiences.  Usually expressed in

   This is confusing, and the term isn't used in the document. I suggest
removing the definition. (Otherwise, we need to see how it will be used
and make sure we understand that concept before wordsmithing.)

>       intended to cover the customer network.

   Personally, I would prefer "customer" to "consumer". "Consumer"
suggests we're talking about the receiver as opposed to the sender.

>    to do with protocol mechanisms.

   I'm not sure quite what this means: does it imply that we need to
read abstract-mech for definitions used in this document? (I would
prefer we not ask our readers to do that.)

--
John Leslie <[email-masked]>

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 14 Jul 2011 09:26:52 +0000

Hi Bob and all,

Thanks for the update and apologies for the late feedback -- here's one comment:

It's good to have 'congestion volume' defined (and the definition is correct IMO), but I don't think the 'blame' terminology is very helpful here. I understand what you want to say, but I fear that it will be misleading.

Especially I find it misleading to talk about "blaming network operators" in the beginning of section 2. I understand the motivation with the upstream/downstream congestion exposure for inter-provider accountability, but you assume that concept to be understood when talking about "how badly the network operator is to blame", whereas you actually describe it later.

I think what we ought to say is that congestion normally occurs in capacity-shared networks (nobody is to blame for that), and that it will be useful to expose such congestion for different reasons: to optimize the capacity sharing between users, to support operators to adjust capacity sharing policies (or to adjust capacity), to evaluate network performance with respect to congestion etc. (detailed use cases to be described elsewhere).

Congestion volume is a metric for accounting for congestion (with your definition), and this metric could for example be used for 1) quantifying per-user/flow contribution (adding the details of your first example) and for 2) assessing congestion in inter-provider settings (also adding details).

Best regards,

Dirk

> Sent: Monday, July 11, 2011 7:14 PM
> To: [email-masked]
> Subject: [conex] New concepts text in draft-ietf-conex-concepts-uses
> 
> All,
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 14 Jul 2011 23:45:31 +0100

Dirk,

John Leslie also thought blame was not a good concept to use.

I tried to say balme is shared between too little capacity and too 
much traffic, then each side of that further splits down 
(respectively between providers along the path and between the users 
sending the traffic). And behind the users sending the traffic there 
are those receiving it as in the discussion with Mikael. And so on.

But I can see that it is easy to pick up one of the later sentences 
out of context of the original statement that overall blame is shared 
from the start.

I was pleased to have thought of a way of describing all the concepts 
under the same over-arching framework - just unfortunate it was laden 
with the guilt of blame :(

I will have to find another approach to pulling all the concepts 
together, or a way to avoid being misinterpreted or parts taken out of context.

Bob

At 10:26 14/07/2011, Dirk Kutscher wrote:
>It's good to have 'congestion volume' defined (and the definition is 
>correct IMO), but I don't think the 'blame' terminology is very 
>helpful here. I understand what you want to say, but I fear that it 
>will be misleading.
>
>Especially I find it misleading to talk about "blaming network 
>operators" in the beginning of section 2. I understand the 
>motivation with the upstream/downstream congestion exposure for 
>inter-provider accountability, but you assume that concept to be 
>understood when talking about "how badly the network operator is to 
>blame", whereas you actually describe it later.
>
>I think what we ought to say is that congestion normally occurs in 
>capacity-shared networks (nobody is to blame for that), and that it 
>will be useful to expose such congestion for different reasons: to 
>optimize the capacity sharing between users, to support operators to 
>adjust capacity sharing policies (or to adjust capacity), to 
>evaluate network performance with respect to congestion etc. 
>(detailed use cases to be described elsewhere).
>
>Congestion volume is a metric for accounting for congestion (with 
>your definition), and this metric could for example be used for 1) 
>quantifying per-user/flow contribution (adding the details of your 
>first example) and for 2) assessing congestion in inter-provider 
>settings (also adding details).
>
>
>Best regards,
>
>Dirk
>
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 15 Jul 2011 21:35:13 +0000

> John Leslie also thought blame was not a good concept to use.

My personal opinion is that the issue with 'blame' is about terminology implying a (negative) moral judgment, rather than about the concept of accountability. According to Wikipedia, "Blame is the act of censuring, holding responsible, making negative statements about an individual or group that their action or actions are socially or morally irresponsible".

Perhaps we should consider substituting non-judgmental terms like 'accounting', 'attribution', or even 'source'.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: Thursday, July 14, 2011 6:46 PM
To: Dirk Kutscher
Cc: [email-masked]
Subject: Re: [conex] New concepts text in draft-ietf-conex-concepts-uses

Dirk,

Bob

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 16 Jul 2011 11:51:01 +0100

I agree that "blame" is far too negative a word to be using. If anything we
should be saying that there is no blame-- after all congestion is a
by-product of using the network. What we are trying to do is make people
accountable for that use, and in turn, make the operators accountable for
their network provisioning.

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Woundy, Richard
> Sent: 15 July 2011 22:35
> To: Bob Briscoe; Dirk Kutscher
> Cc: [email-masked]
> My personal opinion is that the issue with 'blame' is about terminology
> implying a (negative) moral judgment, rather than about the concept of
> accountability. According to Wikipedia, "Blame is the act of censuring,
> holding responsible, making negative statements about an individual or
> group that their action or actions are socially or morally
> irresponsible".
> 
> Perhaps we should consider substituting non-judgmental terms like
> 'accounting', 'attribution', or even 'source'.
> 
> -- Rich
> 
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of Bob Briscoe
> > >     provides a good academic background.  For the purposes of
> ConEx,
> > > the
> > >     equivalent to the loss probability (or the marking probability
> if
> > > ECN
> > >     is used).
> > >
> > >     ConEx is essentially about accountability for congestion (or
> blame
> > > in
> > >     volume is a property of traffic, whereas congestion is a
> property
> > > of
> > >     a link or a path.
> > >
> > >
> > >
> > > Briscoe & Woundy         Expires January 8, 2012
> [Page
> > > 5]
> > >
> > >     0.2%.  Then her contribution to congestion (or congestion-
> volume)
> > > is
> > >     multiplications and additions.  It is simply a matter of
> counting
> > > the
> > >     blame.  However, in an internetwork there are multiple
> providers.
> > > If
> > >     In order to apportion blame accordingly, ConEx is designed so
> that
> > > a
> > >     meter at the border can see how much of the congestion is on
> one
> > > side
> > >     If A and B are connected within a chain of more than two
> networks,
> > > A
> > >     attributes all congestion beyond B to B, and vice versa.  As
> far as
> > > A
> > >        therefore delay is set to one side.  Congestion is measured
> as
> > > the
> > > Briscoe & Woundy         Expires January 8, 2012
> [Page
> > > 6]
> > >
> > >        aggregate, link, etc.), the volume of bytes dropped or
> marked in
> > > a
> > >        given period of time.  Conceptually, data volume multiplied
> by
> > > the
> > >        accmulated level of congestion the traffic flow has
> experienced
> > > as
> > >        it travels from the sender to that point.  At the receiver
> this
> > > is
> > >     Downstream Congestion:  The level of congestion a flow of
> traffic
> > > is
> > >     Consumer:  A general term representing the contractual entity
> such
> > > as
> > >        enterprise network service would be students or employees
> and
> > > they
> > > Briscoe & Woundy         Expires January 8, 2012
> [Page
> > > 7]
> > >

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 18 Jul 2011 18:58:17 +0100

Hi Bob,

I am finding the organization of the document somewhat confusing. With the introduction of new text in early sections, it has also become a bit repetitive in parts. I'll throw out an alternative organization below with some explanation afterward:

1. Introduction
2. Concepts
3. Definitions
4. Core Use Case: Informing Congestion Management
	4.1 History
	4.2 Existing Approaches
	4.3 Drawbacks of Existing Approaches
	4.4 Use Case Description
5. Other Use Cases
	5.1 Creating Incentives for Scavenger Transports
	5.2 Supporting Intra-Class Quality of Service
	5.3 Preventing Congestion Collapse
	5.4 Informing Inter-Operator Contracts
	5.5 Informing Capacity Provisioning
6. Deployment Arrangements  (sub-outline structure as is for now)
7. Commercial Secrecy as a Potential Deployment Barrier
8. Non-Goals
9. Security Considerations
10. IANA Considerations
11. Acknowledgments
12. Contributors

2. Concepts and 3. Definitions -- Right now the only concepts that are fully teed up in the Concepts section are congestion volume and blame (which I hope will become accountability or something similar as others have suggested). So I think it's safe to separate the concepts section from the definitions section.

4. Core Use Case: Informing Congestion Management -- As of now the document sort of wavers between emphasizing traffic management (what I'm calling congestion management) as the key motivating use case and mixing in some of the other motivating use cases. A clearer separation would help, I think. I also found the narrative of current sections 3 and 4 (Traffic Management and Exposing Congestion) to be somewhat disjoint and repetitive, thus my suggestions for streamlining 4.1-4.4 above. 4.1 maps to the current intro to section 3; 4.2 maps to the first part of the current 3.1; 4.3 maps to the second part of the current 3.1 plus the ECN discussion currently in 4.1; and 4.4 maps to the current 5.1. I think parts of the intro to the current section 4 are now redundant and other parts can be fit in to the subsections above as appropriate (e.g., the LEDBAT discussion could go in the suggested 5.1).

5. Other Use Cases -- This is just the list from the current draft, although phrased in the active voice. I find the distinction between consequences and use cases to be of little use; in every case, ConEx just exposes information and it is up to the operator to act on it, so in some sense every use case is a consequence. For the "Informing Traffic Management" case, for example, I don't think the expectation is that operators will merely be glad to have more information, but they will actually act on it (perhaps by using an ingress policer as described). The same can be said for incentivizing scavenger transports: the operator has to take affirmative steps using the ConEx information to create the incentives. I don't see the difference between the two.

6. Deployment Arrangements -- I haven't looked at this section in depth yet so no changes to recommend.

7. Commercial Secrecy as a Potential Deployment Barrier and 8. Non-Goals -- From the text it seems like dealing with self-congestion is a non-goal, so it probably can be fit in the non-goals section. And I agree with earlier reviewers that putting non-goals up front is a non-starter. If the section is listed in the ToC and previewed at the end of the introduction, people who are confused will be able to find it (as opposed to possibly confusing many people by putting it up front before the actual goals have really been discussed).

Alissa

On Jul 6, 2011, at 11:57 AM, Bob Briscoe wrote:

> Please react if you object. There will be controversy, but please try to recognise that we ought to be converging now.
> 
> The "Definitions" section in draft-01 actually introduced the main concepts, which is goal #1 of this doc. So Concepts is a better section heading.
> Then we've added the much-discussed Misconceptions sub-section clarifying it's not misconceptions about networking, just about ConEx.
> 
> 5.  ConEx Use Cases
> Removed one use-case (Accounting for Congestion Volume) but really just moved it to "Other Use-Cases" so it can be much shorter.
> 
> The idea is to resolve all the to-and-fro about which use-cases should be in or out, by having a "half-in" category.
> 
> We'll change the story to emphasise that ConEx doesn't replace Diffserv, but it could handle allocation of resources within a class (ie bandwidth allocation as opposed to queue scheduling).
> 
> It's tough to talk about deployment in a mechanism-neutral way (given deployment is about deploying mechanisms!). Nonetheless, the idea is to give a plausible story for how the previously mentioned use-cases would get incrementally deployed. So it fits in this doc, but it will be tough. We have summarised stuff about components and incremental deployment in abstract-mech first (I intend to post proposed new text for this section to the list shortly).
> 
> 7.2.  Self Congestion
> 
> Rather than diving straight into this detailed area early in the Introduction, we've moved it to where it belongs: under 7. Potential Issues.
> 
> Bob (& discussed with Rich as co-editor, but still some uncertainties - hence asking the list for views)
> 
> 
> Bob
> 
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 18 Jul 2011 19:08:26 +0100

John (and Toby, Dirk),

OK. I get the message loud and clear; blame is a politically 
incorrect word - to be avoided. (Rich had already thought it was 
unsafe language and wishes he had been more forceful against it now).

Before addressing your wordsmithing suggestions, can you just confirm 
that you are not saying we should not use this way of explaining the 
ConEx concepts (dividing down who is accountable for what), it's just 
the guilt-laden word blame that is problematic?

Now some responses inline...

>" blaming the sender is harder, because you can't tell which sender to

Jumping from the frying pan into fire! I don't think we should bring 
cost in at this early stage in the doc. We should keep it as 
accountability for congestion.

We can certainly point to the equivalence of congestion and cost 
later (e.g. when we talk about provisioning), but we shouldn't turn 
off some readers who have an allergic reaction to billing and so 
forth. We can talk about accountability without implying accounting 
at this stage.

>" cost, this information better informs any judgment of when to upgrade.

I'm afraid this also jumps into the fire from the frying pan. Reason: ditto

As Rich said in our offlist conversation about this, ConEx touches a 
load of different political hot potatoes. We have to somehow describe 
ConEx without explicitly looking as if we are touching any of them. 
It might make the doc bland, but we have to do it and we can.

>" the actual congestion by one Round-Trip-Time).

OK. Let's try to use something like this.

Did you remove the "relatively newly defined metric" deliberately. 
This was deliberately in there to gently flag to readers that they 
might need to turn on their brain for this para: ie "Warning: new 
concept ahead!".

I've realised we don't need to introduce the additional concept of an 
allowance, we just need to talk about counting.

I'm not sure the idea of congestion jumping from 0 to 100% for 
different packets will help. What do others think? Here's an idea. 
Would the concept of a weighted average help? Ie. a weighted average 
of volume sent, where the weights are the levels of congestion when it is sent.

As per previous discussion, let's not introduce the time lag 
discussion at this point in the doc. The new concepts have to come in 
baby steps.

>to them -- merely suggesting how to get to the point before losing our

OK, I agree the numerical example can go - I was not sure about it at the time.

I think we need to keep the essence of the latter para: that this 
doesn't involve complicated calculations; you just count the volume 
of dropped or marked packets.

>    Here a simple s/apportion blame accordingly/establish accountability/

If this sentence just stood alone, without the start of the previous 
para, it would not be clear that we have switched from a property of 
the traffic back to a property of the path.

I agree we could scrub the example with the data centre, but we need 
something to signpost that we've switched back to congestion, not 
congestion-volume. And for those who think ConEx is an evil 
operator-inspired plot, it's important to point out that ConEx 
equally addresses dividing up the accountability for provisioning, 
not just accountability for the traffic.

In summary, we need to keep something like the first part of the 
"There is another way to cut the ..." para. And I think it can be 
rewritten avoiding the blame word.

>    I could probably improve on this, but I'm not going to try right now.

Can you try to say what is wrong with given text, rather than only 
re-writing it? It is fine if there are not any problems with the new 
text. But if there are, before fixing your text, as editors we have 
to guess what it was you were objecting to by detecting all the 
differences and reverse-engineering.

>better to say "delay is not considered".

OK.

>how the sender measures the congestion expected is out-of scope.

Eh? We're defining Congestion here, not ConEx.

>Perhaps:

I'd be happy with cutting down to such a stark sentence (given we've 
said earlier we focus on what is practically measurable). But I don't 
agree with "Congestion is", given we said earlier we're not going to 
define what congestion is, just how it will be measured. So I don't 
understand why you don't like "Congestion is measured as"? We have to 
say this, surely?

>    Nit: s/Conceptually, data volume/Conceptually it is data volume/

Y

>and make sure we understand that concept before wordsmithing.)

For similar reasons, I considered removing this (during the threads 
with Georgios & Mikael). But I figured these are definitions for 
later ConEx use, not just in this doc. When talking about policers, 
we will need this definition.

How about explicitly saying...

     Congestion-rate:  This concept is not needed in the current 
document but, as it follows naturally from congestion-volume, it is 
defined here for use in other ConEx documents. For any granularity of 
traffic (packet, flow, ...

>suggests we're talking about the receiver as opposed to the sender.

Ug. Customer is too loaded with commercial connotations. ConEx is 
equally applicable to non-ISP scenarios and we mustn't rule that out 
with our language.

I can't think of another word (neither can the Thesaurus) other than punter :)

Do you really think Consumer will get confused with receiver? We could add:

"Note: The Consumer could be a sender and/or receiver; it is used in 
the sense of a consumer of service (not to be confused with a 
consumer of data)."

>prefer we not ask our readers to do that.)

How about:
     Because ConEx protocol mechanisms are outside this document's 
scope, mechanism-related definitions can be found in [ConEx-Abstract-Mech].

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 18 Jul 2011 19:38:22 +0100

Alissa,

I'll deal with this in small parts.

At 18:58 18/07/2011, Alissa Cooper wrote:
>2. Concepts and 3. Definitions -- Right now the only concepts that 
>are fully teed up in the Concepts section are congestion volume and 
>blame (which I hope will become accountability or something similar 
>as others have suggested). So I think it's safe to separate the 
>concepts section from the definitions section.

Concepts introduces all of:
- congestion
- congestion-volume
- upstream/downstream congestion
all under the framework of cutting accountability different ways.

The definitions section is then a formalisation of the prose that precedes it.
The addition of provider/consumer is related to the 
upstream/downstram split, but the link isn't explicitly made (no need IMO).

Then, what are you implying about the non-goals/misconceptions 
subsection, which you've not mentioned?

I'm about to go offline, so will continue in the morning...

Bob

---

From: John Leslie <[email-masked]>
Date: Mon, 18 Jul 2011 14:52:01 -0400

Alissa Cooper <[email-masked]> wrote:
> 
> I am finding the organization of the document somewhat confusing. With
> the introduction of new text in early sections, it has also become
> a bit repetitive in parts.

   True... :^(

> I'll throw out an alternative organization below with some explanation
> afterward:
> 
> 1. Introduction
> 2. Concepts
> 3. Definitions

   This looks like a promising organization...

   I can't say whether making such a change at this stage makes sense.
I would be willing to help wordsmith if the WGCs decide it does.

> concepts section from the definitions section.

   I certainly agree that _defining_ blame is a super-bad idea!

   Definitions tend to come first, so that the reader can understand
the intended meaning when s/he first encounters the term. Careful
wordsmithing can reduce the need for this, and I'd be willing to help.

   It feels important to get concepts out there first -- especially
with so much of our on-list traffic stumbling over them.

> 4. Core Use Case: Informing Congestion Management

   Quibble: I think we _do_ mean "informing traffic management".
Network operators are going to do traffic-management anyway, and we
can make it work better.

> -- As of now the document sort of wavers between emphasizing traffic
> management (what I'm calling congestion management) as the key
> motivating use case and mixing in some of the other motivating use
> cases. A clearer separation would help, I think.

   I tend to agree.

> I also found the narrative of current sections 3 and 4 (Traffic
> Management and Exposing Congestion) to be somewhat disjoint and
> repetitive,

   A lot of Section 3 text is new: most of Section 4 is old. Some
overlap is inevitable.

> thus my suggestions for streamlining 4.1-4.4 above.

   That seems reasonable, at first blush...

> 4.1 maps to the current intro to section 3;
> 4.2 maps to the first part of the current 3.1;
> 4.3 maps to the second part of the current 3.1 plus the ECN discussion
>     currently in 4.1; and
> 4.4 maps to the current 5.1.

   (I have to admit that throwing out the Section 4 text preceding 4.1
feels a bit painful -- I don't think it's adequately covered elsewhere.)

> I think parts of the intro to the current section 4 are now redundant

   Hmm... someone else will have to chime in here... This is carefully-
crafted text on which I thought we had consensus. Carving it up into
pieces, IMHO, endangers the consensus.

> and other parts can be fit in to the subsections above as appropriate
> (e.g., the LEDBAT discussion could go in the suggested 5.1).

   To me, LEDBAT isn't the point -- the point is that current traffic
management disincents good behavior. This feels like something which
belongs earlier than a secondary use-case.

> 5. Other Use Cases -- This is just the list from the current draft,
> although phrased in the active voice.

   Active-voice is good...

> I find the distinction between consequences and use cases to be of
> little use; in every case, ConEx just exposes information and it is
> up to the operator to act on it, so in some sense every use case is
> a > consequence.

   I think I agree.

> For the "Informing Traffic Management" case, for example, I don't
> think the expectation is that operators will merely be glad to have
> more information, but they will actually act on it (perhaps by using
> an ingress policer as described).

   That's by no means the only way to act on it...

> The same can be said for incentivizing scavenger transports: the
> operator has to take affirmative steps using the ConEx information
> to create the incentives. I don't see the difference between the two.

   It's no so much a difference between use -- it's a difference in
motivation to use ConEx information. I think the uses deserve separate
billing...

> depth yet so no changes to recommend.

   Certainly incremental-deployment is an essential feature -- but
I don't want to talk details here yet either.

> 7. Commercial Secrecy as a Potential Deployment Barrier and
> 8. Non-Goals -- From the text it seems like dealing with self-
> congestion is a non-goal, so it probably can be fit in the non-goals
> section.

   That doesn't feel quite right. Self-congestion differs in that the
network operator can do little to help -- but it may look no different
to the application self-congesting. The same tools which a network
operator might use to act on ConEx information could be deployed by
users before the Internet Ingress.

   Also, to some degree, self-congestion can result from a receiver
requesting too much; and there is quite a bit network operators could
do there.

> And I agree with earlier reviewers that putting non-goals up front
> is a non-starter. If the section is listed in the ToC and previewed
> at the end of the introduction, people who are confused will be able
> to find it (as opposed to possibly confusing many people by putting
> it up front before the actual goals have really been discussed).

   +1

---

From: John Leslie <[email-masked]>
Date: Mon, 18 Jul 2011 15:35:36 -0400

>> tried to avoid such distractions. Thus, I attempt some wordsmithing:

   (It's not unusual for the first wordsmithing attempt to fail...)

> accountability for congestion.

   Nonetheless, congestion _is_ a signal of something like that; and
ConEx intends to make an even-more-useful signal visible at the
network layer. Retreating in horror at the C-word (cost) doesn't help.

> forth. We can talk about accountability without implying accounting 

   Careful, there: "accountability" already raises some of the C-word
hackles. ;^)

>>" sent data over a path known to be congested.

   This _is_ a central point (though I must agree it's probably too early
to introduce it).

>>" While ConEx doesn't consider how to assess cost, it does ensure that
>>" the needed information is right there in the IP packet. Even without
>>" any mechanism to assess cost, this information better informs any
>>" judgment of when to upgrade.
> 

   Quite possibly none of your words belong so early in the document
either. Reason: ditto.

> It might make the doc bland, but we have to do it and we can.

   We "want to avoid" that, yes. But we do need to get across the idea
that essential information is missing. Where I was trying to go is that
the mere fact that a sender _deliberately_ sends data down a congested
path is useful information to inform network upgrade decisions, even
without any cost-sharing mechanism.

> Did you remove the "relatively newly defined metric" deliberately. 

   Well, yes...

> might need to turn on their brain for this para: ie "Warning: new 

   Exactly: when warned, readers tend to turn their brain off; when
they merely encounter a new idea, they tend to forget they saw it.
Big difference! When they run into the new idea again, in the latter
case, it comes with a patina of familiarity.

> allowance, we just need to talk about counting.

   Probably a good idea.

> of volume sent, where the weights are the levels of congestion when it

   I found it helpful to contrast binary counting of volume with binary
counting of congestion -- and didn't feel the need to go into weighed
anything (which does frighten a number of readers).

> discussion at this point in the doc. The new concepts have to come in 

   I think it's important for _us_ to remember the time-lag -- but I
don't think it's necessary to bother the reader with it, least of all
early in the document.

>>> <snip first of two paragpaphs>
>> I don't think these two paragraphs are needed...
> 

   The question is how early we need to get into mechanism...

>> <snip>

   Better, we could wordsmith so we don't need to switch back and forth.

> differences and reverse-engineering.

   It's describing mechanism, and the mechanism is confusing to the
casual reader. Also, it goes _way_ beyond the limited deployment we
are chartered to consider. I doubt it's even needed in the document
at all.

>>> 2.1.  Definitions
>>> <snip> Congestion is measured as the

   But in fact, our definition is intentionally vague...

> understand why you don't like "Congestion is measured as"? We have to 

   I objected to the _sentence_ -- not the words. You're welcome to say
"Congestion is measured as; but it's not a definition, it's a description.
"Congestion is defined as", or "Here we define congestion as" would be
more accurate wording.

> we will need this definition.

   Future documents can always refer to future definitions...

> traffic (packet, flow, ...

   Unnecessarily confusing to the casual reader.

> equally applicable to non-ISP scenarios and we mustn't rule that out 

   I think you're way over-sensitive here. "Customer" contains no
implications of what the contractual relationship is -- or even if
a contract is recognized to exist. And "consumer" does bring confusion
about sender vs. receiver.

> the sense of a consumer of service (not to be confused with a 

   That would help -- if you're unwilling to go back to "customer".

>   scope, mechanism-related definitions can be found in

   Much clearer!

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 18 Jul 2011 21:28:34 +0100

> Sent: 18 July 2011 19:08
> To: John Leslie

Speaking for myself I was just a little concerned that the document is
getting too political (or at least opening itself up to wilful
misinterpretation). I'm hoping to get time to read through it properly when
I am actually awake (rather than the semi-comatose state my daily commute
leaves me in), then I will be able to make some more constructive
suggestions... At the moment I have no objections to your actual approach to
explaining this

Toby

> if ECN
> blame in
> property of
> volume) is
> counting the
> providers.  If
> that a
> networks, A
> as the
> by the
> experienced as
> this is
> traffic is
> such as

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 18 Jul 2011 21:37:40 +0100

I have only skim read this and the following is rather a rambling chain of
consciousness.

I think at some stage we have to grab the bull by the horns and talk about
cost, however as things stand we need to treat this aspect really
cautiously. And we have to accept that readers are bright enough to make the
link between accountability and cost... Where they are struggling is in
understanding the difference between the variable cost (congestion) and the
fixed costs (infrastructure) - they are worried that ConEx is just opening
the door to allowing ISPs to charge for any and all congestion thus coining
money.

There is no easy way through this. I think we need to somehow provide a
reasonable analogy, but I'm too tired to think of one for now. 

One part of me has always wanted to describe all this in terms if equity and
equitable shares of the network, but that is also open to misinterpretation.

Perhaps what we have to get across is that we are coming up with a way to
apportion responsibility between operators and users. Make more use of the
Tragedy of the Commons argument, using a suitable analogy to show why such a
world is unsustainable without either heavy handed intervention by ISPs or
huge investment (at a time when investment is not high on the agenda) or by
using ConEx.

Hope at least some of this makes sense :)

Toby

> Of John Leslie
> Sent: 18 July 2011 20:36
> To: Bob Briscoe
> > of volume sent, where the weights are the levels of congestion when
> it
> > is sent.
> 
> > OK, I agree the numerical example can go - I was not sure about it at
> the
> > time.
> >

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 19 Jul 2011 05:53:00 +0100

Hi Bob,

Inline...

On Jul 18, 2011, at 7:38 PM, Bob Briscoe wrote:

> The addition of provider/consumer is related to the upstream/downstram split, but the link isn't explicitly made (no need IMO).

Fair enough.

> 
> Then, what are you implying about the non-goals/misconceptions subsection, which you've not mentioned?

Nothing. I find it confusing to start the document by saying what it doesn't do, that's all.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 19 Jul 2011 06:09:26 +0100

Hi Bob,

I have a few questions/suggestions on the definitions.

On Jul 11, 2011, at 6:14 PM, Bob Briscoe wrote:
>      network resources becoming overloaded.  

i) Does "increased" apply only to delay, or also to loss and markings? I would expect it to be the former, but from this construction it's not clear. Might help to say "loss, ECN marking, or increased delay."

ii) What is the "increase" from? Increase from zero? Increase from some baseline? If "increased" only applies to delay this probably doesn't need clarification, but if it applies to loss and marking too, it probably does.

> For the purposes of ConEx,

>      intended to cover the customer network.

If people have problems with "Consumer" you could substitute "User" and I think that would work fine.

>      enterprise, campus and other networks.

I find it confusing to define this in the negative. A suggestion:

Network provider (or "operator"): Operator of a commercial, enterprise, campus, or other network.

Alissa

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Jul 2011 08:14:39 +0200 (CEST)

On Mon, 18 Jul 2011, Toby Moncaster wrote:

> Perhaps what we have to get across is that we are coming up with a way 
> to apportion responsibility between operators and users. Make more use 
> of the Tragedy of the Commons argument, using a suitable analogy to show 
> why such a world is unsustainable without either heavy handed 
> intervention by ISPs or huge investment (at a time when investment is 
> not high on the agenda) or by using ConEx.

I'd just like to point out that the ingress policer needed to actually 
make conex police traffic, isn't going to be for free. It seems to be a 
quite advanced device.

So what I'd like to see is ConEx do two things:

Show congestion to everybody, the user and ISP alike. I would like to see 
it also differentiate between self-congestion (access link) and 
shared-link congestion (everything else than the access link), but I have 
no idea how to do this. It would also be good to show which direction the 
congestion is in. Should we give guidance to how the IP stack should 
expose this information to the user? In the end, I want an end-user to be 
able to differentiate between an ISP which doesn't congest its 
core/distribution, and one that does, by means of showing percent of 
traffic that is exposed to congestion (or some other metric).

I'd also like us to give guidance to AQM for different media, like wifi 
(which is half duplex), ADSL and other typical medias (also in the core, 
WRED drop settings for instance). This is all in the context of 
bufferbloat (I hate that term, but it seems to have gained traction), and 
how it should be handled to give the best compromise between speed for TCP 
and low-latency for interactive applications.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: John Leslie <[email-masked]>
Date: Tue, 19 Jul 2011 08:05:22 -0400

> make conex police traffic, isn't going to be for free. It seems to be a 

   An ingress policer _could_ be rather complicated, but IMHO this really
isn't necessary. We seem to be letting ourselves think in terms of each
policer being flow-aware -- in order to police the "right" target.

   But if an ingress policer is close enough to the source it needn't be
flow-aware -- the user is in the best position to balance demands of
different flows, and the policer merely needs to enforce an overall
limit.

   If, OTOH, various users are aggregated before the ingress policer,
the ingress policer is in a very poor position to sort them out --
especially with forging of source addresses being so easy. I think we're
wasting our time to try.

> Show congestion to everybody, the user and ISP alike.

   Do you mean something beyond simply having in the IP packet in a
well-known place? If so, what?

> I would like to see it also differentiate between self-congestion
> (access link) and shared-link congestion (everything else than the
> access link), but I have no idea how to do this.

   Neither do I... nor do I see any benefit. At any point, it's trivial
to distinguish upstream from downstream.

   Now, if you mean that self-congestion shouldn't be reported all the
way along the path, that's a user's choice which could be implemented
by moving the "sender" function past the ingress bottleneck. But I don't
think many users could be bothered.

> It would also be good to show which direction the congestion is in.

   Oh, but we do. Any congestion on the return-path from receiver to
sender is Somebody-Else's-Problem.

> Should we give guidance to how the IP stack should expose this
> information to the user?

   I don't understand the question.

> In the end, I want an end-user to be able to differentiate between
> an ISP which doesn't congest its core/distribution, and one that does,
> by means of showing percent of traffic that is exposed to congestion
> (or some other metric).

   Recall that ISPs have two quite separable functions: to accept IP
packets to forward them "somewhere closer", and to advertise themselves
as able to deliver packets to particular IP ranges. There's no necessary
correlation between congestion on these two functions.

   In principle, an ISP could entirely avoid congestion of the first:
in practice, most come "close enough". But for the second, it's quite
impossible to avoid congestion _under_some_conditions_ where the
receiving customer is "offered" traffic (often from diverse sources)
greater than his link can handle.

   The receiver already has the information on incoming congestion
without ConEx. The sender _would_ have an additional signal from
ConEx; but it's unlikely it will tell him much about outgoing
congestion _within_ his ISP's control.

   (There is, of course a special-case, where the sender's modem
contends for upstream bandwidth in cable networks, and I guess that
technically is "within" the ISP's control -- but that's more a matter
of diagnosis of the issue than questionable provisioning...)

> (which is half duplex),

   Indeed! an interesting problem area. I'm not sure what would help...

> ADSL and other typical medias (also in the core, WRED drop settings
> for instance).

   Do you have suggestions on what would help?

> This is all in the context of bufferbloat (I hate that term, but it
> seems to have gained traction), and how it should be handled to give
> the best compromise between speed for TCP and low-latency for
> interactive applications.

   Ah, yes. Buffer tuning is fairly well understood by ISPs, but the
distribution-of-information channels don't work well. :^( If you
think ConEx could help, please say how!

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Jul 2011 14:34:09 +0200 (CEST)

> different flows, and the policer merely needs to enforce an overall 

I don't see the need for anything more than we have today then? What would 
a conex enabled policer give if it's one policer per access port anyway? 
And how would it work when it's connected to an ISP<->ISP peering port?

> especially with forging of source addresses being so easy. I think we're

I always thought the policer acted on aggregation ports, ie for several 
users.

> well-known place? If so, what?

I'm talking the congestion signals (re-ECN etc) that seems to be the 
centarl goal of ConEx.

> to distinguish upstream from downstream.

There is tremendous benefit from differentiating "my access link is 
congesting because *I* am using it" to "my ISP doesn't have enough 
capacity so because of *others* I can't use my full access speed", for the 
user point of view.

> sender is Somebody-Else's-Problem.

I don't agree at all. If someone is dropping the traffic I'm about to 
receive, I want to know about it.

>   I don't understand the question.

I want to empower the user with knowledge about congestion. I thought this 
was a central goal of ConEx, to *expose* congestion.

>   In principle, an ISP could entirely avoid congestion of the first: in 
> practice, most come "close enough". But for the second, it's quite 

An ISP can certainly try, and I don't agree that this is "impossible". Of 
course the congestion will be destination/flow-dependent, but this is 
something that has to be taken into account.

> congestion _within_ his ISP's control.

Well, even if the information is already available, it's not exposed to 
the user.

>   Do you have suggestions on what would help?

So, for core links, my suggestion is to use WRED and drop/set ECN at a 
certain queue depth, for instance 20-30 ms queue depth. For access links, 
I'd like to see "fair queuing" (RFC970) enabled on a lot more ADSL/cable 
modems/Wifi routers, and also in hosts.

RFC1254 also lists different ways of handling this. Generally, I'd say not 
much of this is actually in use on the Internet today, 25+ years later :P 
I run fair-queue on my access link at home, it works great.

> distribution-of-information channels don't work well. :^( If you think 
> ConEx could help, please say how!

Er, considering basically NONE of the typical CPEs in use today does 
anything other than FIFO with a lot of buffers, I'd say if the ISP 
understands bufferbloat, they haven't communicated this to the purchasing 
department who controls CPE purchases, because if they did, the typical 
ADSL router would do better things than FIFO for upstream buffer 
management.

So I would like to have ConEx describe how buffering should be implemented 
in all devices who might experience congestion on the outgoing interface 
(hosts and routers, most likely different advice, ConEx perhaps should 
define different classes of devices that should do different things), this 
should be very good guidance going forward.

Let me describe a typical home access scenario to visualise what I'm 
trying to say:

The host IP stack is sending 5 different TCP flows. The IP stack is 
dumping these packets into an egress Wifi NIC FIFO buffer, which is 
emptied by the Wifi hardware as packets are being passed out the wifi air 
interface. When there is a 20ms stop in the wifi communication, this 
affects all flows, and the FIFO buffer might be quite big. When it arrives 
in the wifi router, it's now going to split up the traffic because one 
flow was going to the ethernet attached file server, and 4 was going out 
the ADSL interface. The ethernet is faster than the wifi, so the stupid 
FIFO buffering here doesn't matter, but the ADSL interface is an ATM FIFO 
single PVC again, with quite large buffer, so this can easily reach 
hundreds of milliseconds of buffering when this is full. Even if the IP 
stack might do AQM, the cell buffer is so big that the AQM empties into a 
10-20ms cell FIFO anyway, so the AQM is crippled even if it exists. Now we 
enter the DSLAM and it might have a 100 meg ethernet upstream interface, 
and you now have many hundreds of customers on this 100 meg interface 
which means it's full, but it's a L2 switch interface and it only has 5 ms 
of FIFO buffers with tail drop so it'll just drop 100% of packets at a 
certain queue depth. After this we hit a 1G router interface with 600ms 
FIFO, where if it's full, you'll get a lot of delay, often without any 
drops because most TCP flows will never reach full queue depth before the 
bandwidth/delay product is larger than available TCP window.

Phew, that was a lot of text. Anyhow, it was just an example of all the 
different places where packets can be dropped/queued in the network and 
how they might work today, and I believe there are a LOT to be done to 
improve how all these different queue points can handle traffic to give 
the end user a better network experience. This is both within the home and 
within the ISP network.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 19 Jul 2011 17:20:34 +0100

Alissa,

At 06:09 19/07/2011, Alissa Cooper wrote:
>i) Does "increased" apply only to delay, or also to loss and 
>markings? I would expect it to be the former, but from this 
>construction it's not clear. Might help to say "loss, ECN marking, 
>or increased delay."

Yes, I think the latter was meant. Thanks

However, we're likely to take John's suggestion and just cut down the 
definition of congestion to how it is measured (loss & ECN), removing 
this sentence entirely.

>ii) What is the "increase" from? Increase from zero? Increase from 
>some baseline? If "increased" only applies to delay this probably 
>doesn't need clarification, but if it applies to loss and marking 
>too, it probably does.

Another reason to cut out this sentence!

>and I think that would work fine.

I'm afraid user always means one human, so it precludes a business, a 
University or a home. We need a term for a network of users, whether 
small or large, that gets connectivity to the Internet from another network.

>enterprise, campus, or other network.

Good.

Thanks for the suggestions

Bob

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 19 Jul 2011 17:27:20 +0100

Hi Bob,

On Jul 19, 2011, at 5:20 PM, Bob Briscoe wrote:
> I'm afraid user always means one human, so it precludes a business, a University or a home. We need a term for a network of users, whether small or large, that gets connectivity to the Internet from another network.

The exact same logic applies to "consumer." Since you have to go to the length of explaining it as you do above for consumer, you could do it just as well for "user." I don't care either way, but I think either could work.

Best,
Alissa

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 19 Jul 2011 17:29:29 +0100

Alissa,

At 05:53 19/07/2011, Alissa Cooper wrote:
> >> 2. Concepts and 3. Definitions -- Right now the only concepts 
> that are fully teed up in the Concepts section are congestion 
> volume and blame (which I hope will become accountability or 
> something similar as others have suggested). So I think it's safe 
> to separate the concepts section from the definitions section.
> >

But I've taken the message that this link obviously needs to be made clearer.

>Nothing. I find it confusing to start the document by saying what it 

We're 6 pages into the text by now (not incl. the 2 pages of preamble).

Do you really mean "confusing", or just unnecessary?

Given how many people on this list have assumed some non-goals are 
goals, a number of people have been saying (including me) that we 
need to explicitly unhitch new readers from some of the more common 
preconceptions they seem to have.

I agree this shouldn't be done before we've said what ConEx is, but 
that's why it's positioned here, after the Intro, Concepts and 
Definitions, at the point where the reader should now 'get it', 
before reading on for the detail.

Still disagree?

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 19 Jul 2011 17:48:23 +0100

Alissa,

The difference is that the proposed defintion of 
the word consumer actually matches one of its 
dictionary meanings. Whereas the definition of 
"user" would have to contradict the natural 
meaning of the word user, which is definitely not good practice.

con·sum·er
    [kuhn-soo-mer] –noun
1. a person or thing that consumes.
2. Economics . a person or organization that uses a commodity or service.

courtesy dictionary.com

Bob

At 17:27 19/07/2011, Alissa Cooper wrote:
> >> If people have problems with "Consumer" you 
> could substitute "User" and I think that would work fine.
> >
> > I'm afraid user always means one human, so it 
> precludes a business, a University or a home. 
> We need a term for a network of users, whether 
>The exact same logic applies to "consumer." 
>Since you have to go to the length of explaining 
>it as you do above for consumer, you could do it 
>just as well for "user." I don't care either 
>way, but I think either could work.
>
>Best,
>Alissa

---

From: John Leslie <[email-masked]>
Date: Thu, 21 Jul 2011 14:32:17 -0400

> a conex enabled policer give if it's one policer per access port anyway? 

   It would likely drop packets which exceed the Congestion-Expected
allowance. (This is by no means the only possibility, but it seems the
most likely.)

> And how would it work when it's connected to an ISP<->ISP peering port?

   It would likely drop packets which exceed the Congestion-Expected
allowance. (Here other options seem less unlikely...)

> I always thought the policer acted on aggregation ports, ie for several 

   That is an implementation choice. There are setups where you can be
quite confident which customer sent you the packet without depending on
source address. And there are situations in which trusting the source
address is reasonable. But IMHO, trying to distinguish flows would be
a poor practice. YMMV, of course...

> I'm talking the congestion signals (re-ECN etc) that seems to be the 

   They, by definition, will be in a well-known place in the packet.

> capacity so because of *others* I can't use my full access speed", for
> the user point of view.

   I can't think of a way to do that without cooperation by your ISP.
However, the likes of DSLreports ought to be able to estimate congestion
within your ISP...

> receive, I want to know about it.

   I think we have a failure-t'communicate here. Any transport receiver
has to signal back to the sender, which may follow a congested path as
well. How this is done is not a problem for ConEx to solve.

> I want to empower the user with knowledge about congestion. I thought 
> this was a central goal of ConEx, to *expose* congestion.

   ... to the network layer: the application layer is awfully far removed
from that...

<snip>
> I run fair-queue on my access link at home, it works great.

   These seem reasonable, but not for ConEx to say...

> ADSL router would do better things than FIFO for upstream buffer 

   As I said, distribution-of-information channels don't work well. :^(

> should be very good guidance going forward.

   Hmm... I don't see where that fits in our current documents. Perhaps
you'd like to try writing an Internet Draft?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2011 21:03:07 +0200 (CEST)

>   ... to the network layer: the application layer is awfully far removed

I'm not talking about the application layer, I'm talking about 
implementing metrics the network layer could present via a dashboard to 
the user.

>   These seem reasonable, but not for ConEx to say...

If ISPs don't exmply ECN enabled handling of packets, isn't ConEx 
seriously crippled?

> you'd like to try writing an Internet Draft?

I could write text to the list which could be the basis of a discussion if 
this would fit somewhere. I'm not going to start doing the whole RFC 
document formatting thing without knowing it's actually has a reasonable 
chance of getting used. I'll see when I have some time to write something.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 22 Jul 2011 19:22:45 +0100

Hi Bob,

> Do you really mean "confusing", or just unnecessary?

I'm just trying to give a sense of my experience as the reader, having not looked at this for a number of months. I was confused to be reading about what conex does not do so early in the document, before the use cases had been fully described. Phil and Michael have likewise suggested that this section belongs at the end.

With that said, regardless of where it appears in the document, it might still create some confusion to spend two paragraphs of exposition about why per-flow fairness is generally harmful and one paragraph explaining why eliminating all congestion is not optimal without linking that explanation to conex. I think the non-goals (which, at my count, are (1) fine-grained congestion control, (2) per-flow fairness, (3) substitution for capacity planning, (4) elimination of all congestion, and (5) mitigation of self-congestion) could be stated more succinctly.

Alissa

> 
> Given how many people on this list have assumed some non-goals are goals, a number of people have been saying (including me) that we need to explicitly unhitch new readers from some of the more common preconceptions they seem to have.
> 
> I agree this shouldn't be done before we've said what ConEx is, but that's why it's positioned here, after the Intro, Concepts and Definitions, at the point where the reader should now 'get it', before reading on for the detail.
> 
> Still disagree?
> 
> 
> Bob
> 
> 
>> Alissa
>> 
>> >

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Jul 2011 04:53:30 -0400

Alissa,

OK, message received.
I'd like to try what Phil suggested: move it to later (and OK, 
shorter), but advertise it at the end of the concepts section, using 
the five bullets you list.

Reason: You, Phil & Michael don't hold these misconceptions. But 
anyone who does (which is going to be most people) is going to have 
got through the concepts section not understanding why/what is going on.

Bob

At 14:22 22/07/2011, Alissa Cooper wrote:
>I'm just trying to give a sense of my experience as the reader, 
>having not looked at this for a number of months. I was confused to 
>be reading about what conex does not do so early in the document, 
>before the use cases had been fully described. Phil and Michael have 
>likewise suggested that this section belongs at the end.
>
>With that said, regardless of where it appears in the document, it 
>might still create some confusion to spend two paragraphs of 
>exposition about why per-flow fairness is generally harmful and one 
>paragraph explaining why eliminating all congestion is not optimal 
>without linking that explanation to conex. I think the non-goals 
>(which, at my count, are (1) fine-grained congestion control, (2) 
>per-flow fairness, (3) substitution for capacity planning, (4) 
>elimination of all congestion, and (5) mitigation of 
>self-congestion) could be stated more succinctly.
>
>Alissa
>
> >
> > Given how many people on this list have assumed some non-goals 
> are goals, a number of people have been saying (including me) that 
> we need to explicitly unhitch new readers from some of the more 
> common preconceptions they seem to have.
> >
> > I agree this shouldn't be done before we've said what ConEx is, 
> but that's why it's positioned here, after the Intro, Concepts and

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Jul 2011 06:18:23 -0400

Mikael,

>a poor practice. YMMV, of course...

The idea is for ConEx info to be used to 'sanction' the immediately 
connected entity, not the entities the other side of it. Then the 
immediately connected entity can sanction its immediately connected 
entities if it so wishes.

If you do something else, it's up to you, but you're relying on 
network layer source addresses, and wasting a system (ConEx) that was 
deliberately arranged not to have to.

However, the deployment story for ConEx is a single network first, 
where this issue doesn't arise. It's only worth using ConEx in 
multiple networks once you have ECN as well (as you yourself have 
also pointed out).

>However, the likes of DSLreports ought to be able to estimate congestion

In the downstream, DSL is arranged so that the per-CVLAN queue in the 
BRAS models that customer's DSL line and drops packets as if it had a 
capacity equal to the line. Then separately there is the scheduling 
to share the backhaul network (the link between the BRAS and the 
DSLAM), which is typically a WRR scheduler also in the BRAS.

In a single network scenario, we can assume there is little loss 
upstream of the BRAS if the traffic is coming from a data centre over 
a core network. Therefore, for each customer, subtracting loss in the 
WRR queue at the BRAS from their ConEx markings will give the loss in 
the (modelled) access line.

If you also had ECN in the upstream access you can do similar tricks 
in the upstream direction. But even without ECN, at least doing it in 
the downstream is one better than anything else that can't do it at all.

However, I also wanted to interject here for a more basic 
explanation. Congestion is a property of a link or path that is the 
same for everyone using it. Whereas congestion-volume is a property 
of each user's traffic, measured by counting ConEx markings on only 
the packets of that user.

ConEx isn't merely trying to find how congested a link is. We can 
already do that. ConEx is trying to attribute which traffic 
contributed how much to the congestion. If Alice sends all her volume 
when the link is congested while Bob sends the same volume when it 
isn't, the DSL reports could be the same, but the congestion-volumes 
will be very different.

>well. How this is done is not a problem for ConEx to solve.

I agre it's not our direct problem. But in the design of the accurate 
transport feedback <draft-kuehlewind-conex-accurate-ecn> we have 
ensured that the feedback info is robust to ack losses. But that's 
probably just confusing your point, which is in general true.

> > this was a central goal of ConEx, to *expose* congestion.

Quoting conex-concepts-uses:
"2.2.  Non-Goals of ConEx and Common Misconceptions

    Congestion exposure is about the transport sender exposing congestion
    to the network, not the other way round.  That would not make sense
    given by design the transport endpoints already handle congestion in the
    TCP/IP protocol suite.
"

Nonetheless, by exposing congestion to the operator, it makes the 
operator able to do something about the user's congestion, which 
motivates {apps|transport protocols|the user} to do something with 
their pre-existing knowledge of congestion.

> > certain queue depth, for instance 20-30 ms queue depth.

Yup, altho just RED would be enough - maybe you mean that.

>For access links,

FQ crudely carves up each customer's usage into equal bit-rates. 
That's better than nothing, but it's very over-constraining. Quoting 
again from new text in concepts-uses:

"   Since then capacity has been shared by a mix of traffic management
    approaches, partly network-based (weighted round-robin scheduling,
    weighted fair queuing, etc) and partly host-based (TCP).  However, in
    recent years, network operators became concerned that a relatively
    small number of end-machines were consuming a disproportionately high
    share of network resources.  This is actually because both TCP and
    all the traditional network-based approaches only share out a
    bottleneck at each instant.  They fail to take account of how much of
    the time a consumer is keeping the link busy, which is the main
    factor that determines everyone else's bit-rate.
"

> > I run fair-queue on my access link at home, it works great.

Have you tried running uTP and Web at the same time through your FQ? 
FQ forces them to have equal bit-rate, even tho uTP is trying to 
allow the Web flows to temporarily take more of the capacity.

Also if you put multiple variable bit-rate videos through FQ, it 
forces them all to get constant bit-rate service. Through a given 
backhaul link, relative to CBR, a good VBR codec can get more than 
twice as many videos through. If you turn on FQ, it removes the 
ability to multiplex all the peaks and troughs, and you can only get 
half the videos through, as if they were CBR again. See "Equitable 
quality video streaming over DSL," via 
<http://bobbriscoe.net/projects/refb/index.html#Weighted_andor_Proportionally_Fair>

> > ADSL router would do better things than FIFO for upstream buffer

Not so. Many home gateways have fairly complex queuing arrangments in 
the upstream with what is essentially simple DPI to classify flows 
into the different queues. Admittedly, many also have rubbish 
implementations and bugs, but we tested many of them and there are a 
few good ones. I'm not saying DPI is a good way to go. I'm just 
saying what's out there.

>you'd like to try writing an Internet Draft?

Altho this isn't the bailiwick of ConEx, this is the goal of a 
different draft that a bunch of us have promised to write, but just 
not got round to it (yet). It's under the ICCRG (IRTF). However, it 
looks like you & I have some disagreements to discuss before we would 
be able to write anything approaching consensus.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Jul 2011 10:51:39 -0400

Alissa,

I said I was going to respond to each of your suggested changes in 
chunks, moving to the next as discussion closes on the previous...

Inline...

At 08:58 18/07/2011, Alissa Cooper wrote:
>Hi Bob,
>
>I am finding the organization of the document somewhat confusing. 
>With the introduction of new text in early sections, it has also 
>become a bit repetitive in parts. I'll throw out an alternative 
>organization below with some explanation afterward:
>
>1. Introduction
>2. Concepts
>3. Definitions

Including non-congestion management approaches (DPI etc) under the 
main section heading "Congestion Management" seems to contradict or 
at least confuse the message that these techniques should not 
actually be classified as congestion management.

>         4.4 Use Case Description

This heading needs to be where the term "Informing Congestion 
Management" appears. But that doesn't make it clear that ConEx is 
informing the Operator - in fact it could be skim-read as host 
congestion management.

The problem is that ConEx redefines who does Congestion Management 
(operator not just host) and who does Traffic Management (host - 
LEDBAT/QoS - not just network). So preconceptions on who does these 
functions get in the way.

>4. Core Use Case: Informing Congestion Management -- As of now the 
>document sort of wavers between emphasizing traffic management (what 
>I'm calling congestion management) as the key motivating use case 
>and mixing in some of the other motivating use cases.

I think your structure misses the point (made on the list, not in the 
current draft yet, other than in the section headings) that LEDBAT & 
QoS have traffic management as a pre-requisite. ConEx is about 
co-operative traffic management. Also see later discussion.

>A clearer separation would help, I think.

I more strongly disagree about this point than anything else. What we 
have been trying to do all along is to ensure a single message comes 
out of this doc: ConEx does good traffic management and gets the 
hosts and network to co-operate in same.

That's why LEDBAT & QoS were main use-cases with traffic management, 
and the Others were "Other".

A more nitty point was that we had bulletted the "Others" rather than 
given them separate section headings, because we wanted just a few 
sentences on each, because we didn't want to allow them to push the 
main message out of mind.

>repetitive, thus my suggestions for streamlining 4.1-4.4 above. 4.1 
>maps to the current intro to section 3; 4.2 maps to the first part 
>of the current 3.1; 4.3 maps to the second part of the current

The existing approaches have been an evolution: Each time a problem 
has arisen with one approach another has been added. That's the story 
in the Intro and it's given in more detail here.

Altho it seems that splitting existing approaches and problems with 
existing approaches would make sense, it wouldn't flow given this 
patch-problem-patch-problem-patch-problem history.

>3.1 plus the ECN discussion currently in 4.1; and 4.4 maps to the 
>current 5.1. I think parts of the intro to the current section 4 are 
>now redundant and other parts can be fit in to the subsections above 
>as appropriate (e.g., the LEDBAT discussion could go in the suggested 5.1).

I can't parse the section numbers here - I am beginning to think 
there are some typos.

The current 5.1 is "Inform the Operator's Traffic Management"
* How does "3.1 Existing Approaches to Traffic Management" map to that?
* How does ECN discussion map to that?
* I can only see how 4.4 "Use Case Description" maps to that

>although phrased in the active voice. I find the distinction between 
>consequences and use cases to be of little use; in every case, ConEx 
>just exposes information and it is up to the operator to act on it, 
>so in some sense every use case is a consequence. For the "Informing 
>Traffic Management" case, for example, I don't think the expectation 
>is that operators will merely be glad to have more information, but 
>they will actually act on it (perhaps by using an ingress policer as 
>described). The same can be said for incentivizing scavenger 
>transports: the operator has to take affirmative steps using the 
>ConEx information to create the incentives. I don't see the 
>difference between the two.

The point Phil made, which I liked, was that a use-case shouldn't be 
described as if it is a separate use case, if it can only exist after 
another use-case has happened.

Things consumers (or their software-providers) do (LEDBAT, QoS) in 
response to ConEx traffic management fall into this category.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Jul 2011 11:07:24 -0400

Alissa,

The final posting in this series, on your last point, inline...

At 08:58 18/07/2011, Alissa Cooper wrote:
>7. Commercial Secrecy as a Potential Deployment Barrier and 8. 
>Non-Goals -- From the text it seems like dealing with 
>self-congestion is a non-goal, so it probably can be fit in the 
>non-goals section. And I agree with earlier reviewers that putting 
>non-goals up front is a non-starter. If the section is listed in the 
>ToC and previewed at the end of the introduction, people who are 
>confused will be able to find it (as opposed to possibly confusing 
>many people by putting it up front before the actual goals have 
>really been discussed).

I don't think anyone is saying that distinguishing self-congestion 
from shared congestion is a non-goal. But many people are saying 
ConEx (or re-ECN?) can't distinguish these, and that it should be 
able to. That means self-congestion is a "potential issue".

Also, I've proposed a way the two can be distinguished in some 
important cases (see recent mail to Mikael), but I know it's not 
possible in some cases. Therefore this is a non-issue sometimes, and 
a potential issue others.

That's why we created a Potential Issues section and made Commercial 
Secrecy a sub-section, and self-congestion another subsection.

Whatever, we want to move text about self-congestion from the 
introduction, where it was in -01.

Bob