Истории про fq_codel/CAKE?

Ты совершенно прав, что иногда сам интернет выдаёт сбои. Я всё ещё надеюсь, что fq_codel и cake появятся на большем числе магистральных каналов, но где-то всегда будет какой-то глюк. Чтобы понять, действительно ли cake или fq_codel приносят пользу, можно посмотреть статистику потерь пакетов за какое-то время — это хороший индикатор. Но когда я последний раз проверял, у Mikrotik таких данных не было. Можешь проверить ещё раз?

Не рискую ли я, полагая, что мой самый удалённый часто используемый CDN находится менее чем в 30 мс, и что последствия ошибочного прогноза иногда незначительны? Однако ack-фильтр на приёме практически бесполезен и жрёт процессор. В вашей среде он нужен только на передаче. Интересное наблюдение, спасибо. Я не просто убрал эту бесполезную часть из конфигурации, но и добавил такой абзац: «Мы делаем это только на стороне cake-tx, потому что в типичных случаях можем контролировать только то, что отправляем на удалённые TCP/IP стеки, а не то, что они делают в ответ. Есть исключения, например, при site-to-site туннеле WireGuard, но даже там фильтрация ACK наиболее эффективна с узкой стороны асимметричного канала. Поэтому лучшая стратегия — применять фильтрацию ACK только на стороне передачи каждого пира, улучшая таким образом очередь приёма на удалённом узле издалека.»

Учитывая, что моя конфигурация подаёт два CAKE-очереди в простую очередь, где применяется максимальное ограничение, я бы сказал: «Да». Но почему бы не попробовать и не убедиться самому? Твой симметричный канал не исключает эксперименты. Если у тебя 1G/1G, попробуй 900M/800M и посмотри, в какую сторону у тебя окажется «липкая палочка» (то есть где возникнут проблемы). Я пришёл к такому выводу после того, как попробовал это у себя и был озадачен поведением, а потом придумал объяснение, которое привёл выше.

Я обнаружил то же самое: значения rx/tx в simple queue перепутаны по сравнению с ожидаемым поведением: RX — это загрузка целевого интерфейса, а TX — скачивание целевого интерфейса. Конфигурация ниже хорошо работает на кабельных соединениях 1000/100 Мбит с пользователями, которые жаловались на проблемы с загрузкой или скачиванием большого количества и/или крупных файлов, что мешало параллельным звонкам в Teams/Zoom и т. п.

Очередь rx besteffort ограничивает входящий WAN-трафик незадолго до того, как вступает в действие шейпер у провайдера. Это, как показало время, меньше влияет на задержки. Очередь tx diffserv4 отлично приоритизирует исходящий трафик Teams/Zoom, если аплинк загружен полностью. По крайней мере, жалобы прекратились.

/queue type  
add cake-diffserv=diffserv4 cake-flowmode=dual-srchost cake-nat=yes kind=cake name=cake-WAN-tx  
add cake-diffserv=besteffort cake-flowmode=dual-dsthost cake-nat=yes kind=cake name=cake-WAN-rx  

/queue simple  
add comment="RX= Загрузка цели TX = Скачивание цели" max-limit=950M/95M name=cake-WAN queue=cake-WAN-rx/cake-WAN-tx target=bridge1_WAN

Потери пакетов не считаются при использовании cake или fq_codel. Не стесняйтесь доставать тик по этому поводу от моего имени. Мне всё ещё интересно узнать причину, по которой был переопределён режим потока по умолчанию.

Да, шансы ошибиться время от времени очень малы. Особенно при входном формировании трафика лучше использовать ваше типичное RTT в качестве оценки, чтобы контролировать очередь до того, как она попадёт в шейпер провайдера, который вы пытаетесь обойти. Алгоритм codel был разработан с расчётом на мировые RTT (280 мс) с настройками по умолчанию: target 5 мс, interval 100. Он также рассчитан так, что один TCP-поток может использовать почти всю пропускную способность, если RTT находится в этом диапазоне. Сегодня наиболее типичные сценарии — это примерно 15 коротких потоков из браузера, 5 и более из торрент-клиента, а вообще интерактивные потоки, такие как voip и видеоконференции, потребляют так мало трафика, что у них практически никогда не возникает потерь. При большом количестве потоков и/или небольших RTT codel на самом деле недостаточно отзывчив.

Случай, когда использование регионального RTT может навредить (30 мс interval, 1.5 мс target) — это когда передача одного пакета занимает больше времени, чем его «подгонка» под пропускную способность. При 10 Мбит один пакет помещается примерно за 1.3 мс. После появления codel системы на базе Linux начали использовать packet pacing, который работает лучше как на коротких, так и на длинных расстояниях. Правда, у меня нет реальных бенчмарков по этому поводу.

В общем, если вы не передаёте большой объём данных через один поток на расстоянии дальше 100 мс с пропускной способностью выше 10 Мбит/с, региональная настройка должна быть в порядке.

… «Мы делаем это только с cake-tx, если у нас сочетается соотношение загрузки и отдачи больше 10:1, на узкой стороне асимметричного канала, когда подтверждения (acks) от одного TCP-потока могут полностью загрузить аплоад. Фильтрация подтверждений не помогает при зашифрованном трафике — например, в site-to-site туннеле WireGuard. Подтверждения почти никогда не ставятся в очередь на стороне приёма, фильтровать там бессмысленно.»

Я поигрался с rrul некоторое время назад. Точные настройки не помню, наверное, была простая очередь на моём подключении 100 DL / 20 UL с лимитами 95 DL / 15 UL. Что мне показалось крутым — так это то, как чётко видно diffserv4 в действии. Сейчас я запускаю CAKE на дереве очередей с включённым fasttrack и для ipv4, и для ipv6 (тестирую 7.18beta). Раньше fasttrack был отключён, и я классифицировал трафик с помощью правил mangle и меток dscp для diffserv, но я не до конца доверяю своим навыкам mangle, чтобы оставлять такую настройку. Без очередей:  
 
fq_codel:  
 
CAKE dual-src/dsthost diffserv4 nat internet: