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

From: Bob Briscoe <[email-masked]>
Date: Wed, 29 Apr 2015 17:42:15 +0100

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

---

From: Andrew Mcgregor <[email-masked]>
Date: Thu, 30 Apr 2015 12:46:17 +1000

FWIW, the authors and editors have been thinking of CoDel as informational;
I think this comes from a discussion post-chartering which converged to
"there is no one AQM to rule them all, therefore we won't be doing
standards track".

On 30 April 2015 at 02:42, Bob Briscoe <[email-masked]> 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.
>
> 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.
>
> 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.
>
> 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
>
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 30 Apr 2015 04:36:05 +0000

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

---

From: Nicolas Kuhn <[email-masked]>
Date: Thu, 30 Apr 2015 09:22:26 +0200

> On 29 Apr 2015, at 18:42, Bob Briscoe <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Richard, Wes,
> 
> 1) The AQM charter says:
> "Dec 2014 - Submit first algorithm specification to IESG for publication as Proposed Standard"
> 
> 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
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/aqm <https://www.ietf.org/mailman/listinfo/aqm>

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 30 Apr 2015 08:43:20 -0400

> "Dec 2014 - Submit first algorithm specification to IESG for publication

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