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

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

[Nicolas Kuhn]

> On 29 Apr 2015, at 18:42, Bob Briscoe  > 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 
> 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?

[Fred Baker (fred)]

> On Apr 29, 2015, at 9:42 AM, Bob Briscoe  wrote:
> 
> 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.

I’m not sure RFC 2026 says anything about that; that’s RFC 2119. PIE describes 
an algorithm.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

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

[Bob Briscoe]

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.


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
https://www.ietf.org/mailman/listinfo/aqm