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

[<[e-mail]>]

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

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

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


2. Specification of IP (v4 & v6) packet structure to carry CONEX
information (header bits, interpretation)


3. Transport-related Best practices and specifications:

A. for the transport of congestion information from the destination to
the sender,

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.


4. Use cases -- possible uses of CONEX information to reduce congestion
and/or increase the accountability for it. 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.

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