Hi,

For the (public) record, here's the most recent version of the charter. 
  Phil sent it along to Lars for his consideration, yesterday.  I think 
we'll wait to hear feedback from him before doing more serious mods on 
the charter -- I think (hope!) we're really close, and can be focusing 
on getting the work items moving.


Congestion Exposure (CONEX) WG

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 in the end systems. 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.

The WG will work on the following topics (see later for the list of 
documents):

1. An applicability statement that describes:

A. the functionality / capability that is expected to be provided by the 
CONEX mechanism itself, including its architectural features, 
limitations and assumptions it makes about networks and end systems

B. deployability goals - how the CONEX mechanism can be deployed in 
networks (non vs ECN vs perhaps CONEX routers) and end systems

C. security goals - addressing threats from falsifying or blanking CONEX 
info

The purpose is
[1] to detail the key functional and non-functional considerations that 
guide the work on the mechanism's design

[2] to allow exploration of use cases to begin before work on the 
mechanism is complete

[3] to provide an intuitive explanation of the new concepts in CONEX

2. Specification of IP (v4 & v6) packet structure to carry CONEX 
information (header bits, interpretation)

3. Transport-related Best practices and specifications:

A. for the timely transport of congestion information from the 
destination to the sender,

B. for ensuring the trustworthiness of the CONEX information (to 
mitigate the threats identified in 1C)

4. Use cases -- possible uses of CONEX information, which include 
controlling or reducing congestion and increasing accountability for 
congestion. The main purpose is to encourage experiments that use CONEX 
information and to describe their results; it is not to delineate all 
potential uses cases, nor to provide a full 
architectural/deployment/security analysis of use cases. Future work may 
include specifications to implement one or more use cases.

The output is Informational and Experimental, apart from #2 which is 
tentatively slated as Standards track. Depending on the bits that are 
proposed to be used in the IP header and their semantics (eg Bit 48 in 
IPv4, ECN nonce), there may need to be further STD or INFO documents to 
reassign the bits from their current definition(s) (which would be 
subject to appropriate IESG and IETF review as necessary).


Milestones & List of documents to be produced:

== Related to Output Item 1 ==

Feb 2010 Internet-Draft functionality statement (Output item 1A)

Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C)

July 2010 Applicability statement to WGLC

Sep 2010 Applicability statement sent to IESG (INFO)

== Related to Output Item 2 ==

Mar 2010 Proposals (individual I-Ds) for CONEX IPv4 & IPv6 specifications

Jun 2010 First WG draft CONEX IPv4 specification

Jun 2010 First WG draft CONEX IPv6 specification

Nov 2010 CONEX IPv4 specification to WGLC

Nov 2010 CONEX IPv6 specification to WGLC

Jan 2011 IPv4 specification sent to IESG (STD)

Jan 2011 IPv6 specification sent to IESG (STD)

== Related to Output Item 3 ==

Jun 2010 Draft transport-related best practices

Jun 2010 Proposals (individual I-Ds) for TCP modification

Jun 2010 Proposals (individual I-Ds) for mechanism to ensure 
trustworthiness of CONEX information

Mar 2011 Transport-related Best practices for ensuring the 
trustworthiness of the CONEX information, including Spec of one 
mechanism to WGLC (EXP)

Mar 2011 Transport-related Best practices for the transport of 
congestion information from the destination to the sender, including 
Spec of TCP modification to WGLC (EXP)

May 2011 Both transport-related docs sent to IESG

== Related to Output Item 4 ==

May 2010 Internet-Draft use cases

Mar 2011 Use cases to WGLC

May 2011 Use cases sent to IESG (INFO)

==
Jun 2011 Close or re-charter




Leslie.

