Re: [re-ECN] DRAFT charter

Hi Leslie,

Generally that looks like a pretty good charter. Just a couple of
issues:

We should make it clearer that the suggested use cases are just that -
suggestions.

I'm not quite sure about having an applicability statement, and if we do
I don't think we can have it as the first milestone unless you actually
mean it to be mainly a "constraints" document.

There is definite pressure from some people to cover transports other
than TCP. One suggestion might be to specify a minimal behaviour needed
in order to make this work in any transport (e.g. nature, granularity
and timeliness of feedback information and how to convert this into
feed-forward CONEX info).

Final thing, should we consider having a "vision" document for how this
might impact things architecturally in the long term?

Toby

> -----Original Message-----
> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> Behalf Of Leslie Daigle
> Sent: 05 November 2009 05:58
> To: re-ecn@ietf.org
> Subject: [re-ECN] DRAFT charter
> 
> 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
> leslie@thinkingcat.com
> -------------------------------------------------------------------
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn