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

<philip.eardley@bt.com> Mon, 14 December 2009 11:14 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEF23A6983 for <re-ecn@core3.amsl.com>; Mon, 14 Dec 2009 03:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level:
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JBuiYB6EHnR for <re-ecn@core3.amsl.com>; Mon, 14 Dec 2009 03:14:53 -0800 (PST)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id DEB343A63EB for <re-ecn@ietf.org>; Mon, 14 Dec 2009 03:14:51 -0800 (PST)
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Dec 2009 11:14:24 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7CAE.97FAE246"
Date: Mon, 14 Dec 2009 11:14:24 -0000
Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363BA7@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363B66@E03MVB1-UKBR.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Complete draft Charter for proposed CONEX WG
Thread-Index: Acp4Gx0EP2kuvs7QSlqymk5yJ6ln6wEk2aog
From: <philip.eardley@bt.com>
To: <re-ecn@ietf.org>
X-OriginalArrivalTime: 14 Dec 2009 11:14:24.0694 (UTC) FILETIME=[97D4CD60:01CA7CAE]
Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2009 11:15:00 -0000

it would be great if we could get this to Lars in the next couple of
days. Please send any more comments asap
thanks!
phil

	-----Original Message-----
	From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org]
On Behalf Of philip.eardley@bt.com
	Sent: 08 December 2009 15:29
	To: re-ecn@ietf.org
	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 
	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