Re: [re-ECN] DRAFT charter

[Leslie Daigle <[e-mail]>]

Hi,

Updated from comments on the list (thanks!).  This is the version we 
will have for discussion tomorrow during the BoF, along with some of the 
(as yet) unaddressed suggestions, for discussion there.

Thanks,
Leslie.

CONEX Charter

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.


Output of  the CONEX WG will include:

o An applicability statement -- the specific cases in which CONEX is 
useful, especially in different network conditions, incremental 
deployment considerations, etc.

o Specification of IP (v4 and v6) packet structure to encapsulate 
congestion exposure information (header bits, interpretation)

o Use cases -- possible uses of the CONEX information to reduce 
congestion and/or increase accountability for it -- for illustration 
purposes only

o Specification of necessary CONEX features in TCP, for example to carry
congestion information from receiver to sender

o Analysis of security threats from falsifying or suppressing CONEX
information

Future work may include specifications to implement one or more use 
cases, but that is out of scope initially.



Milestones [Hopelessly ambitious for now -- to be hammered out when the 
output is settled]


Feb 2010 Draft applicability statement (-00)

Mar 2010 Evaluation of candidate protocol approaches

Apr 2010 Determination of protocol approach

May 2010 Draft use cases (-00)

Jun 2010 Revised applicability statement

Jun 2010 Draft CONEX IPv4 specification  (-00)

Jun 2010 Draft CONEX IPv6 specification (-00)

Aug 2010 Draft security threats document (-00)

Dec 2010 Revised CONEX IPv4 specification

Dec 2010 Revised CONEX IPv6 specification

Jan 2011 Revised security threats document

Jan 2011 Revised use cases




Leslie Daigle wrote:
> Hi,
> 
> Here's a draft charter for a potential WG in this area.  Note that we 
> have to be pretty successful in working our way through the BoF agenda 
> to even get to a point where it is sensible to discuss a charter, but it 
> seemed reasonable to have a draft in hand.
> 
> 
> 
> 
> 
> CONEX Charter
> 
> 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.
> 
> 
> Output of  the CONEX WG will include:
> 
> o An applicability statement -- the specific cases in which CONEX is 
> useful, especially in different network conditions, incremental 
> deployment considerations, etc.
> 
> o Specification of IP (v4 and v6) packet structure to encapsulate 
> congestion exposure information (header bits, interpretation)
> 
> o Use cases -- possible uses of the CONEX information to reduce 
> congestion and/or increase accountability for it
> 
> o Specification of necessary CONEX features in TCP, for example to carry
> congestion information from receiver to sender
> 
> o Analysis of security threats from falsifying or suppressing CONEX
> information
> 
> Future work may include specifications to implement one or more use cases.
> 
> 
> 
> Milestones [Hopelessly ambitious for now -- to be hammered out when the 
> output is settled]
> 
> 
> Feb 2010 Draft applicability statement (-00)
> 
> Mar 2010 Evaluation of candidate protocol approaches
> 
> Apr 2010 Determination of protocol approach
> 
> May 2010 Draft use cases (-00)
> 
> Jun 2010 Revised applicability statement
> 
> Jun 2010 Draft CONEX IPv4 specification  (-00)
> 
> Jun 2010 Draft CONEX IPv6 specification (-00)
> 
> Dec 2010 Revised CONEX IPv4 specification
> 
> Dec 2010 Revised CONEX IPv6 specification
> 
> Jan 2011 Revised use cases
> 
> 
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------