conex-lars.txt   conex-iesg.txt 
Congestion Exposure (CONEX) WG Congestion Exposure (CONEX) WG
The purpose of the CONEX working group is to develop a mechanism The purpose of the CONEX working group is to develop a mechanism
by which senders inform the network about the congestion their by which senders inform the network about the congestion encountered
packets encounter. Today, the network may signal congestion by ECN by previous packets on the same flow. Today, the network may signal
markings or by dropping packets, and the receiver passes this congestion by ECN markings or by dropping packets, and the receiver
information back to the sender in transport-layer acknowledgements, passes this information back to the sender in transport-layer
where the sender makes an adjustment to its window size or data acknowledgements, The mechanism to be developed by the CONEX WG
rate, as appropriate. The mechanism to be developed by the CONEX will enable the sender to also relay the congestion information
WG will enable the sender to also relay the congestion information
back into the IP layer, such that the total level of congestion is back into the IP layer, such that the total level of congestion is
visible to all IP devices along the path. visible to all IP devices along the path.
The primary goal of the CONEX WG is to develop experimental The primary goal of the CONEX WG is to develop experimental
specifications to achieve the above. The WG will also develop an specifications to achieve the above in IPv6 networks. The WG will
abstract, higher-level description of the congestion exposure also develop an abstract, higher-level description of the congestion
mechanism. exposure mechanism.
Primary work items are: Primary work items are:
* An Informational document containing an abstract description of * An Informational document containing an abstract description of
the congestion exposure mechanism that is independent of specific the congestion exposure mechanism that is independent of specific
transport protocols and congestion information encoding techniques transport protocols and congestion information encoding techniques
needed for different IP protocol versions. needed for different IP protocol versions.
* An Experimental specification of an IPv6 packet structure that * An Experimental specification of an IPv6 packet structure that
encapsulates CONEX information, defining a packet format and an encapsulates CONEX information, defining a packet format and an
interpretation. interpretation.
* An Experimental specification of a modification to TCP, for the * An Experimental specification of a modification to TCP, for the
timely transport of congestion information from the destination to timely transport of congestion information from the destination to
the sender. the sender.
It is believed that the CONEX mechanism will be useful as a generative It is believed that the CONEX mechanism will be useful as a generative
technology that can be applied as a key element of congestion technology that can be applied as a key element of congestion
management solutions in a wide variety of use cases. However, the management solutions in a wide variety of use cases. However, the
CONEX WG will initially focus solely on one use case, where the end CONEX WG will initially focus on one use case, where the end
hosts and the network that contains the destination end host are hosts and the network that contains the destination end host are
CONEX-enabled but other networks are not. CONEX information can CONEX-enabled but other networks need not be. CONEX information can
assist the network operator's traffic management and, for example, assist the network operator's traffic management and, for example,
incentivize LEDBAT-like applications. Experiments on such use cases incentivize LEDBAT-like applications. Experiments on such use cases
are encouraged and the WG will solicit feedback from such deployments. are encouraged and the WG will solicit feedback from such deployments.
The WG may decide to document the experience from such use cases The WG may decide to document the experience from such use cases
in Informational documents, covering: in Informational documents, covering:
* Assumptions made * Assumptions made
* Deployment considerations * Deployment considerations
* Advice on how to use the CONEX mechanism as an element of a * Advice on how to use the CONEX mechanism as an element of a
congestion management solution congestion management solution
* Security threats and advice on mitigation approaches (detailed * Security threats and advice on mitigation approaches (detailed
specifications of threat mitigation techniques are out of scope) specifications of threat mitigation techniques are out of scope)
* Descriptions of results from experiments with the use case * Descriptions of results from experiments with the use case
During the chartering discussion of the CONEX WG, much interest was The CONEX WG is initially chartered to work a congestion exposure
expressed in pursuing a CONEX specification for IPv4. Due to the mechanism for IPv6 networks. When the output of the WG has seen
complications of experimenting with 'bit 48', i.e., the last adoption and has proven to be useful, the WG may propose to the
unassigned bit in the IPv4 header, this was decided to be out of IESG that it should be rechartered to widen its scope to include
scope for the initial charter. If the IETF comes to consensus on IPv4.
how 'bit 48' can be used for experiments, the CONEX WG may consider
rechartering to work on an IPv4 packet structure to encapsulate
CONEX information.
Milestones Milestones
Mar 2011 Submit abstract specification for the congestion Mar 2011 Submit abstract specification for the congestion
exposure mechanism to IESG as Informational exposure mechanism to IESG as Informational
Mar 2011 Submit use case description to IESG as Informational Mar 2011 Submit use case description to IESG as Informational
Sep 2011 Submit specification of IPv6 packet structure to IESG as Sep 2011 Submit specification of IPv6 packet structure to IESG as
Experimental Experimental
 End of changes. 5 change blocks. 
20 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/