Subject: [re-ECN] FW: New draft Conex charter - for rapid comments please

From: <[email-masked]>
Date: Wed, 31 Mar 2010 17:53:50 +0100

Cc list, which got dropped by mistake
phil

-----Original Message-----
From: Eardley,PL,Philip,DEE1 R 
Sent: 31 March 2010 17:45
To: 'Alissa Cooper'
Subject: RE: [re-ECN] New draft Conex charter - for rapid comments
please

> >
> > In establishing this working group, much interest was expressed in 
> > pursuing an IPv4 specification. A new work item proposed for TSVWG
> > would define how 'bit 48' of the IPv4 header can be used for  
> > Experiments.
> >
> [AC] It's unclear what this means -- has the work item already been
> proposed? Will it definitely be proposed? Or does the CONEX 
> group just  
> really hope it gets proposed so we can get on with standardizing  
> something in the IPv4 header?
> 
At the moment, the last is nearest

How about this -
The WG hopes that other IETF work (to be proposed for TSVWG) will define
how 'bit 48' of the IPv4 header can be used for Experiments.

Thanks
phil 

----

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: 31 March 2010 17:36
To: Eardley,PL,Philip,DEE1 R
Subject: Re: [re-ECN] New draft Conex charter - for rapid comments
please

Two comments inline...

On Mar 30, 2010, at 6:40 AM, <[email-masked]>
<[email-masked] 
 > wrote:
>
> ---
> Congestion Exposure (CONEX) WG
>
>
> The purpose of the CONEX working group is to develop a mechanism by
> which senders inform the network about the congestion their packets  
> encounter. Today, the network signals congestion by ECN marking or  
> dropping packets, the receiver passes this information back to the  
> sender in transport layer acknowledgements, where the sender makes  
> an adjustment to its window size or data rate as appropriate.
>
[AC] s/the receiver passes/and the receiver passes/
> The mechanism to be developed under CONEX will enable the sender to
> also relay the congestion information back into the IP layer such  
> that the total level of congestion is visible to all IP devices  
> along the path.
>
> The primary goal of the CONEX WG is to develop experimental
> specifications to achieve the above. To help explore how to squeeze  
> the necessary information into a very limited numbers of header  
> bits, the WG will also develop an abstract specification for the  
> congestion exposure mechanism, independent of transport and protocol  
> version.
>
> Primary work items are:
>
> *       An Informational document with an abstract specification for  
> the congestion exposure mechanism
> *       Experimental Specification of IPv6 packet structure that  
> encapsulates CONEX information (header bits, interpretation).
>
> *       Experimental Specification for modification to TCP, for the  
> timely transport of congestion information from the destination to
> the sender
>
> It is believed that the CONEX mechanism will be useful as a
> generative technology which can be applied as a key element of  
> congestion management solutions in a wide variety of use cases.  
> However, the WG will initially focus solely on one use case, where  
> the end hosts and the network of the destination end host are CONEX- 
> enabled but the other networks are not. CONEX information can assist  
> the network operator's traffic management and incentivise LEDBAT- 
> like applications. Experiments on the use case are encouraged and  
> the WG will solicit input about their process and findings. The  
> output of the WG includes Informational document(s) for the use case  
> covering:
>
> *       Assumptions it makes
> *       Deployment considerations
> *       Security Threats
> *       Advice on mitigating threats (detailed work on a mechanism  
> to mitigate the threats is out of the initial scope)
> *       Description of results from experiments on the use case
>
> In establishing this working group, much interest was expressed in
> pursuing an IPv4 specification. A new work item proposed for TSVWG  
> would define how 'bit 48' of the IPv4 header can be used for  
> Experiments.
>
[AC] It's unclear what this means -- has the work item already been  
proposed? Will it definitely be proposed? Or does the CONEX group just  
really hope it gets proposed so we can get on with standardizing  
something in the IPv4 header?

> At the appropriate time, the CONEX WG will consider rechartering to
> include a work item to specify the IPv4 packet structure to  
> encapsulate CONEX information.
>
> Milestones
>
> Jul 2010 Internet-draft Informational document with an abstract
> specification for the congestion exposure mechanism
>
> Jul 2010 Internet-draft use case
>
> Sep 2010 Internet-draft specification of IPv6 packet structure.
>
> Sep 2010 Internet-draft specification for modification to TCP
>
> Mar 2011 Informational RFC abstract specification of the congestion
> exposure mechanism
>
> Mar 2011 Informational RFC use case
>
> Sep 2011 Experimental RFC specification of IPv6 packet structure
>
> Sep 2011 Experimental RFC specification for modification to TCP
>
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: ken carlberg <[email-masked]>
Date: Wed, 31 Mar 2010 13:13:25 -0400

> how 'bit 48' of the IPv4 header can be used for Experiments.

or words to the effect of "...the WG intends to revisit the issue with IPv4..."

However its articulated, I think its important to place a hook in the charter that convey's the interest of the WG to applying the effort to IPv4, if at all possible, and even if just under the context of initially an experimental effort.

-ken

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 18:26:04 +0100

Here's the complete paragraph at the moment

