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

[<[e-mail]>]

Thanks toby & john
> > ---
> > 
> > The purpose of the CONEX working group is to develop a mechanism to
> 
> The CONEX working group will develop mechanisms to

"mechanisms" might imply that we going to develop several different ways
of doing this.
So I prefer keeping as "a mechanism" (albeit one with several parts -
which I think was your point)

> 
> > allow senders to inform the network of the level of congestion they 
> > expect their packets to encounter. This information is 
> currently only 
> > visible at the transport layer.
> 

I think everyone so far is ok with mirja's suggestion to add "in the end
systems", please shout if I mis-interpreted.

> Although I agree with Mirja's comment, an argument that could 
> be made to say the information is visible in the network if 
> you use DPI equipment... However I think highlighting that 
> only the end-systems are DESIGNED to see the info is a good thing...
> 
> > With the output of CONEX, it will be
> > possible to provide sufficient information in each IP 
> datagram so that 
> > any node in the network can see the expected rest-of-path 
> congestion.
> 
> I think I would prefer to say "The main output of CONEX will 
> be a protocol that allows each IP datagram to carry 
> sufficient information to allow any node in the network to 
> see the whole path congestion." I make the subtle distinction 
> between rest of path and whole path so that we leave the door 
> open for Matt Mathis's mark on drop suggestion...

Please can you remind me what Matt's suggestion is. 
At the moment, prefer to leave as "rest-of-path congestion" (knowing one
implies knowing the other, and rest-of-path emphasises the new info
useful for a router, as john says)

> 
> > Once any node can see the impact it causes (and suffers) by 
> sending or 
> > forwarding packets, it will be possible to hold senders and whole 
> > networks accountable for the congestion they cause 
> downstream. Tools 
> > that exploit the CONEX output could be used for mitigating 
> distributed 
> > denial of service (DDoS); simplifying differentiation of quality of 
> > service (QoS); policing compliance to congestion control; 
> and so on. 
> > Intended output of the WG: 1. An applicability statement 
> that consists 
> > of
> 
> Don't like "consists of" would prefer something like 
> "explains" or "describes"

Ok

> 
> > 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. 
> > deployment analysis - how the CONEX mechanism can be deployed in 
> > networks (non vs ECN vs perhaps CONEX routers) and end systems
> 
> Including analysis of the impact of full vs partial 
> deployment (or something like this - highlight that what 
> matters is how we get to a system that is useful)

This raises an interesting question. There are several deployment
issues:
* the functionality of the routers (non, ECN, maybe CONEX, maybe a mix)
* the functionality of the end systems (is the destination non, ECN,
CONEX?)
* the functionality of the network (specifically, this about the
enforcement of trustworthiness of conex info)

The 3rd one seems to me a big issue, & one that first requires work on
the mechanism in 3B. So I see network-by-network partial deployment as a
use case, potentially to be explored under item 4. 

"Output Item 1" (APPlicability) is intended to be early work "to detail
the key functional and non-functional considerations that guide the work
on the mechanism's design". 
I'm not convinced that network-by-network deployment analysis falls into
this category. 

But maybe just my perception! 
 
> 
> > C. security analysis - threats from falsifying or blanking 
> CONEX info
> 
> Think I would just all that a threat analysis and I think 
> there is a good chance it could exist as a separate document...
> 
> > 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
> > 
> > 2. Specification of IP (v4 & v6) packet structure to carry CONEX 
> > information (header bits, interpretation)
> > 
> > 3. Transport-related Best practices and specifications:
> 
> Add the word "covering" after specifications...

Ok

> 
> > A. for the transport of congestion information from the 
> destination to 
> > the sender,
> 
> For the timely transport ?
> 
> > B. for ensuring the trustworthiness of the CONEX information
> > Note: capability negotiation is out of scope, except to the extent 
> > that a CONEX sender should either be able to work with a legacy 
> > destination or be able to fall-back to non-CONEX operation.
> 
> Somewhere in work items 2 or 3 we need to specifically refer 
> to a need to mitigate those threats identified in the threat 
> analysis...

Ok

> 
> 
> > 
> > 4. Use cases -- possible uses of CONEX information to reduce 
> > congestion and/or increase the accountability for it.
> 
> This first sentence seems to pre-suppose which use cases are 
> of interest... Perhaps change it to "possible uses of CONEX 
> information which include controlling or reducing congestion 
> and increasing accountability for congestion."

Ok. Widening the text allows things like simply monitoring the info, in
order to do some off-line network planning perhaps

> 
> > The main purpose is to
> > encourage experiments that use CONEX information and to 
> describe their 
> > results; it is not to delineate all potential uses cases, nor to 
> > provide a full architectural/deployment/security analysis of use 
> > cases. Future work may include specifications to implement 
> one or more 
> > use cases.
> 
> Highlight that we expect there to be a number of use case 
> documents (or a number of sections within a master use case document).

Think we can leave this to the WG to decide.

> 
> > The output is Informational and Experimental, apart from #2 
> which is 
> > tentatively slated as Standards track.
> > 
> > Milestones
> > Feb 2010 Internet-Draft functionality statement (Output 
> item 1A) Mar 
> > 2010 Internet-Draft applicability statement (Output item 
> 1A, B, C) Mar 
> > 2010 Internet-Draft(s) for CONEX IPv4 & IPv6 specifications (Output 
> > item 2) May 2010 Internet-Draft use cases (Ouput item 4)
> > Jun 2010 First WG draft CONEX IPv4 specification
> > Jun 2010 First WG draft CONEX IPv6 specification
> > Jun 2010 Draft transport-related best practices
> > Jun 2010 Proposals (individual I-Ds) for TCP modification 
> (Ouput item
> > 3A)
> > Jun 2010 Proposals (individual I-Ds) for mechanism to ensure
> > trustworthiness of CONEX information (Ouput item 3B)
> > Sep 2010 Complete applicability statement (sent to IESG)
> > Nov 2010 CONEX IPv4 specification to WGLC
> > Nov 2010 CONEX IPv6 specification to WGLC
> > Jan 2011 Complete IPv4 specification (sent to IESG)
> > Jan 2011 Complete IPv6 specification (sent to IESG)
> > Mar 2011 Spec of TCP modification to WGLC
> > Mar 2011 Spec of mechanism to ensure trustworthiness to WGLC
> > Mar 2011 Transport-related best practices to WGLC
> > Mar 2011 Use cases to WGLC
> > May 2011 Complete remaining docs (sent to IESG)
> > Jun 2011 Close or re-charter
> 
> My word that's an exhaustive list of milestones! For 
> simplicity can we also break out the list of intended 
> publication dates for the final outputs? My personal instinct 
> is that we should be able to publish the applicability 
> statement in July or at least WGLC it. Also sometime round 
> November 2010 we need to actually select which individual IDs 
> we are progressing for TCP and trustworthiness...

Thnks, we'll have a think whether there's a better way to list them. 

> 
> Toby
>