Re: [aqm] working group last call on CoDel drafts

[Dave Taht]

In just about every benchmark we have created to date, the linux
version of the codel implementation wins over dozens of attempted
alternatives. We have one that is mildly better at a 10ms RTT, but not
as good at 80ms, but that's it.

This doesn't mean that more experimentation isn't called for (there
are two radical alternatives I know of still being tested), but I
would vote for putting the linux version into the codel draft.


On Fri, Dec 4, 2015 at 11:16 AM, Bless, Roland (TM)
 wrote:
> Dear all,
>
> we believe that the Codel specification
> https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ needs at least one
> major clarification.
>
> The following lines are present in the draft's pseudo-code, but are not
> explained further anywhere in the document text, and moreover differ from
> the Linux implementation [*], that the document also suggests as reference
> implementation.
>
>// If min went above target close to when it last went
>// below, assume that the drop rate that controlled the
>// queue on the last cycle is a good starting point to
>// control it now. ('drop_next' will be at most 'interval'
>// later than the time of the last drop so 'now - drop_next'
>// is a good approximation of the time from the last drop
>// until now.)
>count_ = (count_ > 2 && now - drop_next_ < 8*interval_)?
>count_ - 2 : 1;
>
> This line makes sure, that when two dropping states are entered within a
> short interval from each other, the variable count is not reset (to zero),
> but is rather changed somehow. In this document, count is decreased by two,
> while in the Linux version, count is set to the number of packets, that were
> dropped in the previous dropping state.
>
> Based on the email-thread that was started from these messages ...
>  http://www.ietf.org/mail-archive/web/aqm/current/msg00376.html
> http://www.ietf.org/mail-archive/web/aqm/current/msg01250.html
> http://www.ietf.org/mail-archive/web/aqm/current/msg01455.html
>
> ... one can infer, that:
> 1) the case where count is not reset is not an exception, but rather a
> common case (that we can confirm from our measurements),

It is a common case. Most of the other behaviors in codel are in
attempting to seek to the optimum drop rate, that bit is the one that
maintains the optimal drop rate.

> 2) several options for this behavior were described on the mailing list some
> time ago,
>
> Since it is the most common case, this part of the algorithm should be
> explained in the specification.
> If the two versions will continue to differ, both algorithms (and their
> difference in behavior) should be explained,
> but in order to avoid confusion for implementers/operators we believe that
> specification of a single algorithm is preferable .

I could make a counter argument saying that diversity and not having a
monoculture is good, and that it is possible to make other codels with
very similar behavior... but I too would prefer the one true
implementation in this draft.

>
> Regards,
>   Roland and Polina
>
> [*] https://github.com/torvalds/linux/blob/master/include/net/codel.h#L341
>
> Am 02.12.2015 um 16:45 schrieb Wesley Eddy:
>
> These both have the intended status designated as "Informational". Similar
> to the questions asked for PIE, we/chairs need to understand if there's
> consensus on:
> - Are these specifications are clear and sufficient quality to publish?
> - Should the status of the RFCs be "Experimental", "Proposed Standard", or
> "Informational"?
>
>
>
> ___
> 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] working group last call on CoDel drafts

[Bless, Roland (TM)]

Dear all,

we believe that the Codel specification
https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ needs at least
one major clarification.

The following lines are present in the draft's pseudo-code, but are not
explained further anywhere in the document text, and moreover differ
from the Linux implementation [*], that the document also suggests as
reference implementation.

   // If min went above target close to when it last went
   // below, assume that the drop rate that controlled the
   // queue on the last cycle is a good starting point to
   // control it now. ('drop_next' will be at most 'interval'
   // later than the time of the last drop so 'now - drop_next'
   // is a good approximation of the time from the last drop
   // until now.)
*count_ = (count_ > 2 && now - drop_next_ < 8*interval_)? count_ - 2 : 1; *

This line makes sure, that when two dropping states are entered within a
short interval from each other, the variable /count/ is not reset (to
zero), but is rather changed somehow. In this document, /count/ is
decreased by two, while in the Linux version, /count/ is set to the
number of packets, that were dropped in the previous dropping state.

Based on the email-thread that was started from these messages ...
 http://www.ietf.org/mail-archive/web/aqm/current/msg00376.html
http://www.ietf.org/mail-archive/web/aqm/current/msg01250.html
http://www.ietf.org/mail-archive/web/aqm/current/msg01455.html

... one can infer, that:
1) the case where /count/ is not reset is not an exception, but rather a
common case (that we can confirm from our measurements),
2) several options for this behavior were described on the mailing list
some time ago,

Since it is the most common case, this part of the algorithm should be
explained in the specification.
If the two versions will continue to differ, both algorithms (and their
difference in behavior) should be explained,
but in order to avoid confusion for implementers/operators we believe
that specification of a single algorithm is preferable .

Regards,
  Roland and Polina

[*] https://github.com/torvalds/linux/blob/master/include/net/codel.h#L341

Am 02.12.2015 um 16:45 schrieb Wesley Eddy:
> These both have the intended status designated as "Informational".
> Similar to the questions asked for PIE, we/chairs need to understand
> if there's consensus on:
> - Are these specifications are clear and sufficient quality to publish?
> - Should the status of the RFCs be "Experimental", "Proposed
> Standard", or "Informational"?
>

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

[aqm] working group last call on CoDel drafts

[Wesley Eddy]

This message is to start a working group last call on the CoDel and 
FQ-CoDel documents:

https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
and:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/

Please provide any comments you might be saving up on these by the end 
of December.


These both have the intended status designated as "Informational". 
Similar to the questions asked for PIE, we/chairs need to understand if 
there's consensus on:

- Are these specifications are clear and sufficient quality to publish?
- Should the status of the RFCs be "Experimental", "Proposed Standard", 
or "Informational"?







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