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

From: <[email-masked]>
Date: Tue, 30 Mar 2010 11:40:30 +0100

Just to let those of you who weren't in Anaheim about progress. 

We had two good meetings, there are extensive jabber notes (offiicial meeting notes to follow)
http://www.ietf.org/jabber/logs/conex/2010-03-24.txt
http://www.ietf.org/jabber/logs/conex/2010-03-25.txt

We discussed how to change the Charter to meet the issues raised. The following were proposed and received good support:
* Experimental track (no Standards track docs)
* for the use cases work, concentrate on one use case (where the end hosts & the destination network are conex-enabled, but not the other networks)
* do IPv6 header encoding
* suggest a work item in tsvwg (probably) about assigning "bit 48" as Experimental in the IPv4 header 

Here's a new draft Charter implementing these changes. If we can complete by Thursday lunchtime, then we should get it into the next IESG call.

Thanks
Phil & Leslie
---
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.  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. 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

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 30 Mar 2010 08:04:03 -0400

Phil,
 
A few comments in line below prefixed by DM.
 
Thanks,

Dave

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Tuesday, March 30, 2010 6:41 AM
	To: [email-masked]
	Subject: [re-ECN] New draft Conex charter - for rapid comments
please

	We had two good meetings, there are extensive jabber notes
(offiicial meeting notes to follow) 
	http://www.ietf.org/jabber/logs/conex/2010-03-24.txt 
	http://www.ietf.org/jabber/logs/conex/2010-03-25.txt 

	We discussed how to change the Charter to meet the issues
raised. The following were proposed and received good support:

	* Experimental track (no Standards track docs) 
	* for the use cases work, concentrate on one use case (where the
end hosts & the destination network are conex-enabled, but not the other
networks)

	* do IPv6 header encoding 
	* suggest a work item in tsvwg (probably) about assigning "bit
48" as Experimental in the IPv4 header 

	Here's a new draft Charter implementing these changes. If we can
complete by Thursday lunchtime, then we should get it into the next IESG
call.

	Thanks 
	Phil & Leslie 
	--- 

	The purpose of the CONEX working group is to develop a mechanism
by which senders inform 
                                                                 some 
the network about the congestion their packets encounter. Today, ^^^^^
networks signal

DM: Not every implementation supports ECN marking in the network, nor
does every operator enable it in implementations that do. Slight
rewording proposed to not give the impression that network elements
(e.g., routers) setting ECN is already widely done today.

 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.  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. 

DM: IPv6 may provide additional bits or methods to signal congestion as
an alternative to and/or as a complement to ECN. 

	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, 

DM: This limitation seems to apply to only IPv4. Can the charter
separate this case for IPv4 fromt that of IPv6. Recall Adrian's comments
at the mike.

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 
DM: suggesting adding "unconstrained by the number of available bits in
the IP header"

	*       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.

DM: This is an extremely important point -- working only with TCP (e.g.,
ECN) is not enough, the use cases must include protocols that are a
client of the TCP. Not clear from this wording whether this will be part
of the use case, and I would like for it to be part of the use case. 

 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. 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 

	Mar 2011 Informational RFC abstract specification of the
congestion exposure mechanism

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 16:27:02 +0100

Thanks
In-line
phil

> -----Original Message-----
> From: Mcdysan, David E [mailto:[email-masked]] 
> Sent: 30 March 2010 13:04
> To: Eardley,PL,Philip,DEE1 R; [email-masked]
> Subject: RE: [re-ECN] New draft Conex charter - for rapid 
> comments please
> 
> 
> Phil,
>  
> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 	Subject: [re-ECN] New draft Conex charter - for rapid 
> comments please
> 	
> 	
> 
> 	We had two good meetings, there are extensive jabber 
> notes (offiicial meeting notes to follow) 
> 	We discussed how to change the Charter to meet the 
> issues raised. The following were proposed and received good support:
> 
> 	* for the use cases work, concentrate on one use case 
> (where the end hosts & the destination network are 
> conex-enabled, but not the other
> networks)
> 
> 	* suggest a work item in tsvwg (probably) about 
> assigning "bit 48" as Experimental in the IPv4 header 
> 
> 	Here's a new draft Charter implementing these changes. 
> If we can complete by Thursday lunchtime, then we should get 
> it into the next IESG call.
> 
> 	Thanks 
> 	Phil & Leslie 
> 	--- 
> 	The purpose of the CONEX working group is to develop a 
> mechanism by which senders inform 
>                                                                  some 
> the network about the congestion their packets encounter. 
> Today, ^^^^^ networks signal
> 
> DM: Not every implementation supports ECN marking in the 
> network, nor does every operator enable it in implementations 
> that do. Slight rewording proposed to not give the impression 
> that network elements (e.g., routers) setting ECN is already 
> widely done today.

Phil: adding ^^^some - might suggest that only some networks drop pkts!?
Perhaps: "Today networks ^^may signal congestion by ECN marking or
dropping packets

> 
>  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.  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. 
> 
> DM: IPv6 may provide additional bits or methods to signal 
> congestion as an alternative to and/or as a complement to ECN. 

