Subject: [conex] my personal views on draft-ietf-conex-concepts-uses

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 5 Apr 2011 16:20:34 +0100

Hi All,

As I am no longer editor of draft-ietf-conex-concepts-uses I can express my
views on the document as an individual (rather than as the representative of
the of the co-authors).

Having had a thorough re-think about how best to progress ConEx through the
IETF, I have come to the conclusion that the current draft is failing
because it tries to do too much for a single document. In its current form,
the document is doing two things. It seeks to explain the rationale of ConEx
and it tries to give a list of use cases where ConEx seems to add most
value. I now think these two parts can't exist in a single document since
the latter tends to distract attention from the former.

Marcelo ad Nandita have lofty ambitions for this document, which should
serve as the ambassador for ConEx. This should be the document that silences
our critics, or at least shows them that their fears about ConEx are
unfounded. It should also act to enthuse the developer, vendor and operator
communities to start working on ConEx and thus start the ball rolling for
eventual deployment.

So my proposal to the new editing team is as follows. 

.         Re-write  the introduction of the draft to provide a clear
motivation for ConEx

.         Write a section explaining what Conex is and (importantly) what it
isn't. This needs to contrast it to alternative approaches (such as
over-provisioning) and show how those alternative approaches are flawed. 

.         Then have a short section using a single network deployment as an
example of how ConEx can operate (for instance, using ConEx as a mechanism
to control the usage of a resource-constrained shared network such as those
that are provided for students on university campuses). This should be
explained in terms of familiar concepts (the approach taken in [policing
freedom], where the policer is described in terms of a token bucket).

.         Then give a detailed use case for the "charter scenario" of
partial deployment with only sender and sender's network ConEx-enabled. This
needs to show how (for instance) the sender's network can use ConEx to
ensure that user's are not contributing to local congestion and are thus not
causing other users to suffer a degradation in service.

