I was until now unsure as to how to file a bug report here. I do not run openbsd but am one of the authors of RFC8290, and of the linux and ns2/ns3 versions of fq_codel. I think the implementation in openbsd has a scaling problem, that comes from the drop (count variable in the RFC) being capped at 400 in the codel_control_law here:
https://github.com/openbsd/src/blob/c069659183f0d17034b0869e8f990e6330e6c06c/sys/net/fq_codel.c#L340 It is supposed to be essentially a free-running variable, interacting complexedly with going over/under the target setting. As drop rates go up with more flows pounding the link (try, oh, steam? or torrent) capping this variable makes the AQM component increasingly less effective, or so I think from various reports in the field. The fix is rather easy - (but I am not sure if it is the only one needed) A) just delete all that code and lookup table and do the invsqrt via the newton approximation all the way to saturation. (the linux code for this is BSD licensed) https://github.com/torvalds/linux/blob/master/include/net/codel_impl.h#L80 B) put in a small lookup table (cake uses 16, as that method is inaccurate going up from 1-4, and inaccurate going down in most cases). sch_Cake is BSD/GPL licensed and you are welcome to crib the code from there, also. (I have long dreamed someone would port cake but not today) If I could get someones to attempt to test it fully (there are multiple benchmark suites available), I can help evaluate the results. There are a couple variants of the rest of codel algorithm out there. Thanks! -- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos
