[Bug 276890] Getting fq_codel correct on inbound shaping

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276890

            Bug ID: 276890
           Summary: Getting fq_codel correct on inbound shaping
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: dave.taht@gmail.com

Over the years, particularly in the opnsense universe, there has been much
angst and hairpulling with a variety of claims saying that "fq_codel" does not
work properly on inbound shaping, and others that went to the Linux version on
the same hardware, saying that it worked much better.

The paper and code to my eye, looked pretty close to correct, but it was,
indeed, very different than the Linux version, *and* that paper did not test
inbound shaping:
https://www.researchgate.net/publication/322784709_Dummynet_AQM_v02_--_CoDel_FQ-CoDel_PIE_and_FQ-PIE_for_FreeBSD%27s_ipfwdummynet_framework 


So anyway, this reddit thread came up where I concluded there is something
weird about how the freebsd inbound path actually functions in some cases:

https://www.reddit.com/r/opnsense/comments/18z68ec/anyone_who_hasnt_configured_codel_limiters_do_it/

I am not a freebsd developer, and the effort required for me to "get in there"
and test (or worse, patch) is a bit much (I live on a boat nowadays).  What I
would like is to find someone that can run 3 simple tests on my behalf, and
give me the packet captures, so I can verify correctness. Ideally driving more
complex tests through flent to my cloud would be great, but I would settle for,
at some RTT (ideally 10-40ms - not LOCAL[1] - ideally over a GPON fiber network
to the cloud) is the following test:

Setup inbound shaping at 100Mbit, 300mbit, and 800mbit. (on a link capable of
those speeds, and on x86 or arm hardware also capable)

Run iperf or netperf for 1 minute on a tcp download while capturing
tcpdump -i the_interface -s 128 -w 100mbit.cap (etc)

And send me the capture, please?  [2]

There are plenty of reasons why inbound shaping can have problems, like
batchyness or timing outside of the fq_codel implementation, and people set
their expectations too high for it (particularly against torrent), and I have
tried (with libreqos, etc) to make egress shaping far more the default across
the internet. But I should be able to verify basic correctness with just those
three captures. [3]

Bonus points would be enabling RFC3168 style ECN across the test (which shows
up really nicely in a packet cap) and capturing from the server, rather than
client. 

Thanks for any help you can offer. 

[1] Longer RTTs engage the AQM component of fq_codel more visibly
[2] Or plot yourself with wireshark and/or xplot.org
[3] and gain a reference plot for future work, if needed 

PS The openbsd version of fq_codel is *definately* broken, but codebase
entirely different. It caps the "count" (drop) variable to 400 when it should
run freely. Working on fixing that too.

-- 
You are receiving this mail because:
You are the assignee for the bug.