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

[Don Lewis]

On 20 Apr, Rasool Al-Saadi wrote:
> 
> 
>> -----Original Message-----
>> From: Don Lewis [mailto:truckman at FreeBSD.org]
>> Sent: Thursday, March 10, 2016 7:29 PM
>> To: Rasool Al-Saadi <ralsaadi at swin.edu.au>
>> Cc: aqm at ietf.org; freebsd-net at FreeBSD.org; freebsd-ipfw at FreeBSD.org;
>> Grenville Armitage <garmitage at swin.edu.au>
>> Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's
>> ipfw/dummynet
>> 
>> 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.
> 
> Dave Täht suggests you to try a "quantum 300" for your 600kbit uplink.

Actually I need to decrease the quantum from 1514 to 1506 in the other
direction as well.  I decreased the MTU on this path to 1492 to
compensate for the PPPOE header that is added by my DSL router.  The
default 1500 byte MTU will result in fragmentation.  If I don't change
the quantum to match, then periodically two maximal size packets will be
allowed from the same flow.

> BTW, if you interested try our FQ-PIE implementation in Dummynet AQM v0.2 in your configuration.

I'm planning on trying that when I have the time.  I also want to test
with and without ECN on the end station.