Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet

[Don Lewis]

On 26 Feb, Rasool Al-Saadi wrote:
> Dear all,
> 
> I would like to announce that we (myself and Grenville Armitage) released Dummynet AQM v0.1, which is an independent implementation of CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF  CoDel [1] and FQ-CoDel [2] Internet-Drafts.
> We prepared patches for FreeBSD11-CURRENT-r295345  and FreeBSD 10.x-RELEASE (10.0, 10.1, 10.2), and a technical report  of our implementation.
> 
> Patches and documentation can be found in:
> http://caia.swin.edu.au/freebsd/aqm
> 
> Technical report:
> http://caia.swin.edu.au/reports/160226A/CAIA-TR-160226A.pdf

I've got some results with running this on my firewall in an attempt to
tame a severe bufferbloat problem on my ADSL connection to the outside
world.

The raw speed numbers reported by my ADSL modem are 6016 Kb/s downstream
and 768 Kb/s upstream.  I set my MTU to 1492 to avoid fragmentation from
PPPoE overhead.

Using <http://www.dslreports.com/speedtest> with things unthrottled, I
observe about 5050 Kb/s downstream and 648Kb/s upstream, with a
bufferbloat rating of F.

I configured the system to use FQ-CoDel, with separate pipes for each
direction.  Because of the slow upstream speed, I increased the target
value for the upstream direction to 25 ms since a maximum size packet
will require about 20 ms to send.  I also set the
net.inet.tcp.experimental.initcwnd10 sysctl value to 0.  The latter
seemed to help a lot.  With this feature enabled, the initial packet
blast at the start of the upload caused a large initial latency spike,
and the initial transfer rate ended up being very slow and it took a
long time to ramp up to its maximum sustained value.

My current dummynet pipe bandwidth settings are 4800 Kb/s downstream and
615 Kb/s upstream.  The speedtest results for these settings are
about 4600 Kb/s downstream and about 600 Kb/s upstream.  I'm somewhat
disappointed in the bandwith loss, but my bufferbloat rating has
improved to mostly A's with some B's.

I do still see a large increase in latency at the start of transfers,
and then it oscillates for a while before settling down at a reasonable
value for the remainder of the transfer.  I suspect this is to be
expected.

It would be nice if the implementation was able to account for the PPPOE
and ATM framing overhead like the Linux implementation does.  I think
that would help performance when there is a mix of packet sizes.