Subject: Re: [conex] Intent of charter: division of concepts across docs

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 Jul 2010 23:35:33 +0100

Nandita,

[Adding the list]

My prejudices go like this:

>- Which doc should aim to be a stand-alone introduction to ConEx?

* Use-cases (the one we've written covers "Concepts and Use-cases", 
which allows us to make it an introductory doc)

also, Abstract ConEx Mechanism should be possible to understand 
without having read use-cases first, but I imagine it will be more 
focused just on the mechanisms, not why they are there, nor different 
ways they might go together.

>- Which doc would be best to define ConEx terminology?

* Abstract ConEx mechanism

But, as use-cases has to go first, it will have to define terminology 
for its own use. So we should try to have a decent version of the 
Abstract ConEx mechanism before w-g submits use-cases for RFC.

>- Where should we discuss incremental deployment and deployment incentives.
>  (is use-cases more about *what* ConEx is used for than *how* it's used)
>  (we surely want a more detailed check on incremental deployability 
> once we've defined the detailed protocol)

Multiple places with increasing degress of solidity:
* In use-cases (with some vagueness allowed)
* In each experimental track doc, protocol specifics for partial 
deployment have to be defined
* In one or more of the informational evaluation docs, I would expect 
to see a more precise evaluation of how well a partial deployment 
worked, or whether there were incentives to start deployment and so forth.

Bob

At 21:21 23/07/2010, Nandita Dukkipati wrote:
>Bob,
>
>That's a great question and I believe we should set aside time in 
>the WG for this discussion. Given that we have ~40 mins. left in the 
>slot, I don't see an issue time wise. Marcello may comment as well.
>
>That said, could you come up with a plan (and post to the list) on 
>what would be the most logical way of mapping these questions to the 
>chartered documents. The discussion will be more focussed and 
>targeted if we begin with your plan as starting point.
>
>Thanks,
>-Nandita
>
>On Fri, Jul 23, 2010 at 12:49 PM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>Nandita, Marcelo,
>
>I want to start a discussion for anyone on the list, but you (the 
>chairs) may have initial views to kick this off.
>
>It's not immediately obvious in which of the 4 chartered docs the 
>following concepts belong (if indeed we choose to write exactly the 
>same number of docs as there are bullet pointed docs in the charter):
>
>- Which doc should aim to be a stand-alone introduction to ConEx?
>- Which doc would be best to define ConEx terminology?
>- Where should we discuss incremental deployment and deployment incentives.
>  (is use-cases more about *what* ConEx is used for than *how* it's used)
>  (we surely want a more detailed check on incremental deployability 
> once we've defined the detailed protocol)
>
>These questions have arisen in writing draft-moncaster-conex-concepts-uses
>
>Do you intend to put aside some time in the w-g on Tue for 
>discussing these sort of doc co-ordinating questions?
>
>
>Bob
>
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: John Leslie <[email-masked]>
Date: Fri, 23 Jul 2010 19:54:48 -0400

>   which allows us to make it an introductory doc)

   I think the rest of the authors agree: I certainly do.

>  ways they might go together.

   The Mechanism document will get specific about a number of things
we've intentionally left vague so far, but IMHO it shouldn't go into
detail about _why_ you might use the mechanisms.

> * Abstract ConEx mechanism

   A perhaps surprisingly important issue...

> Abstract ConEx mechanism before w-g submits use-cases for RFC.

   So far, Use-Cases has defined terminology "for its own use," and
this has made Bob uneasy. He's quite determined that the "real"
definitions should provably deliver what they promise, and fears that
the Use-Cases definitions will imply promises to deliver something we
can't deliver.

   I, at least, and the rest of the authors to some extent, believe
that definitions can evolve as the WG progresses. For one obvious
example, I have pretty strong opinions an what "congestion" should
mean in its "real" definition; but I am not concerned as we run
through much-less-rigorous mini-definitions in early documents.

   I would not tend to support holding up the Use-Cases document
for nailing down details of definitions of terms in some later
document.

>> - Where should we discuss incremental deployment and deployment
>>   incentives. (is use-cases more about *what* ConEx is used for
>>   than *how* it's used)

   We could use some WG guidance here. The _question_ of deployability
must be tackled in the Use-Cases document, but it seems to me to be
inappropriate to lay out many details of deployment (not least since
actual deployment won't follow our plan anyway).

   I'd like to punt most of the details to another document...

>>   (we surely want a more detailed check on incremental
>>    deployability once we've defined the detailed protocol)

   I agree with Bob here.

> * In use-cases (with some vagueness allowed)

   I'd go for "quite a bit" of vagueness...

>   deployment have to be defined

   I agree with Bob here.

> * In one or more of the informational evaluation docs, I would
>   expect to see a more precise evaluation of how well a partial
>   deployment worked, or whether there were incentives to start
>   deployment and so forth.

   "Worked so far," of course...

   I agree with Bob that review of how deployment is coming along
is essential; and I despair of predicting what this will show.

   I _have_ considered deployment incentives at length, but I'm
disinclined to put much of my musings into the Use-Cases document.
A deployment plan is an essential piece of the Experiment-track
documents we will write; and it should be specific enough to
report to what extent the experiment succeeds in deployment.

--
John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 24 Jul 2010 10:51:37 +0100

John,

I agree with you on not holding up use-cases for the sake of 
terminology definitions in the abstract mechanism doc.

That's a message for us to get going with the abstract mech doc, not 
to hold up use-cases if we don't.

I was merely saying *it would be nice" to have a decent version of 
the abstract mechanisms doc with a decent consensus on what 
terminology we're going to use before use-cases gets to RFC. If 
people read use-cases as a gateway into the work, terminology 
inconsistent with later docs will confuse.

Terminology is a non-trivial task for ConEx because there's a fair 
few new concepts that the IETF doesn't already have words for.

Bob

---

From: John Leslie <[email-masked]>
Date: Sat, 24 Jul 2010 08:33:37 -0400

> to hold up use-cases if we don't.

   I'm nervous about starting into a new document without guidance
from the chairs...

> inconsistent with later docs will confuse.

   I don't think the confusion is necessarily that bad...

> few new concepts that the IETF doesn't already have words for.

   I agree with that.

   Might I suggest working on terminology in the ConEx wiki:

http://trac.tools.ietf.org/wg/conex/trac/wiki

---

From: Nandita Dukkipati <[email-masked]>
Date: Sun, 25 Jul 2010 22:50:48 +0000

On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe <[email-masked]>wrote:

> * Use-cases (the one we've written covers "Concepts and Use-cases", which
> allows us to make it an introductory doc)
>

Bob,

I believe the use-cases document should be the one landing place for anyone
who cares to know the high order bits of ConEx. Therefore, it should have
the best possible introduction to ConEx --- my feeling is that pieces of
such an Intro. are currently strewn in several disparate
documents/papers/slides.

I am glad you brought up this question; please give it a thought on what
that best stand-alone introduction would look like.

-Nandita

---

From: Nandita Dukkipati <[email-masked]>
Date: Sun, 25 Jul 2010 23:03:09 +0000

John,

>    I'm nervous about starting into a new document without guidance

Although we will submit the documents sequentially as per the milestones
(use-case description followed by abstract specification and so on), we
should work
simultaneously on charter items even if their milestones are further along
in the process.

-Nandita

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 26 Jul 2010 10:53:25 +0100

That makes the most sense to me. After all this is the first milestone and
so (in theory) should exist as a stand-alone document. 

It does raise an important question for the list:

How can we best describe ConEx? Of the many intros that are out there, which
seems easiest to understand and which most confusing? Is the current draft
going down the right lines?

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nandita Dukkipati
Sent: 25 July 2010 23:51
To: Bob Briscoe
Cc: [email-masked]
Subject: Re: [conex] Intent of charter: division of concepts across docs

On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe <[email-masked]>
wrote:

Nandita,

[Adding the list]

Bob,

-Nandita

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 26 Jul 2010 12:07:48 +0100

I was asked to furnish a list of suitable links for introductions to ConEx
or to Bob's re-ECN protocol (which achieves similar aims to ConEx):

General introduction for non-specialist audience:

Bob Briscoe, “Internet Fairer is Faster", White Paper (Jun 2009)
<http://bobbriscoe.net/projects/refb/#fairfastWP>   

Current ConEx use cases document:

Toby Moncaster et al, "ConEx Concepts and Uses" (Jul 2010) 
<http://moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.html> 

ConEx Problem statement:

Toby Moncaster et al "The Need for Congestion Exposure in the Internet "
<http://tools.ietf.org/html/draft-moncaster-conex-problem-00> 

Re-ECN drafts (expired)  

Bob Briscoe et al, "Re-ECN: The Motivation for Adding Accountability for
Causing Congestion to TCP/IP"
<http://www.bobbriscoe.net/projects/refb/draft-briscoe-tsvwg-re-ecn-tcp-moti
vation-01.html> 

Bob Briscoe et al, "Re-ECN: Adding Accountability for Causing Congestion to
TCP/IP"
<http://www.bobbriscoe.net/projects/refb/draft-briscoe-tsvwg-re-ecn-tcp-08.h
tml>  

More technical paper about how to control congestion, but includes some
stuff about exposing it as well:

Arnaud Jacquet et al: "Policing freedom to use the internet resource pool"
<http://www.bobbriscoe.net/projects/refb/polfree_rearch08.pdf> 

There are also presentations like Bob's presentation to ConEx BoF in
Hiroshima:

<http://www.ietf.org/proceedings/76/slides/conex-7.pdf> 

And I am sure Bob can find some more links for people!

Toby

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Toby Moncaster
Sent: 26 July 2010 10:53
To: 'Nandita Dukkipati'; 'Bob Briscoe'
Cc: [email-masked]
Subject: Re: [conex] Intent of charter: division of concepts across docs

Toby

[Adding the list]

Bob,

-Nandita

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 27 Jul 2010 01:04:21 +0100

Toby,

Thanks. That's a good primary reading list.
I maintain a page with papers about ConEx/re-feedback/re-ECN/fairness 
etc. It has a section called "primary documentation", giving 
summaries of what audience they are aimed at, and what they cover. I 
haven't included the recent ConEx docs that Toby lists, but will do 
straight after the IETF. It also includes more focused ones on DDoS 
mitigation and commercial interconnection models.

It is a bit biased towards my own papers, but also includes related 
work, evaluations by others, links to implementations, weighted 
congestion controls, standards activity, articles in the media, etc.

HTH

Bob

At 12:07 26/07/2010, Toby Moncaster wrote:
>Bob Briscoe, "Internet Fairer is Faster", White Paper (Jun 2009)

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 27 Jul 2010 03:32:13 -0400

I chose this message to respond to since I agree with many of John's
points. I also include some responses in line intended to help advance
the work, summarized as follows:

* Use cases need not have the same terminology as the final experimental
specification, however, terminology in the abstract mechanism should
align with the IPv6 specification.
* As John indicated in a separate post, the use case document will
become historical, and may not be as relevant in the future as the
abstract mechanism and experimental specification.
* IMO, the use cases should use terminology that is relevant to the use
case. Hopefully, a mapping at the end of the use case document could map
the range of terminology unique to particular use cases to that of the
abstract mechanism.

Thanks,

Dave 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of John Leslie
> Sent: Friday, July 23, 2010 7:55 PM
> To: Bob Briscoe
> Cc: [email-masked]

As summarized above, the introduction should use terminology and
examples specific to a use case that is familiar to current readers. As
John pointed out earlier, additional use cases (and terminology) will
likely evolve if conex is sucessful (as we hope it becomes). 

>    The Mechanism document will get specific about a number of 
> things we've intentionally left vague so far, but IMHO it 
> shouldn't go into detail about _why_ you might use the mechanisms.

I think the use case needs to provide at least high-level motivation for
development of at least some of the mechanisms. I agree that it should
not provide detail. Hopefully, the document has several use cases
justifying aspects of the abstract mechanism(s).

>    A perhaps surprisingly important issue...

I agree. Mapping from use case specific terminology to a common abstract
model could occur at the end of the use case document. After
experimentation, there could be an updated use case document, that
hopefully, adds some new use cases and refines the description of the
ones initially described.

>    So far, Use-Cases has defined terminology "for its own 
> use," and this has made Bob uneasy. He's quite determined 
> that the "real"
> definitions should provably deliver what they promise, and 
> fears that the Use-Cases definitions will imply promises to 
> deliver something we can't deliver.
> 
>    I, at least, and the rest of the authors to some extent, 
> believe that definitions can evolve as the WG progresses. For 
> one obvious example, I have pretty strong opinions an what 
> "congestion" should mean in its "real" definition; but I am 
> not concerned as we run through much-less-rigorous 
> mini-definitions in early documents.
> 
>    I would not tend to support holding up the Use-Cases 
> document for nailing down details of definitions of terms in 
> some later document.
> 

I agree. See my more specific proposals above and the summary.

>    We could use some WG guidance here. The _question_ of 
> deployability must be tackled in the Use-Cases document, but 
> it seems to me to be inappropriate to lay out many details of 
> deployment (not least since actual deployment won't follow 
> our plan anyway).
> 

I agree.

> >>    deployability once we've defined the detailed protocol)

Agreed.

>    I'd go for "quite a bit" of vagueness...

I would suggest phrasing this as "terminology familiar and relevant to
the particular use case" instead of vagueness.

> >   deployment have to be defined

In the specification? (Third deliverable)

>    I agree with Bob that review of how deployment is coming 
> along is essential; and I despair of predicting what this will show.
> 
>    I _have_ considered deployment incentives at length, but 
> I'm disinclined to put much of my musings into the Use-Cases document.
> A deployment plan is an essential piece of the 
> Experiment-track documents we will write; and it should be 
> specific enough to report to what extent the experiment 
> succeeds in deployment.

I agree

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

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 29 Jul 2010 13:49:51 -0400

As requested by Marcelo in the wg meeting, below is a more detailed
review of draft-moncaster-conex-concepts-uses-01.txt as to what sections
are a use case versus an mechanism.

Thanks,

Dave

   1.  Introduction 

"   (Wireless ISPs and cellular internet have different tradeoffs which
   we will not discuss here.) "

IMO, This is an important set of use cases which need to be included.

"   The ConEx working group proposes that Internet Protocol (IP) packets
   have two "congestion" fields.  The exact protocol details of these
   fields are for another document, but we expect them to provide
   measures of "congestion so far" and "congestion still expected". "

Above is mechanism.

2.  Definitions

IMO, using ECN (a specific mechanism) as the basis of use case
definitions is a duplication of the wg charter deliverable of an
abstract mechanism. This thread runs through the document and should be
replaced with terminology aligned with the draft abstract mechanism. A
single network which is ECN enabled is a specific use case.

3.  Existing Approaches to Congestion Management 

IMO, the text here is quite relevant to use cases. A use case should
define a problem which is not currently solved, and in terminology and a
context specific to the use case describe at a high level what form of
congestion, if exposed in a particular way, would enable an improvement
over the current situation.

4.  Exposing Congestion

This section is primarily mechanism.

     4.1.  ECN - a Step in the Right Direction  
ECN is a specific use case and should be described. Issues with it
(e.g., limited deployment in operator network equipment) should be
mentioned.

   5.  Requirements for ConEx 
Attibutes like timeliness, accuracy and visibility (there may be more)
could be a good set of terminology in which to describe various use
cases, as well as decide on an appropriate abstract mechanism.

     5.1.  ConEx Issues 
The descriptions of interaction with non-conex traffic and over/under
declaration of conex traffic should be rewritten as attributes which may
apply to some (possibly not all) use cases.

The bulleted list introduced by the text: "There are three approaches
that may work ..." is mechanism (approach is synomomous with mechanism).

   6.  A Possible Congestion Exposure Mechanism 
The title (as well as the text) declares this as "Mechanism" and not use
case. The references could be cited in the ECN enabled network use case.

   7.  ConEx Architectural Elements 

The second paragraph begins:   "In the following we are assuming the
most abstract version of the ConEx mechanism ..."

The next six pages are candidates for the abstract mechanism document

     7.1.  ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 13
       7.1.1.  Edge Monitoring  . . . . . . . . . . . . . . . . . . . 13
       7.1.2.  Border Monitoring  . . . . . . . . . . . . . . . . . . 15
     7.2.  ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 15
       7.2.1.  Egress Policing  . . . . . . . . . . . . . . . . . . . 16
       7.2.2.  Ingress Policing . . . . . . . . . . . . . . . . . . . 17
       7.2.3.  Border Policing  . . . . . . . . . . . . . . . . . . . 18

Based upon the questions I asked in the wg, the scheduler associated
with the queue (i.e., work conserving or non-work conserving) should be
added to the abstract mechanism draft.

   8.  ConEx Use Cases  . . . . . . . . . . . . . . . . . . . . . . . 19

Page 19 is where the document first states that use cases are described.
A use case document needs to get to this much sooner!

Each of these subsections has a similar structural issue -- it begins
with some good motivational text and terminology relevant to the use
case, but then goes on the summarize how the previously described
mechanism can address the described problem. I suggest that the latter
part of the text could be rewritten to describe high-level requirements
on what could be done by conex to improve the situation and why this
would be expected to improve matters. If there is general agreement on
this approach, I would be happy to work on text with the draft authors.

Furthermore, as we collect use cases (several more were mentioned during
the meeting), we may be able to categorize them as having similar
characteristics or parameters. Using this categorization, the
terminology of the abstract mechanism draft may be used to describe how
the class of similar use cases would be supported.

     8.1.  ConEx as a basis for traffic management  

     8.2.  ConEx to incentivise scavenger transports  

     8.3.  ConEx to mitigate DDoS 

     8.4.  Accounting for Congestion Volume 

     8.5.  ConEx as a form of differential QoS  

     8.6.  Partial vs. Full Deployment  

   9.  Other issues 
     9.1.  Congestion as a Commercial Secret  

I'm not sure how to categorize this section. It seems that external
measurements of performance (e.g., by end users as mentioned in the last
paragraph) is a contradiction to the assertion in the first paragraph
that some network operators want to keep congestion secret. Suggest
rewording into a use case, otherwise deletion.

     9.2.  Information Security 

Suggest that these be made criteria and/or make them part of use case
classes or make them general security consideration.

10. Security Considerations

Reword and combine with thoughts from 9.2 and edit out mention of
mechanism.