Включил FQ-CoDel. PIE, CAKE...

https://www.youtube.com/watch?v=y5KPryOHwk8
https://www.bufferbloat.net/projects/
https://en.wikipedia.org/wiki/CoDel
https://datatracker.ietf.org/doc/html/rfc7567
https://datatracker.ietf.org/doc/html/rfc8290
https://habr.com/ru/articles/194274/
https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4
https://news.ycombinator.com/item?id=11516372
Traffic shaper я прежде использовал только для ограничения пропускной
способности того или иного трафика. Уже не помню как, но вышел на тему
связанную с AQM -- Active Queue Management. ECN (Explicit Congestion
Notification), который у меня включён, по идее работать должен только
при использовании AQM, ибо именно он должен оповещать о возникающих
задержках. Но AQM и без ECN должен быть полезен.

Увидел много упоминаний положительных о FQ-CoDel (FlowQueue-Controlled
Delay) алгоритме, который относительно недавно был добавлен в FreeBSD.
Пишут что без каких-либо настроек он резко улучшает usability и user
experience в сети при забитых каналах. Подтверждаю: при забитом на выход
BitTorrent-ом канале, ssh до VPS-ки теперь идёт как маслу, не замечаю
разницы между 10GbE соединением с шлюзом и забитым 100Mbps каналом в
Интернет.

Читаешь форумы, где говорят что невообразимая по полезности магия
происходит только включив (FQ-)CoDel -- и действительно визуально оно
ощутимо меняет поведение. iperf3 на 10GbE вроде бы не мешает, не замечаю
ощутимо большего использования CPU.

Хотя, как всегда, не совсем уверен
(f8e2e4dfc6870c4dad7e62be9bb02ae9dd73d180) в корректности настройки
firewall-а, но добавлял count log правила чтобы точно понимать попадает
ли под правило нужный мне трафик или нет.

Но для работы ECN нужна поддержка и от TCP. А у меня BBR
(e454488d86353680fdc8300a1567011572953e27), который не ECN-friendly.
BBRv2 дружелюбен к нему, но его нет в FreeBSD. На BitTorrent машине
временно включил CUBIC и статистика по ECN пошла:

    # netstat -s | grep ECN
        0 packets with ECN CE bit set
        295108 packets with ECN ECT(0) bit set
        177 packets with ECN ECT(1) bit set
        3525 successful ECN handshakes
        8 times ECN reduced the congestion window

Ещё я догадался проверить iperf3 свои 10GbE соединения после этого. И на
BBR с двумя параллельными соединениями он и до 5Gbps не вытягивает. А на
родном FreeBSD стэке (с CUBIC-ом вместо New Reno) спокойно все 10 выдаёт.
Конечно, один алгоритм для 10GbE LAN и загруженного 100Mbps Интернета не
может подойти одинаково хорошо, но пока от BBR откажусь.

IPv4 трафик, который в основном BitTorrent, который и забивает весь
исходящий канал, у меня идёт в gif-туннеле поверх IPv6 динамически
маршрутизируемых пакетов (a1251840ec6cc11b80519ae8a4f519f54c4358b9).
Чтобы ECN биты копировались из IPv4 заголовков в IPv6-ые, то надо сделать:
    ifconfig gif_XXX link1
Но это только для внутренних туннелей годится. gif-ы с Hurricane
Electric и IP4Market (fb6dc9b409ae5051b610950dae0eaf4c70061437) не
поддерживают этой фишки, ибо она не по RFC.

А ещё бывают AQM-ы с красивым названиями типа:
PIE (Proportional Integral controller Enhanced) и
CAKE (Common Applications Kept Enhanced).

Первая ссылка -- видео поясняющее принципы AQM-а. Лектор здорово
подготовился ко всему этому представлению. Даже для RED алгоритма
использовал соответствующий цвет жидкости.

А в комментарии на HackerNews, пишут что в OpenBSD выпилили ECN, всё мол
плохо. Но это 2016-ый год. В его исходниках вижу, что и CoDel есть и ECN
вроде бы обрабатывается в TCP.