.          Finally have a complete section on partial deployment models (the
third bullet on Bob's list). This would look at the different arrangements
of networks (sender, core, receiver), what each network needs to do about
conex and what advantages it gets through being conex aware.

Such a document would best be called "ConEx Concepts and Motivations". By
limiting the use cases described in the document it allows people to focus
on what ConEx is actually doing and how it works. Until they understand
that, there is no point trying to convince them of the huge range of uses to
which it can be put.

Then we can create a separate document bringing together all the other use
cases and incorporating some of the individual work that has been
contributed to ConEx. That document can be published a bit later than the
other one and it can then assume that people are able to understand ConEx
properly.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 6 Apr 2011 00:53:54 +0200

Hi Toby,

I believe thats a very good proposal! I was always looking at the use case doc 
as something that can be read by somebody who heard the first time of ConEx 
and wants to get an idea of what ConEx is good for. That means understanding 
the/a benefit of ConEx without knowing all the details about the mechanism. 
The use case draft in the current state is probably more confusing than 
anythingelse. Splitting up into two doc sounds for me as the right way 
forward to reach both goals - explaining the benefit of ConEx to an ingenuous 
reader and documenting possible use cases to be considered in deployment.

Mirja

P.S.: Thx for the effort you put into this draft and also previous versions!

On Tuesday 05 April 2011 17:20:34 Toby Moncaster wrote:
> views on the document as an individual (rather than as the representative
> of the of the co-authors).
>
>
>
> the document is doing two things. It seeks to explain the rationale of
> ConEx and it tries to give a list of use cases where ConEx seems to add
> most value. I now think these two parts can't exist in a single document
> since the latter tends to distract attention from the former.
>
>
>
> serve as the ambassador for ConEx. This should be the document that
> silences our critics, or at least shows them that their fears about ConEx
> are unfounded. It should also act to enthuse the developer, vendor and
> operator communities to start working on ConEx and thus start the ball
> rolling for eventual deployment.
>
>
>
> .         Write a section explaining what Conex is and (importantly) what
> it isn't. This needs to contrast it to alternative approaches (such as
> partial deployment with only sender and sender's network ConEx-enabled.
> This needs to show how (for instance) the sender's network can use ConEx to
> ensure that user's are not contributing to local congestion and are thus
> not causing other users to suffer a degradation in service.
>
> .          Finally have a complete section on partial deployment models
> (the third bullet on Bob's list). This would look at the different
> arrangements of networks (sender, core, receiver), what each network needs
> to do about conex and what advantages it gets through being conex aware.
>
>
>
> that, there is no point trying to convince them of the huge range of uses
> to which it can be put.
>
>
>

-- 
-------------------------------------------------------------------
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: John Leslie <[email-masked]>
Date: Wed, 6 Apr 2011 15:27:01 -0400

Toby Moncaster <[email-masked]> wrote:
> 
> - Re-write  the introduction of the draft to provide a clear
>   motivation for ConEx
> 
> - Write a section explaining what Conex is and (importantly) what it
> - Then have a short section using a single network deployment as an
>   example of how ConEx can operate (for instance, using ConEx as a
>   mechanism to control the usage of a resource-constrained shared
>   network such as those that are provided for students on university
>   campuses). This should be explained in terms of familiar concepts
>   (the approach taken in [policing freedom], where the policer is
>   described in terms of a token bucket).
> 
> - Then give a detailed use case for the "charter scenario" of partial
>   deployment with only sender and sender's network ConEx-enabled. This
>   needs to show how (for instance) the sender's network can use ConEx
>   to ensure that user's are not contributing to local congestion and
>   are thus not causing other users to suffer a degradation in service.
> 
> - Finally have a complete section on partial deployment models (the
>   third bullet on Bob's list). This would look at the different
>   arrangements of networks (sender, core, receiver), what each network
>   needs to do about conex and what advantages it gets through being
>   conex aware.
> 
> Such a document would best be called "ConEx Concepts and Motivations".
> By limiting the use cases described in the document it allows people
> to focus on what ConEx is actually doing and how it works. Until they
> understand that, there is no point trying to convince them of the huge
> range of uses to which it can be put.

   I agree with Toby.

--
John Leslie <[email-masked]>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 7 Apr 2011 11:03:50 +0200

Hi all

I agree with the opinion of Toby on having a draft that will focus on ConEx
Concepts and Motivations. 

Best regards,

Georgios

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Toby Moncaster
Sent: dinsdag 5 april 2011 17:21
To: [email-masked]
Subject: [conex] my personal views on draft-ietf-conex-concepts-uses

Hi All,

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Apr 2011 15:35:22 +0100

Toby, (& Mirja, John, Georgios)

I want to take one step back before deciding 
whether to split this into two (and if so, how to split it).

Firstly, in Prague, we identified two very 
different things that can both be ambiguously called use-cases:
a) Uses to which ConEx can be put (traffic 
management, incentivising scavenger, differential QoS, etc)
b) Deployment arrangements (the single network 
scenario in the charter, mobile, data centre, etc)

When you suggest we should remove discussion of 
use-cases, you seem to be talking about removing 
a). Correct? I want to argue that a) should be 
in, but b) should be cut-down - mostly to a list of pointers to other docs...

The co-authors who were in Prague (Rich, David & 
I) got together and did a similar 'drains up' 
exercise on the structure of this doc. Firstly, 
we realised that the doc should start with high 
level material similar to that used in early ConEx BoFs etc. In particular:
- Rich Woundy did a presentation at the GIIC 
workshop on capacity sharing that listed what 
Comcast's fairshare could do, but also what it 
could not do and what ConEx provided (slide 13 of 
http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf).
- Alissa Cooper's presentation at the IETF ConEx 
BoF had a good list of ConEx benefits (last slide 
here: <http://www.ietf.org/proceedings/77/slides/conex-3.pdf>).

We came up with the following elements that need 
to be articulated, whether in one or in more 
documents. I've embellished the list with numbers 
that refer to existing sections in conex-concepts-uses-01

A. The Apparent Problems (1 & tba) & the Underlying Problem (tba)
B. Misconceptions (tba) and problems with other approaches (incl Rich's list)
C. ConEx Concepts (2, 5.3) and what ConEx is not (tba)
D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list)
E. Deployment arrangements (5.5 & tba)
F. Potential Issues (7)

If we have anything about deployment 
arrangements, we have to make space to describe 
and motivate the components (but at much higher 
level than in conex-abstract-mech).

So, for deployment arrangements, I see two possible alternatives:

i) A rudimentary section:
- a very high level discription of the components 
in abstract-mech and where they would be placed 
in the charter deployment arrangement
- one sentence bullets describing other 
deployment arrangements, with refs to other docs for each.

