> On 29 Apr 2015, at 18:42, Bob Briscoe <[email protected]
> <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/aqm
> <https://www.ietf.org/mailman/listinfo/aqm>
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
