Re: [aqm] PIE (and CoDel) drafts: proposed standard vs informational?

[Nicolas Kuhn]

 On 29 Apr 2015, at 18:42, Bob Briscoe bob.bris...@bt.com 
 mailto:bob.bris...@bt.com wrote:
 
 Richard, Wes,
 
 1) The AQM charter says:
 Dec 2014 - Submit first algorithm specification to IESG for publication as 
 Proposed Standard
 
 I volunteered to do a thorough review of the PIE draft, which I'm just 
 writing up. One of the problems is that it says 'Proposed Standard' at the 
 top, but it's written in an informational style. There is no normative 
 language saying what a PIE implementation MUST do, what it SHOULD do and what 
 it MAY do.
 
 And actually, I'm not convinced that it would be worthwhile to add normative 
 language. On reflection, I believe it would be better left as an informative 
 specification of the PIE algorithm and its possible variants.
 
 I'm not religious about this. Normative language might be useful. But on a 
 pragmatic note, it will take considerable time and argument to decide which 
 aspects are the essence of PIE and which are optional, because we will then 
 have to consider whether certain combinations of options are not workable, or 
 whether taking out too many of the optional parts makes it non-viable.
 
 What will be the point of being able to say that a particular implementation 
 complies with an RFC that recorded at one snapshot in time what we thought 
 defined the line between PIE and not PIE? If a future improvement is not 
 described in the RFC, it will be non-compliant but better.
 
 BTW, wrt the CoDel draft, it does contain some normative language., but there 
 are many aspects of the spec where it is not stated whether they are MUST, 
 SHOULD or MAY. So this email really applies to both specs.
 
 2) There /are/ interoperability concerns between AQMs, and between 
 delay-based congestion controls (like LEDBAT) and AQMs. Writing a Proposed 
 Standard giving the interoperability constraints on all AQMs would be a 
 useful exercise. However, giving the special status of proposed standard to 
 one design of PIE at one snapshot in time will not say anything about 
 interoperability.
 

I think that this point 2) should be considered in the evaluation guidelines. 
I propose to add a scenario to assess the performance of delay-based congestion 
controls when there is an AQM. 
The ToC would become:

4.  Transport Protocols 
  4.1.  TCP-friendly sender 
4.1.1.  TCP-friendly sender with the same initial congestion  window
   4.1.2.  TCP-friendly sender with different initial congestion window
  4.2.  Aggressive transport sender
  4.3.  Unresponsive transport sender 
  4.3.  Delay-based transport sender 

What do you think ?

Nicolas


 3) If someone comes up with an improvement on PIE (or CoDel) next week or 
 next month or next year, will the IETF want to standardise it? Is the 
 intention that AQM-chair will be a job for life?
 
 
 Bob
 
 
 
 Bob Briscoe,  BT  
 ___
 aqm mailing list
 aqm@ietf.org mailto:aqm@ietf.org
 https://www.ietf.org/mailman/listinfo/aqm 
 https://www.ietf.org/mailman/listinfo/aqm

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] PIE (and CoDel) drafts: proposed standard vs informational?

[Wesley Eddy]

On 4/29/2015 12:42 PM, Bob Briscoe wrote:
 Richard, Wes,
 
 1) The AQM charter says:
 Dec 2014 - Submit first algorithm specification to IESG for publication
 as Proposed Standard
 


Hi Bob, thanks for raising this, since it probably requires some
clarification and discussion.  I thought we'd outlined this a bit
on the list and through discussion a couple meetings ago, but it
might not have been integrated back into the charter.

I think the intention when chartering was to enable us to put
something on Standards Track, if there is consensus, but not
to limit us to only Standards Track.

It seems apparent that there are drafts which the group has
agreed are worth publishing (the ones we've adopted), and part
of submitting them for publication is deciding on the status
they'll be stamped with.  If the group wants to do Informational
or Experimental and feels those are more appropriate, then
obviously that's what we'll do.

I'm pretty sure our ADs support that, but am happy for them to
jump in and correct it, if not!

-- 
Wes Eddy
MTI Systems

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm