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 waited 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.

However, I have noticed that the commercial implementations for at least two firewalls that I have used (OPNsense and a Unifi gateway) both require the user to input the upload and download bandwidths of the link.

In OPNsense I tried setting the bandwidth to a large number above the actual link bandwidth and then manually setting the fq-codel parameters to their Linux defaults, but that resulted in poor performance. My concern, of course, is that I'm leaving throughput 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.

I'm not sure what exactly OPNsense is doing with the bandwidth parameters, and I've asked on its forum (https://forum.opnsense.org/index.php?topic=44501.0). My question for all of you is whether I am misunderstanding something about fq-codel. Does it need to be configured with the link bandwidth, or can it work nicely in its default configuration with variable bandwidth links (let's consider a typical home fiber connection between 300 and 1000 Mbps).

Thanks for any insight you can share.