From: The IESG <firstname.lastname@example.org>
To: IETF-Announce <email@example.com>
Cc: RFC Editor <firstname.lastname@example.org>,
conex mailing list <email@example.com>,
conex chair <firstname.lastname@example.org>
Subject: Document Action: 'ConEx Concepts and Use Cases' to Informational RFC (draft-ietf-conex-concepts-uses-05.txt)
The IESG has approved the following document:
- 'ConEx Concepts and Use Cases'
(draft-ietf-conex-concepts-uses-05.txt) as Informational RFC
This document is the product of the Congestion Exposure Working Group.
The IESG contact persons are Wesley Eddy and Martin Stiemerling.
A URL of this Internet Draft is:
The ConEx Concepts and Use Cases document provides the entry point to the set of
documentation about the Congestion Exposure (ConEx) protocol. The document
explains the motivation for including a ConEx marking at the IP layer, which is
to expose the path congestion information to the network nodes. It particularly
focuses on how the ConEx marking can serve as the basis for more efficient and
effective traffic management than what exists on the Internet today.
Working Group Summary
The document is a result of a many hours/emails of discussion spanned over 20
months. Two points that stand out in the WG process are:
1. In the beginning, the document was a mix of a several closely related use
cases for ConEx. After much discussion, the document zeroed in on the central
use case of ConEx which is informing traffic management, while also providing a
discussion of other benefits of ConEx in a separate section. Even though this
process took some time, it ultimately helped shape the clarity and focus of the
2. The working group also had an intense discussion on whether the role of
statistical multiplexing over longer timescales should be a separate use case.
It was ultimately folded in with one of the existing use cases.
The ConEx Concepts and Use Cases document serves as an introduction and
motivation for the upcoming documents that describe more precisely the ConEx
mechanisms, IPv6 packet formats and TCP modifications. As such, this is
not a specification itself, and no implementations will be created from it, however
it will be helpful in explaining how CONEX works to implementers and in guiding
Nandita Dukkipati is the document shepherd. Wesley Eddy is the Responsible Area