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

[<[e-mail]>]

Some suggestions/correction inline...

> -----Original Message-----
> From: Moncaster,T,Toby,DEE1 R
> Sent: 09 December 2009 09:37
> To: Moncaster,T,Toby,DEE1 R
> Subject: Complete draft Charter for proposed CONEX WG
> 
> 
> 
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: 08 December 2009 15:29
> To: [e-mail]
> Subject: [re-ECN] Complete draft Charter for proposed CONEX WG
> 
> Hi,
> We've now added a draft list of Milestones to the problem statement
and
> Output already discussed.
> Please send comments as soon as possible - hoping to get into IESG
next
> week.
> Thanks
> Phil & Leslie
> ---
> 
> The purpose of the CONEX working group is to develop a mechanism to

The CONEX working group will develop mechanisms to

> 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. 

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...

> 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"

> 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) 

> 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...

> 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...


> 
> 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."

> 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).

> 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...

Toby