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) <roland.bl...@kit.edu> 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
