[re-ECN] Fwd: WG Action: Congestion Exposure (conex)

Lars Eggert <lars.eggert@nokia.com> Fri, 04 June 2010 07:31 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 98F613A68D8; Fri, 4 Jun 2010 00:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 63TlXydy70D6; Fri, 4 Jun 2010 00:31:10 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com []) by core3.amsl.com (Postfix) with ESMTP id 92BF23A698C; Fri, 4 Jun 2010 00:31:09 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com []) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o547UeiS027791; Fri, 4 Jun 2010 10:30:53 +0300
Received: from vaebh104.NOE.Nokia.com ([]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 10:30:51 +0300
Received: from mgw-sa01.ext.nokia.com ([]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 10:30:22 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com []) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o547UMqU029642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jun 2010 10:30:22 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/signed; boundary="Apple-Mail-59-976666882"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
Date: Fri, 04 Jun 2010 10:30:10 +0300
Message-Id: <0CE22F0A-C26B-4F4E-B778-5062AF76ACB5@nokia.com>
References: <20100603204841.011D53A68D6@core3.amsl.com>
To: "re-ecn@ietf.org list" <re-ecn@ietf.org>
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Fri, 04 Jun 2010 10:30:15 +0300 (EEST)
X-OriginalArrivalTime: 04 Jun 2010 07:30:22.0803 (UTC) FILETIME=[CAE40230:01CB03B7]
X-Nokia-AV: Clean
Cc: conex@ietf.org
Subject: [re-ECN] Fwd: WG Action: Congestion Exposure (conex)
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: conex@ietf.org
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: Fri, 04 Jun 2010 07:31:11 -0000


you have probably seen that the CONEX WG has been chartered. The WG mailing list is conex@ietf.org. I have requested that the secretariat subscribe everyone who is currently on the re-ecn@ietf.org list to the new CONEX WG list.

I leave it up to Bob to decide if he wants to keep the re-ecn@ietf.org list around; but any CONEX-related discussion should move to conex@ietf.org.


Begin forwarded message:

> From: IESG Secretary <iesg-secretary@ietf.org>
> Date: June 3, 2010 23:48:40 GMT+03:00
> To: IETF Announcement list <ietf-announce@ietf.org>
> Cc: "marcelo@it.uc3m.es" <marcelo@it.uc3m.es>, "nanditad@google.com" <nanditad@google.com>, "conex@ietf.org" <conex@ietf.org>
> Subject: WG Action: Congestion Exposure (conex) 
> A new IETF working group has been formed in the Transport Area.  For
> additional information, please contact the Area Directors or the WG
> Chairs.
> Congestion Exposure (conex) 
> ---------------------------------------------------
> Current Status: Active Working Group
> Chairs:
>  Nandita Dukkipati <nanditad@google.com>
>  Marcelo Bagnulo <marcelo@it.uc3m.es>
> Transport Area Director(s):
>  Lars Eggert <lars.eggert@nokia.com>
>  David Harrington <ietfdbh@comcast.net>
> Transport Area Advisor:
>  Lars Eggert <lars.eggert@nokia.com> 
> Mailing Lists:
>  General Discussion: conex@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/conex
>  Archive: http://www.ietf.org/mail-archive/web/conex/
> Description of Working Group:
> The purpose of the CONEX working group is to develop a mechanism
> by which senders inform the network about the congestion encountered
> by previous packets on the same flow. Today, the network may signal
> congestion by ECN markings or by dropping packets, and the receiver
> passes this information back to the sender in transport-layer
> acknowledgements. The mechanism to be developed by the CONEX WG
> will enable the sender to also relay the congestion information
> back into the network in-band at the IP layer, such that the total
> level of congestion is visible to all IP devices along the path,
> from where it could, for example, be provided as input to traffic
> management.
> The primary goal of the CONEX WG is to develop experimental
> specifications to achieve the above in IPv6 networks. The WG will
> also develop an abstract, higher-level description of the congestion
> exposure mechanism.
> Primary work items are:
> * An Informational document containing an abstract description of
> the congestion exposure mechanism that is independent of specific
> transport protocols and congestion information encoding techniques
> needed for different IP protocol versions.
> * An Experimental specification of an IPv6 packet structure that
> encapsulates CONEX information, defining a packet format and an
> interpretation.
> * An Experimental specification of a modification to TCP, for the
> timely transport of congestion information from the destination to
> the sender.
> It is believed that the CONEX mechanism will be useful as a generative
> technology that can be applied as a key element of congestion
> management solutions in a wide variety of use cases. However, the
> CONEX WG will initially focus on one use case, where the end hosts
> and the network that contains the destination end host are CONEX-enabled
> but other networks need not be. CONEX information can assist the
> network operator's traffic management and, for example, incentivize
> LEDBAT-like applications. Congestion-based billing is not within the
> scope of the WG.
> Experiments on use cases are encouraged and the WG will solicit
> feedback from such deployments. The WG may decide to document the
> experience from such use cases in Informational documents, covering:
> * Assumptions made
> * Deployment considerations
> * Advice on how to use the CONEX mechanism as an element of a
> congestion management solution
> * Security threats and advice on mitigation approaches (detailed
> specifications of threat mitigation techniques are out of scope)
> * Descriptions of results from experiments with the use case
> The CONEX WG is only chartered to work on a congestion exposure mechanism
> for IPv6 networks. When the output of the WG has seen adoption and
> has proven to be useful, the WG may propose to the IESG that it
> should be rechartered to extend this effort. The first result of
> the WG is the usage scenarios document. Other documents will not
> be considered for publication before this first document has seen
> IETF consensus (but may be worked on in the WG).
> Goals and Milestones:
> Mar 2011 Submit use case description to IESG as Informational
> Jul 2011 Submit abstract specification for the congestion exposure
> mechanism to IESG as Informational
> Nov 2011 Submit specification of IPv6 packet structure to IESG as
> Experimental
> Nov 2011 Submit specification for modification to TCP to IESG as
> Experimental
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce