Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG

From: <[email-masked]>
Date: Tue, 5 Jan 2010 11:44:02 -0000

> 
> [BB]: A radically new approach is unlikely to be successful if people 
> can't get an intuitive grasp of it. E.g. HIP would have been unlikely 
> to get anywhere without RFC4423. We know ConEx hasn't been easy for 
> newcomers to grasp, so we shouldn't fudge this issue.
> 
> I was thinking of a framework/architecture doc. Here's an idea...
> 
> Let's assume the use-cases item is >1 doc, rather than a single 
> monolithic doc for all use-cases, ie. we encourage different people 
> to document their own use-cases.
> 
> If so, then someone could attempt to write a more generic use-cases 
> doc that describes building blocks that can be used to build the 
> other use-cases. This could become a README-FIRST if written well, as 
> it's difficult to introduce ConEx without describing how it 
> might be used.

An "intuitive guide" would be possible, although adding another doc is
more work. I wonder if the applicability statement can be tweaked for
this purpose. We could add another "purpose":
[3] to provide an intuitive explanation of the new concepts in CONEX

So that it reads as follows:- 

1. An applicability statement that describes: 

A. the functionality / capability that is expected to be provided by the
CONEX mechanism itself, including its architectural features,
limitations and assumptions it makes about networks and end systems

B. a deployment analysis - how the CONEX mechanism can be deployed in
networks (non vs ECN vs perhaps CONEX routers) and end systems

C. a threat analysis - threats from falsifying or blanking CONEX info 

The purpose is 
[1] to detail the key functional and non-functional considerations that
guide the work on the mechanism's design 

[2] to allow exploration of use cases to begin before work on the
mechanism is complete 

[3] to provide an intuitive explanation of the new concepts in CONEX

> Where do you imagine we should put best practice for the sending 
> transport to set its expectation of congestion?
> - The above EXP for e2e transport,
> - or within the ConEx-IP doc (if so, which one? v4 or v6)?
> It would seem to fit better in the e2e transport one, then the spec 
> for TCP could provide an example of the complete best practice.

Yes, same as you - I'd imagined it would be in the e2e transport doc.
The IP doc defines packet the structure to carry CONEX information  - ie
what the codepoints are and what they mean. "what they mean" of course
influences what the sending transport should do, but the advice for the
sending transport would be in the transport doc [things like "send, as
soon as possible, a Black codepoint for every loss or mark notified by
the receiver". or whatever!] 

Thanks
phil

> IOW, this proposal assumes the IP doc would not need to describe 
> semantics of *when* the transport sets the codepoints. Instead it 
> would focus on just the wire protocol - what the codepoints mean, how 
> they are encoded, tunnel processing, router forwarding behaviour, 
> errors & management etc.
> 
> Altho I'm not implying re-ECN is any more than a candidate, it would 
> be a useful exercise to go through the contents of the re-ECN 
> protocol spec <draft-briscoe-tsvwg-re-ecn-tcp-08> and check where you 
> assume the different sections will end up. I've just done that, which 
> is why I keep bringing up awkward questions.
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 05 Jan 2010 13:48:38 +0000

Phil,

I'm happy with both responses.

one outstanding issue inline...

>C. a threat analysis - threats from falsifying or blanking CONEX info

The milestones have the applicability statement going to the IESG 
before the ConEx protocol is specified, so...

B. I'm not convinced we will be able to write a deployment analysis 
of a protocol as yet to be defined - we can surely only write 
requirements at that stage.
C. And it's certainly not possible to write a meaningful threat 
analysis of something that hasn't yet been specified.

These problems would be solved by altering the chartering text as follows:
s/deployment analysis/
  /deployability goals/
s/threat analysis - threats from.../
  /security goals - addressing threats from.../

Then after the protocol has been specified:
- deployment analysis could be in "4. use-case(s)"
- full threat analysis could be in "3B trust mechanisms"

Bob

> > is why I keep bringing up awkward questions.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design