[Codel] [aqm] An independent implementation of CoDel in FreeBSD/ipfw/dummynet

[Dave Taht]

On Wed, Dec 16, 2015 at 12:35 PM, Rasool Al-Saadi <ralsaadi at swin.edu.au> wrote:
> Hello all,
>
> I am Rasool Al-Saadi, a PhD student at Centre for Advanced Internet Architectures - Swinburne University of Technology. I and my supervisor Grenville Armitage are implementing CoDel (and eventually PIE, FQ_CoDel and FQ_PIE) in FreeBSD targeting ipfw/dummynet framework as a small project funded by Comcast Corporation, USA.

groovy. I assume you are aware that there is already a bsd version of
codel derived from the bsd-licensed codel linux sources? Certainly
approve of doing one from the draft or paper or ns2 or ns3 models....

one of the reasons why cake is dual gpl/bsd licensed is to make it
easier to produce a bsd version one day.

I am delighted to see comcast funding independent work here (I would
love to see a "qfq-codel" developed by someone as the bsd sources for
QFQ  are a bit easier to understand than the linux ones)

> We used CoDel I-D (https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/) as the main source to implement CoDel and we believe that the information in the latest draft (draft-ietf-aqm-codel-02) sufficient and the pseudo-code is straightforward to create functional CoDel code. However, we have some questions/confusion regarding CoDel I-D:

yea!

>
> 1- There is little confusion in the text. In section 3.3, the text says "... the initial drop spacing SHOULD be set to the estimator's interval plus twice the target (i.e., initial drop spacing = 1.1 * interval) ...", while in section 4.1, the text says "As discussed in section 3.3, the initial next drop spacing is intended to be long enough to give the endpoints time to react to the single drop so SHOULD be set to a value of 1.0 to 1.1 times the interval."

yes.... that is the basic intent... but I agree it's confusing....
it's the inverse of the math - 5ms spent over target + 100ms = 1.05
times the interval.

do you have a suggestion that would make it more clear?

>
> 2- In section 3.2 and 4.4, the text says the ideal setpoint is 5-10% of the interval (connection RTT). So, should we allow the user to specify the target value as a percentage of the interval or an absolute value?

I would argue for a percentage nowadays if I were to argue for anything, but...

the thing is, despite much fiddling with various aspects of the
algorithm (I will let you know the list if you want and share the
extensive test results) there seems to be very little reason to allow
for the setpoint to be modified at all at any but the lowest
bandwidths or shortest or longest RTTs.

We outlined an existing problem in the fq_codel draft with setting the
target at less than the actual link rate (1mbit needing 13ms for a big
packet seems to need at >13ms target), but that is still at a folklore
stage rather than thoroughly examined (which we are examining now in
variants of "cake") - it would be really nice to obsolete target and
just declare it to be, say interval >> 4, and just fiddle with the
interval.

We're trying out a few assumptions like that at *really* low rates,
like 64k, now... with very mixed traffic from various flent tests.

==


Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi



>
> Regards,
> Rasool
>
> _______________________________________________
> aqm mailing list
> aqm at ietf.org
> https://www.ietf.org/mailman/listinfo/aqm