ii) An extremely rudimentary section:
- one sentence bullets describing other 
deployment arrangements, with refs to other docs 
for each (including someone writing another doc about the chartered scenario).

On balance, I prefer i), to make this document 
sufficiently self-contained. But I'm aware it 
will make the doc a couple of pages longer.

Bob

At 16:20 05/04/2011, Toby Moncaster wrote:
>Content-Type: multipart/alternative;
>         boundary="----=_NextPart_000_0041_01CBF3AD.647B3900"
>Content-Language: en-gb
>
>Hi All,
>
>As I am no longer editor of 
>draft-ietf-conex-concepts-uses I can express my 
>views on the document as an individual (rather 
>than as the representative of the of the co-authors).
>
>Having had a thorough re-think about how best to 
>progress ConEx through the IETF, I have come to 
>the conclusion that the current draft is failing 
>because it tries to do too much for a single 
>document. In its current form, the document is 
>doing two things. It seeks to explain the 
>rationale of ConEx and it tries to give a list 
>of use cases where ConEx seems to add most 
>value. I now think these two parts can’t exist 
>in a single document since the latter tends to 
>distract attention from the former.
>
>Marcelo ad Nandita have lofty ambitions for this 
>document, which should serve as the ambassador 
>for ConEx. This should be the document that 
>silences our critics, or at least shows them 
>that their fears about ConEx are unfounded. It 
>should also act to enthuse the developer, vendor 
>and operator communities to start working on 
>ConEx and thus start the ball rolling for eventual deployment.
>
>·         Re-write  the introduction of the 
>draft to provide a clear motivation for ConEx
>·         Write a section explaining what Conex 
>is and (importantly) what it isn’t. This needs 
>to contrast it to alternative approaches (such 
>as over-provisioning) and show how those alternative approaches are flawed.
>·         Then have a short section using a 
>single network deployment as an example of how 
>ConEx can operate (for instance, using ConEx as 
>a mechanism to control the usage of a 
>resource-constrained shared network such as 
>those that are provided for students on 
>university campuses). This should be explained 
>in terms of familiar concepts (the approach 
>taken in [policing freedom], where the policer 
>is described in terms of a token bucket).
>·         Then give a detailed use case for the 
>“charter scenario” of partial deployment with 
>only sender and sender’s network ConEx-enabled. 
>This needs to show how (for instance) the 
>sender’s network can use ConEx to ensure that 
>user’s are not contributing to local congestion 
>and are thus not causing other users to suffer a degradation in service.
>·          Finally have a complete section on 
>partial deployment models (the third bullet on 
>Bob’s list). This would look at the different 
>arrangements of networks (sender, core, 
>receiver), what each network needs to do about 
>Such a document would best be called “ConEx 
>Concepts and Motivations”. By limiting the use 
>cases described in the document it allows people 
>to focus on what ConEx is actually doing and how 
>it works. Until they understand that, there is 
>no point trying to convince them of the huge 
>Then we can create a separate document bringing 
>together all the other use cases and 
>incorporating some of the individual work that 
>has been contributed to ConEx. That document can 
>be published a bit later than the other one and 
>it can then assume that people are able to understand ConEx properly.
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: John Leslie <[email-masked]>
Date: Thu, 7 Apr 2011 11:22:27 -0400

Bob Briscoe <[email-masked]> wrote:
> a) Uses to which ConEx can be put (traffic management,
>    incentivising scavenger, differential QoS, etc)

   This is what we've been calling use cases.

> b) Deployment arrangements (the single network scenario
>    in the charter, mobile, data centre, etc)

   This we've been calling usage scenarios.

> a). Correct?

   Yes.

> I want to argue that a) should be in, but b) should be cut-down -
> mostly to a list of pointers to other docs...

   Feel free to argue...

> The co-authors who were in Prague (Rich, David & I)
> got together and did a similar 'drains up' 

   That's pretty heavy on Comcast's current FairShare...

   It does list Advantages of re-ECN over FairShare:
