What is the bandwidth parameter to fd-codel used for?

[emzy]

As far as I can tell, the fq-codel algorithm (https://www.rfc-editor.org/rfc/rfc8290.html) doesn't use link bandwidth as a parameter. From reading the description, it seems like it should be able to work without knowing the link bandwidth since it decides to drop packets based on the amount of time they have sat in a queue. In fact, the original codel rfc (https://www.rfc-editor.org/rfc/rfc8289#section-4.1) even says that it's designed to be non-starving and work over variable bandwidth links.

So, why does configuring fq-codel in opnsense require the link bandwidth to be specified? I tried setting the bandwidth to a large number above the actual link bandwidth and then manually setting the fq-codel parameters to their defaults, but that resulted in poor performance. My concern, of course, is that I'm leaving performance on the table by artificially limiting the bandwidth at a value that may be less than the actual available bandwidth depending on the time of day, etc.

So concretely, what does opnsense do with the bandwidth number and how does that affect the performance of fq-codel? Is there a way to configure fq-codel without needing to know the link bandwidth?

[emzy]

I asked this as a more general question about the algorithm on the codel mailing list and learned a lot. You can read the thread here:

- https://lists.bufferbloat.net/pipermail/codel/2024-December/002512.html

Quoting Dave Taht who implemented fq_codel on Linux:

> Further most ISPs use a non-native rate for their customer interfaces,
> either using a policer or FIFO shaper and thus the rise of combatting
> that with shaping via fq_codel to slightly below the ISPs' rate to
> move the bottleneck to your own hardware.

So essentially you need to move the bottleneck from the ISP to your hardware so that fq_codel has the back pressure it needs to work properly.

[OPNenthu]

So, why does configuring fq-codel in opnsense require the link bandwidth to be specified?

As a practical matter, shaping in OPNsense is via pipes which are fixed.  That is on top of everything the author says about FQ_CoDel.

I think what you are looking to do implies that FQ_CoDel could be divorced from the shaping framework in OPNsense, and I don't know the answer to that.  (leaving aside the issue of moving the bottleneck off of the ISP gateway)