Ingemar Johansson S wrote:
> WARNING: contains banned part
> 
> 
> ------------------------------------------------------------------------
> 
> 
> Subject: Re: Complete draft Charter for proposed CONEX WG From: 
> "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com> Date: Thu, 7
> Jan 2010 15:32:21 +0100 To: <re-ecn@ietf.org>
> 
> To: <re-ecn@ietf.org>
> 
> 
> 
> Hi
> 
> If I get things correct idea is to create one IP doc and a number of
> transport docs (TCP, RTP/UDP....), this sounds OK.
> 
> My feeling is that the IP doc needs to set some requirements on the
> feedback/reinsertion done by the transport. The reason I see is that
> no requirements at all on this level will make it difficult to design
> and tune the incentive droppers and congestion rate policers.
> 
> The use of bit 48 in the IPv4 header is probably one thing that will
> raise the noise level on the list. The IP doc will here need to
> specify how this can be used safely (if posssible)
> 
> PS. Is it possible that you could post a refreshed version of the
> draft charter on this list as it is a bit difficult to follow the
> discussion (esp after being away after being out of office for a
> longer period).
> 
> Regards Ingemar
> 
> 
> 
> ----------------------------------------------------------------------
> 
> 
> Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe
> <rbriscoe@jungle.bt.co.uk> Subject: Re: [re-ECN] Complete draft
> Charter for proposed CONEX WG To: <philip.eardley@bt.com> Cc:
> re-ecn@ietf.org Message-ID:
> <201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk> Content-Type:
> text/plain; charset="us-ascii"; format=flowed
> 
> Phil,
> 
> I'm happy with both responses.
> 
> one outstanding issue inline...
> 
> At 11:44 05/01/2010, philip.eardley@bt.com wrote:
>>> [BB]: A radically new approach is unlikely to be successful if
>>> people can't get an intuitive grasp of it. E.g. HIP would have
>>> been unlikely to get anywhere without RFC4423. We know ConEx
>>> hasn't been easy for newcomers to grasp, so we shouldn't fudge
>>> this issue.
>>> 
>>> I was thinking of a framework/architecture doc. Here's an idea...
>>> 
>>> 
>>> Let's assume the use-cases item is >1 doc, rather than a single 
>>> monolithic doc for all use-cases, ie. we encourage different
>>> people to document their own use-cases.
>>> 
>>> If so, then someone could attempt to write a more generic
>>> use-cases doc that describes building blocks that can be used to
>>> build the other use-cases. This could become a README-FIRST if
>>> written well, as it's difficult to introduce ConEx without
>>> describing how it might be used.
>> An "intuitive guide" would be possible, although adding another doc
>> is more work. I wonder if the applicability statement can be
>> tweaked for this purpose. We could add another "purpose": [3] to
>> provide an intuitive explanation of the new concepts in CONEX
>> 
>> So that it reads as follows:-
>> 
>> 1. An applicability statement that describes:
>> 
>> A. the functionality / capability that is expected to be provided
>> by the CONEX mechanism itself, including its architectural
>> features, limitations and assumptions it makes about networks and
>> end systems
>> 
>> B. a deployment analysis - how the CONEX mechanism can be deployed
>> in networks (non vs ECN vs perhaps CONEX routers) and end systems
>> 
>> C. a threat analysis - threats from falsifying or blanking CONEX
>> info
> 
> The milestones have the applicability statement going to the IESG 
> before the ConEx protocol is specified, so...
> 
> B. I'm not convinced we will be able to write a deployment analysis 
> of a protocol as yet to be defined - we can surely only write 
> requirements at that stage. C. And it's certainly not possible to
> write a meaningful threat analysis of something that hasn't yet been
> specified.
> 
> These problems would be solved by altering the chartering text as
> follows: s/deployment analysis/ /deployability goals/ s/threat
> analysis - threats from.../ /security goals - addressing threats
> from.../
> 
> Then after the protocol has been specified: - deployment analysis
> could be in "4. use-case(s)" - full threat analysis could be in "3B
> trust mechanisms"
> 
> 
> Bob
> 
> 
> 
>> The purpose is [1] to detail the key functional and non-functional
>> considerations that guide the work on the mechanism's design
>> 
>> [2] to allow exploration of use cases to begin before work on the 
>> mechanism is complete
>> 
>> [3] to provide an intuitive explanation of the new concepts in
>> CONEX
>> 
>>> Where do you imagine we should put best practice for the sending 
>>> transport to set its expectation of congestion? - The above EXP
>>> for e2e transport, - or within the ConEx-IP doc (if so, which
>>> one? v4 or v6)? It would seem to fit better in the e2e transport
>>> one, then the spec for TCP could provide an example of the
>>> complete best practice.
>> Yes, same as you - I'd imagined it would be in the e2e transport
>> doc. The IP doc defines packet the structure to carry CONEX
>> information  - ie what the codepoints are and what they mean. "what
>> they mean" of course influences what the sending transport should
>> do, but the advice for the sending transport would be in the
>> transport doc [things like "send, as soon as possible, a Black
>> codepoint for every loss or mark notified by the receiver". or
>> whatever!]
>> 
>> Thanks phil
>> 
>>> IOW, this proposal assumes the IP doc would not need to describe 
>>> semantics of *when* the transport sets the codepoints. Instead it
>>>  would focus on just the wire protocol - what the codepoints
>>> mean, how they are encoded, tunnel processing, router forwarding
>>> behaviour, errors & management etc.
>>> 
>>> Altho I'm not implying re-ECN is any more than a candidate, it
>>> would be a useful exercise to go through the contents of the
>>> re-ECN protocol spec <draft-briscoe-tsvwg-re-ecn-tcp-08> and
>>> check where you assume the different sections will end up. I've
>>> just done that, which is why I keep bringing up awkward
>>> questions.
>>> 
> 
> ________________________________________________________________ Bob
> Briscoe,                                BT Innovate & Design
> 
> 
> 
> ------------------------------
> 
> _______________________________________________ re-ECN mailing list 
> re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 11, Issue 2 
> *************************************
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ re-ECN mailing list 
> re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------