- Re-ECN enables end-to-end congestion management 
- Re-ECN enables end-to-end congestion management 
- Re-ECN signals the presence of congestion to user 
  applications and to all devices on the network path 
- Re-ECN enables additional user and/or application 
  responses to congestion 
- Re-ECN enables DDoSmitigation and other capabilities

   I'm not sure these are the correct things to list in conex-concepts
In particular, we as authors agreed to defer discussion of DDoS.

>   here: <http://www.ietf.org/proceedings/77/slides/conex-3.pdf>).

   That lists Benefits of congestion exposure:
- Incentivizes reduced-congestion protocols like LEDBAT
- Exposes congestion end-to-end, across network borders
- Provides transparancy at every network node
  - Also good for capacity planning
- Avoids cat-and-mouse with apps developers, other
  drawbacks of application-based approaches
- Any-to-any traffic: enables Internet-wide solutions

   This doesn't strike me as the best introduction for conex-concepts.
It lists where we'd like to get, rather than actual concepts of what
we propose to do.

> A. The Apparent Problems (1 & tba) & the Underlying Problem (tba)

   I think the apparent & underlying probems are better understood
today than they were at IETF-77. We need to elaborate what we hope
to _do_.

> B. Misconceptions (tba) and problems with other approaches (incl

   I know you disagree with me here, but experience suggests that a
list of "misconceptions" is an _excellent_ way to lose an audience.

> C. ConEx Concepts (2, 5.3) and what ConEx is not (tba)

   We need to get text talking about what ConEx _is_. The universe
of what ConEx is-not is just too large. (Again, I know you disagree
with me.)

> D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list)

   This is getting beyond what Toby proposed. I'm waiting for your
argument why it needs to be in the same document...

> E. Deployment arrangements (5.5 & tba)

   (No comment.)

> will make the doc a couple of pages longer.

   I think we agree that deployment scenarios don't belong in the
first-document Toby proposes.

   (Did I miss your argument why Uses & Benefits _do_ belong there?)

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 7 Apr 2011 16:07:37 +0000

Do we have an agreed path forward on what to do with the concepts-use cases document? I worry that we do not.

> That's pretty heavy on Comcast's current FairShare...

In Conex, I have tried to avoid spending too much time discussing FairShare. The purpose of Conex isn't to promote FairShare, in my view.

However, FairShare is documented (RFC 6057), and goes about as far as one can go with congestion management using current specifications and deployments. So it is one baseline to defend why we need Conex.

But that's why I wanted to include Alissa's discussion of other alternatives (throwing capacity at the problem, and volume-based / rate-based / application-based approaches).

> In particular, we as authors agreed to defer discussion of DDoS.

Yes, that was always understood.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Leslie
Sent: Thursday, April 07, 2011 11:22 AM
To: Bob Briscoe
Cc: [email-masked]
Subject: [conex] Splitting concepts-uses

   Yes.

   Feel free to argue...

   (No comment.)

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 7 Apr 2011 17:28:21 +0100

I am purposely replying to Bob's email, not to John's response. I will reply
to John's email separately...

> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 07 April 2011 15:35
> To: Toby Moncaster
> Cc: [email-masked]; Mirja Kuehlewind; John Leslie; Georgios Karagiannis
> Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-
> uses
> 

I am (I think) arguing that we need to concentrate on doing ConEx in little
chunks (the horrid MBA phrase seems to be baby steps). We have a very
restrictive charter at present, reflecting a good deal of scepticism on the
part of the IESG. So what we need to do is show how even that limited form
of ConEx is worth doing, not by arguing for philanthropic deployment, but by
showing how (say) an ISP can better manage their own customers' traffic

> scenario in the charter, mobile, data centre, etc)

This confusion has been reigning for some months now, and there have been
discussions about it in the past. Really the charter should be changed.
Currently it says:

" It is believed that the CONEX mechanism will be useful as a generative
  technology that can be applied as a key element of congestion
  management solutions in a wide variety of use cases. However, the
  CONEX WG will initially focus on one use case, where the end hosts
  and the network that contains the destination end host are CONEX-enabled
  but other networks need not be."

Which uses "use case" where it should say "usage scenario" or similar.

> in, but b) should be cut-down - mostly to a list of pointers to other

