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

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 30 Mar 2010 13:57:23 +0200

Hi

I have one question. Based on my recently gained understanding about "emotional feelings" :-) around bit48 in IPv4 I can understand why you propose to make use of this bit experimental. 

However when it comes to IPv6 I am not really convinced why this need to be experimental. As I understand it the ConEx info will be encoded in an IPv6 extension that is encoded in such a way that a node can safely ignore it and just let it pass through if it does not understand it or does not care. 
My problem with the word "Experimental" is that it is just.. experimental and I have a hard time to understand if e.g 3GPP is interested at all to support something that is experimental. 
What is the risk of making the IPv6 header extension standards track ?

Regards
/Ingemar
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 30 Mar 2010 11:40:30 +0100
> From: <[email-masked]>
> Subject: [re-ECN] New draft Conex charter - for rapid comments please
> To: <[email-masked]>
> Message-ID:
> 	
> <[email-masked]
> .systemhost.net>
> 	
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 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
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/re-ecn/attachments/20100
> 330/e093c8a6/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 13, Issue 92
> **************************************
>

---

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

> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: 30 March 2010 12:57
> To: [email-masked]
> Cc: Eardley,PL,Philip,DEE1 R
> Subject: RE: [re-ECN] New draft Conex charter - for rapid 
> comments please
> 
> 
> Hi
> 
> I have one question. Based on my recently gained 
> understanding about "emotional feelings" :-) around bit48 in 
> IPv4 I can understand why you propose to make use of this bit 
> experimental. 
> 
> However when it comes to IPv6 I am not really convinced why 
> this need to be experimental. As I understand it the ConEx 
> info will be encoded in an IPv6 extension that is encoded in 
> such a way that a node can safely ignore it and just let it 
> pass through if it does not understand it or does not care. 
> My problem with the word "Experimental" is that it is just.. 
> experimental and I have a hard time to understand if e.g 3GPP 
> is interested at all to support something that is experimental. 

I have sympathy with your viewpoint - but the IESG have given us
guidance that it should be Experimental. There is no harda nf fast
guidance on what's experimental and what's standards track. Safety is
one thing I've heard to distinguish them (as you say) - another is "do
we believe this is baked enough for the IETF to recommend it for
widespread deployment?".
On the positive side, the transition from Experimental to standards
track is a well-accepted path.

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 30 Mar 2010 12:48:28 -0400

I'd like to expand a little on Phil's point.  The IESG guidance was 
based on expressed concerns over predicting the eventual success (and 
uptake) of CONEX.

Two options:

1/ Go for experimental, do experiments, demonstrate uptake and 
viability.  It's easy enough to move documents to standards track if 
it's warranted.

2/ Go for standards -- prove, now, that this is a recommended and 
desired direction for the Internet.

It seems "2/" is giving the IESG heartburn, and I think it's fair to say 
that it's easier to prove the viability of the approach when there is 
some form of open specification and results from broad-based 
experimental deployments.

In that light -- I think "1/" makes a lot of sense.

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 31 Mar 2010 09:18:52 +0200

OK

I still have my concerns on the experimental path as shorter lead-times in the industry may create a catch-22 situation, it will not be possible to test this on a larger scale as implementors are not interested in it just because it is "Experimental". Doing HW/software is quite expensive today and there are a lot of fancy features that wait to get implemented. The word "Experimental" does IMHO not encourage the industry to allocate people to implement this.

I believe that the tinking around the re-feedback (which is to be encoded in the IPv6 header) has come quite far, it may be the case that some yet unknown truths will emerge that may result in a need to update the re-feedback but then there are a lot of free bits in a IPv6 extension header and intelligent encoding can make it possible to create backwards compatible updates. 

As regards to IESGs concerns, will it be used by operators?. I see already today that there are a representatives of a few operators who shows interest in this on the list (and during the BoF sessions). If it fails ?, then it is not the first time a concept has failed and then we are stuck with an unused IPv6 header extension, is this a big problem ?

My 5€
/Ingemar

> From: Leslie Daigle [mailto:[email-masked]] 
> Sent: den 30 mars 2010 18:48
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]
> Subject: Re: [re-ECN] New draft Conex charter - for rapid 
> comments please
> 
> 
> I'd like to expand a little on Phil's point.  The IESG 
> guidance was based on expressed concerns over predicting the 
> eventual success (and
> uptake) of CONEX.
> 
> Two options:
> 
> 1/ Go for experimental, do experiments, demonstrate uptake 
> and viability.  It's easy enough to move documents to 
> standards track if it's warranted.
> 
> 2/ Go for standards -- prove, now, that this is a recommended 
> and desired direction for the Internet.
> 
> 
> >> From: Ingemar Johansson S 
> [mailto:[email-masked]]