Subject: [re-ECN] DRAFT charter

From: Leslie Daigle <[email-masked]>
Date: Thu, 05 Nov 2009 00:57:36 -0500

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
[email-masked]
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 5 Nov 2009 10:00:31 -0000

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leslie Daigle
> Sent: 05 November 2009 05:58
> To: [email-masked]
> Subject: [re-ECN] DRAFT charter
> 
> Hi,
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Nov 2009 11:09:08 +0100

> o Analysis of security threats from falsifying or suppressing CONEX
isnt this one missing from the deliverables below? or are you expecting 
this to be covered in another document?
regards, marcelo

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

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 09 Nov 2009 19:45:41 +0900

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

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

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

Aug 2010 Draft security threats document (-00)

Jan 2011 Revised security threats document

--

---

From: ken carlberg <[email-masked]>
Date: Mon, 9 Nov 2009 09:03:28 -0500

> congestion information from receiver to sender

I'd like to echo Ingemar's earlier comment on not constraining the  
effort to just TCP but to focus on the more general solution space of  
a transport protocol.

-ken

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 10 Nov 2009 08:03:14 +0900

Hi,

I have that as a point for discussion in the BoF today.

Thanks,
Leslie.

ken carlberg wrote:
> effort to just TCP but to focus on the more general solution space of a 
> transport protocol.
> 
> -ken
> 

--