I am arguing that we should remove large parts of a), just keeping
sufficient to be able to accurately explain how ConEx achieves things that
are beyond current capabilities. I was envisaging doing this using 1 or 2
simple scenarios (such as FairShare vs ConEx policing).

As things stand, we already have lots of "use cases" for ConEx that go
beyond the current charter. And lots that are being deferred to individual
drafts, etc. 

What this document has to do is convince people that deploying the limited
version of ConEx enshrined within the charter will give them a benefit.
Telling them "it would be brilliant if lots of networks all did this" is
translated by some people into "it must be useless if only 1 network does
this"

> level material similar to that used in early ConEx BoFs etc. 

I would sound a definite note of caution. In total it took 3 BoFs and
countless fringe meetings to get ConEx chartered. That does suggest that at
least some of the explaining we did early on was confusing people.

I believe the current draft (the one the WGCs are so worried by) suffers
from over-explaining in many cases. All too often we have tended to respond
to a few people questioning what we meant by adding more detail, tightening
up a definition or adding new text. What we need to do is get to the bottom
of why so many people are confused in the first place.

> In
> particular:

The problem with both these lists is that they don't make it clear why you
want to do those things. Some people who claim over-provisioning is the
panacea for everything might wonder why you want to do this at all, as they
argue congestion is a transient event that can be effectively ignored.

> C. ConEx Concepts (2, 5.3) and what ConEx is not (tba)

We need to be careful how we express "what ConEx is not". There are two
elements to these: avoiding misconceptions about what it is and providing
people with a familiar framework to enable them to grasp what ConEx actually
is. The second aspect is useful. Clearly the description of the policer in
[policing freedom] allowed a lot of people to understand what we were
describing. But the list of misconceptions is so long that trying to cover
all of them would be impossible. Much better to pick a couple and stick to
them. I would argue the biggest ones (that keep cropping up) are: "ConEx
needs per-flow state" and "ConEx requires every node to be updated".

> will make the doc a couple of pages longer.

I agree that i) seems the more sensible of the two approaches, but keeping
the high level descriptions to a line each, keeping it all as brief as
possible and limiting the amount of referencing to what is essential. 

> >value. I now think these two parts can't exist
> >.         Re-write  the introduction of the
> >.         Write a section explaining what Conex
> >is and (importantly) what it isn't. This needs
> >.         Then have a short section using a
> >.         Then give a detailed use case for the
> >"charter scenario" of partial deployment with
> >only sender and sender's network ConEx-enabled.
> >sender's network can use ConEx to ensure that
> >user's are not contributing to local congestion
> >.          Finally have a complete section on
> >Bob's list). This would look at the different
> >Such a document would best be called "ConEx
> >Concepts and Motivations". By limiting the use

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 7 Apr 2011 17:29:06 +0100

And a reply to John's email

> Sent: 07 April 2011 16:22
> To: Bob Briscoe
> Cc: [email-masked]

The confusion seems to have crept in because of bad wording in the charter
(which confuses the two concepts)

> > use-cases, you seem to be talking about removing

See other reply -- I want to remove large chunks of this but not all.

>    That's pretty heavy on Comcast's current FairShare...

One could use that as an example of what ConEx isn't perhaps. It does nicely
fit the charter scenario...

> In particular, we as authors agreed to defer discussion of DDoS.

The decision to defer DDoS was ratified by the WG and Marcelo...

The problem with this list is that it is not telling you /why/ you want to
do those things.

> It lists where we'd like to get, rather than actual concepts of what

That list (or parts of it at any rate) may be useful, particularly in the
conclusions to the document. We can also put it upside down and use these as
ways that current approaches are flawed.

> list of "misconceptions" is an _excellent_ way to lose an audience.

We certainly don't want this to turn into something that can be misconstrued
as "getting at" any group in the IETF. The problem with trying to list the
misconceptions is that there are so many of them. This also applies to
listing "what ConEx isn't"

> of what ConEx is-not is just too large. (Again, I know you disagree

See other reply

> > D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list)

Benefits might belong, but putting in too many use cases just seems to
distract and lead to people getting the wrong end of the stick.

> > E. Deployment arrangements (5.5 & tba)

These need to be looked at again in detail. If the document is meant to be
about motivations for ConEx, then this section needs to be about the
opposite (demotivations as you might put it) 