<
In establishing this working group, much interest was expressed in
pursuing an IPv4 specification. The WG hopes that other IETF work (to be
proposed for TSVWG) will define how 'bit 48' of the IPv4 header can be
used for Experiments. At the appropriate time, the CONEX WG will
consider rechartering to include a work item to specify the IPv4 packet
structure to encapsulate CONEX information. 

- I think this conveys that the wg is very interested in v4. not sure
how to spell it out better. The problem with saying something like "the
WG intends to revisit the issue with IPv4" is that it seems to say the
charter includes v4. somehow we need to say that although v4 is out of
scope at the moment, we believe it's important work that we will want to
do, once it's a bit clearer how to do this - like the bit48 stuff has
got further - and once we'r re-chartered to do it.

Open to suggestions [eg a complete new para] as jet lag is starting to
zap my word generator.

Thanks
phil

> From: ken carlberg [mailto:[email-masked]] 
> Sent: 31 March 2010 18:13
> Cc: [email-masked]
> Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid 
> comments please
> 
> 
> 
> > The WG hopes that other IETF work (to be proposed for TSVWG) will 
> > define how 'bit 48' of the IPv4 header can be used for Experiments.
> 
> However its articulated, I think its important to place a 
> hook in the charter that convey's the interest of the WG to 
> applying the effort to IPv4, if at all possible, and even if 
> just under the context of initially an experimental effort.
> 
> -ken
> 
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 31 Mar 2010 14:59:26 -0400

On Mar 31, 2010, at 1:26 PM, <[email-masked]> <[email-masked] 

> structure to encapsulate CONEX information.

I think this paragraph does the job.
Alissa

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 31 Mar 2010 22:29:35 +0100

Phil, Leslie,

Thanks for all the ducking and diving you guys have had to do on this.

Could you post what you now believe is the latest state of the charter text?

I have just one nit:
s/the WG will initially focus solely on one use case/
   the WG will initially focus on one use case/

I suggest this, because I am concerned we otherwise preclude keeping 
in mind that ConEx should work in other use cases (which I'm sure 
was't the IESG intention).

In particular, the proposed use-case precludes two networks using 
ConEx info at their mutual border. Given interconnect was identified 
as the main unique selling point of ConEx (see earlier thread by Rich 
Woundy, Alissa Cooper, Mat Ford etc), we don't want to completely 
preclude using ConEx at interconnect.

To satisfy the IESG, we only have to promise not to make anything 
depend on MPLS. I don't think anyone on the IESG wanted us to 
preclude interconnection from ConEx scope.

Bob

> > Sep 2011 Experimental RFC specification for modification to TCP

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Apr 2010 09:28:59 +0300

Hi,

> Could you post what you now believe is the latest state of the charter text?

this was directed at Phil, but since he sent me what he believed to be the final text and I made some minor edits, I'll send you what I sent him an hour ago. 

Please let me know if this looks good to you.

Lars

The purpose of the CONEX working group is to develop a mechanism
by which senders inform the network about the congestion their
packets encounter. Today, the network may signal congestion by ECN
markings or by dropping packets, and the receiver passes this
information back to the sender in transport-layer acknowledgements,
where the sender makes an adjustment to its window size or data
rate, as appropriate. The mechanism to be developed by the CONEX
WG will enable the sender to also relay the congestion information
back into the IP layer, such that the total level of congestion is
visible to all IP devices along the path.

The primary goal of the CONEX WG is to develop experimental
specifications to achieve the above. The WG will also develop an
abstract, higher-level description of the congestion exposure
mechanism. 

Primary work items are:

  * An Informational document containing an abstract description of
    the congestion exposure mechanism that is independent of specific
    transport protocols and congestion information encoding techniques
    needed for different IP protocol versions.
    
  * An Experimental specification of an IPv6 packet structure that
    encapsulates CONEX information, defining a packet format and an
    interpretation.
    
  * An Experimental specification of a modification to TCP, for the
    timely transport of congestion information from the destination to
    the sender.

It is believed that the CONEX mechanism will be useful as a generative
technology that can be applied as a key element of congestion
management solutions in a wide variety of use cases. However, the
CONEX WG will initially focus solely on one use case, where the end
hosts and the network that contains the destination end host are
CONEX-enabled but other networks are not. CONEX information can
assist the network operator's traffic management and, for example,
incentivize LEDBAT-like applications. Experiments on such use cases
are encouraged and the WG will solicit feedback from such deployments.
The WG may decide to document the experience from such use cases
in Informational documents, covering:

  * Assumptions made

  * Advice on how to use the CONEX mechanism as an element of a
    congestion management solution

  * Security threats and advice on mitigation approaches (detailed
    specifications of threat mitigation techniques are out of scope) 

  * Descriptions of results from experiments with the use case 

During the chartering discussion of the CONEX WG, much interest was
expressed in pursuing a CONEX specification for IPv4. Due to the
complications of experimenting with 'bit 48', i.e., the last
unassigned bit in the IPv4 header, this was decided to be out of
scope for the initial charter. If the IETF comes to consensus on
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 

Mar 2011   Submit abstract specification for the congestion
           exposure mechanism 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
           Experimental

Sep 2011   Submit specification for modification to TCP to IESG as
           Experimental