Phil: sorry, is this a comment or suggested extra text? (I don't think
it's needed]

> 
> 	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, 
> 
> DM: This limitation seems to apply to only IPv4. Can the 
> charter separate this case for IPv4 fromt that of IPv6. 
> Recall Adrian's comments at the mike.

Phil: was trying to say something very brief to justify the abstract
spec. but see your point.
Perhaps it's easiest simply to delete the phrase and start at "The WG
will ..."

> 
> the WG will also develop an abstract specification for the 
> congestion exposure mechanism, independent of transport and 
> protocol version.
> 
> 	Primary work items are: 
> 
> DM: suggesting adding "unconstrained by the number of 
> available bits in the IP header"

Phil: I like this addition [will add "for example unconstrained..."

> 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.
> 
> ECN) is not enough, the use cases must include protocols that 
> are a client of the TCP. Not clear from this wording whether 
> this will be part of the use case, and I would like for it to 
> be part of the use case. 

Phil: ok, I see the problem is that the list of bullets for the use case
needs to include:
* Advice on how to use the CONEX mechanism as an an element of a
congestion management solution

> 
>  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 
> 	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. 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 
>

---

From: ken carlberg <[email-masked]>
Date: Tue, 30 Mar 2010 11:28:35 -0400

> Here's a new draft Charter implementing these changes. If we can complete by Thursday lunchtime, then we should get it into the next IESG call.
I thought that Lars had presented a reasonable alternative with respect to the IPv4 and/or IPv6 encodings that suggested starting out with IPv6 and then soon revisiting the work with IPv4 -- kind of a staggered design effort.

While there were some folks who understandably expressed concern about assigning the last available bit in IPv4, it would seem that the status of experimental versus standards track makes this assignment quite tentative.  In addition, one thing not mentioned in the meeting was that there is always the process of changing a document to historic, which would allow the IETF to reclaim that last bit, if necessary.

Of course, if IPv4 is soon to be replaced by IPv6 anyway, then the potential need for that last bit in IPv4 should really diminish quite fast.  Besides, the rate at which documents get through the IETF these days means that we do have some time before any CONEX draft becomes an RFC :-) 

-ken

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 16:35:03 +0100

I thought that Lars had presented a reasonable alternative with respect
to the IPv4 and/or IPv6 encodings that suggested starting out with IPv6
and then soon revisiting the work with IPv4 -- kind of a staggered
design effort. 
 
[phil] i think this staggering meant: initially charter for v6 - later
charter for v4 (eg when there's progress on re-assigning bit48 from
Reserved to Experimental] 

	While there were some folks who understandably expressed concern
about assigning the last available bit in IPv4, it would seem that the
status of experimental versus standards track makes this assignment
quite tentative.  In addition, one thing not mentioned in the meeting
was that there is always the process of changing a document to historic,
which would allow the IETF to reclaim that last bit, if necessary.

	Of course, if IPv4 is soon to be replaced by IPv6 anyway, then
the potential need for that last bit in IPv4 should really diminish
quite fast.  Besides, the rate at which documents get through the IETF
these days means that we do have some time before any CONEX draft
becomes an RFC :-)  

	-ken

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 30 Mar 2010 18:17:18 +0200

Hi,

this sentence was not really clear to me at the first moment:

> CONEX information can assist the network operator's

I suggest a working like: CONEX information supports a network operator's 
traffic management which is sensitive to congestion (and not to data volume 
or rate) and thereby creates an advantage for using LEDBAT-like congestion 
control.

BR,
Mirja

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 30 Mar 2010 13:10:22 -0400

Hi Phil,

A few responses in line below, attempting to finalize my inputs.

Thanks,

Dave 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 30, 2010 11:27 AM
> To: Mcdysan, David E; [email-masked]
> > Subject: RE: [re-ECN] New draft Conex charter - for rapid comments 
> > please
> > 
> > 
> > Phil,
> >  

DM: Inserting "may" works for me.

> Perhaps it's easiest simply to delete the phrase and start at "The WG

DM: Deleting the phrase "To help  explore how to squeeze the necessary
information into a very  limited numbers of header bits," addresses my
point.

> Phil: I like this addition [will add "for example unconstrained..."

DM: I think more people expressed support for IPv6. 
> congestion management solution

DM: Possibly add a reference to the LEDBAT sentence as an example here
for clarity?

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 30 Mar 2010 21:16:51 +0000

Hi Phil

The new charter looks much better, it is clear and it satisfies the
conclusions of the CONEX BOF meeting that we have had in Anaheim!

Best regards,
Georgios

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 31 Mar 2010 12:43:51 -0400

Two comments inline...

On Mar 30, 2010, at 6:40 AM, <[email-masked]> <[email-masked] 
 > wrote:
> 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.
>
> 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:
>
> *       Experimental Specification for modification to TCP, for the  
> timely transport of congestion information from the destination to  
> the sender
>
> 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
> *       Advice on mitigating threats (detailed work on a mechanism  
> to mitigate the threats is out of the initial scope)
> In establishing this working group, much interest was expressed in  
> pursuing an IPv4 specification. A new work item proposed for TSVWG  
> 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
>
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

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

Hi Mirja,

- I think adding in something like 'helps it be sensitive to congestion' is a bit redundant [the fact it's conex information should tell the reader this]
- adding '(not data volume or rate)' might be provocative. Some people would see conex info as additional - used alongside volume & rate
- adding 'thereby' seems good to help connect between the 2 halves of the sentence.
- I don't mind whether 'creates an advantage for using' or 'incentivises' [the latter is shorter but not a word, at least it's not in Chambers]
- I think it's better to say 'LEDBAT-like applications' than 'LEDBAT-like congestion control' [someone who doesn't know what ledbat is might wonder whether 'congestion control' means by end systems or by something else]

Thanks
phil 

> [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
> Sent: 30 March 2010 17:17
> To: [email-masked]
> Subject: Re: [re-ECN] New draft Conex charter - for rapid 
> comments please
> 
> 
> Hi,
>