> first-document Toby proposes.

See other reply

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 07 Apr 2011 18:56:21 +0000

Hi Bob

We could have two drafts:

In my opinion it is important to have a draft that motivates the need of
the solutions provided by Conex. In order to accomplish this it is
important, in my opinion, to explain and compare at least:

* a current end to end use case/scenario that uses per flow state in
network entities that are able of providing policing and
auditing/dropping features

* a Conex end to end use case/scenario that provides similar policing and
auditing/dropping features.

Another draft that describes possible Conex use cases/scenarios.

Best regards,
Georgios

---

From: João Taveira Araújo <[email-masked]>
Date: Fri, 08 Apr 2011 13:46:15 +0900

Hi,

> list of "misconceptions" is an _excellent_ way to lose an audience.

I'd just like to emphasize this point and agree with John here. 

It doesn't seem appropriate to include a list of misconceptions on the very document responsible for introducing the concepts behind conex to an unfamiliar audience. Yes, there is a lot of baggage and experience from trying to explain re-ECN which gives us some intuition on what questions are most likely to come up, but we should use that to flesh out the text and make those points clear.  In my opinion having a section on misconceptions feels like historical revisionism and would likely increase skepticism rather than instill confidence.

Cheers,
Joao.

---

From: <[email-masked]>
Date: Fri, 8 Apr 2011 10:40:51 +0100

Personally I think another good starting point is the technical plenary presentations [the tech plenary in Maastricht(?) on Economics of Congestion]. As far as I could tell, the audience understood the argument, even if some disagreed with it (and at some conex presentations my impression is that some people haven't understood the argument).

I also think it is better to start by giving people the "main point" and then work through issues and arguments supporting it. By "main point" I mean something like 'what idea are you trying to embed in the reader's brain'. 1-2 pages motivational pages before the "main point" is ok, but lengthy discussions of related work & issues before the "main point" will tend to mean the average reader either gets bored or forgets what the main point is. (of course the "average reader" here means me!). so for instance explain the use cases, then the comparison with today's approaches and perhaps why the use case is useful.  I draw an analogy with writing a paper, where related work (in my opinion) belongs at the end. 

So what are the main point(s? 
I think one main point is 'enabling IP nodes to see information about whole-path congestion enables some very interesting uses'. 
Another one is 'there is at least one reasonable deployment arrangement' (reasonable meaning incremental and motivated for the party(s) deploying). 
Each of these main points can be treated separately.

Getting these main points right is quite tricky, and I'm not sure I got them right (but after some thought I didn't write 'conex has some interesting use cases'). But i think it would help to decide what they are before writing. 

Another question is whether the doc is standalone? Can the reader to be referred to the abstract mechanism i-d, or does this doc need to include conex's "protocol model", as per rfc4101: "a short description of the system in overview form ... to answer three basic questions: 1. What problem is the protocol trying to achieve? 2. What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol?"
If the doc is standalone, then a protocol model could be the first section

Anyway, I suspect the authors have more than enough advice!!

Best wishes
Phil/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: 07 April 2011 15:35
To: Toby Moncaster
Cc: [email-masked]
Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses

Bob

At 16:20 05/04/2011, Toby Moncaster wrote:
>*         Re-write  the introduction of the 
>*         Write a section explaining what Conex 
>*         Then have a short section using a 
>*         Then give a detailed use case for the 
>*          Finally have a complete section on

---

From: <[email-masked]>
Date: Fri, 8 Apr 2011 16:02:36 +0100

Also, in the Use Cases section, i think you should distinguish between the use case and the side impacts.

For example:
Use case: On a fast timescale (msecs to secs) the operator uses conex information to inform its per-customer traffic management
How: operator installs a token bucket policer per customer (rate of conex marks, burst size)
Side impacts: end customer differentiates QoS amongst their apps (and consequently also motivates them to use scavenger)
Benefits compared with current solutions: (Comcast Fairshare) 

Phil/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 08 April 2011 10:41
To: Briscoe,RJ,Bob,DES8 R; [email-masked]
Cc: [email-masked]
Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses

Best wishes
Phil/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: 07 April 2011 15:35
To: Toby Moncaster
Cc: [email-masked]
Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses

Bob