Поддержка L4S в RouterOS7

Как добавить голоса? Меня, по крайней мере, очень интересует этот вопрос.

В чём преимущество L4S перед fq_codel и/или CAKE?

FQ_Codel поддерживает и переключение бита ECN. Я не вижу, как L4S может быть полезен для: магистральных оптоволоконных сетей PON-оптоволоконных сетей или даже LTE/5G.

Если уж на то пошло, кажется, что L4S продвигают старые компании, работающие с коаксиальным кабелем, которые отказываются переходить на оптоволокно.

Мне бы хотелось, чтобы MikroTik позволил offloading fq_codel на ASIC — это бы стало революцией и эволюцией для отрасли, ведь сейчас даже Cisco, Juniper, Huawei и Nokia не поддерживают fq_codel на ASIC.

Даже забывая про ASIC, MikroTik сначала надо добавить это, прежде чем говорить об алгоритмах: https://blog.linuxplumbersconf.org/2011/ocw/sessions/171

В целом, я рекомендую поэкспериментировать с этими концепциями. Скачайте код L4S — попробуйте его на своих домашних машинах! Но пару фактов, постараюсь быть беспристрастным.

Для протокола, я изначально поддерживал версию этой идеи, совместимую с RFC3168, называемую SCE, на IETF, но потом отказался даже от неё, когда «красная команда» показала, что особенно L4S вновь вводит сильную несправедливость по RTT, тогда как в fq_codel мы, как правило, добиваемся одинаковой пропускной способности независимо от того, близко или далеко конечное устройство.

Diffserv-функции в cake я также счёл достаточными для большинства игровых потребностей. Ирония в том, что другой компонент L4S — новый NQB кодпоинт — не может быть послан с платформ Windows, которые поддерживают только CS7, CS5 и CS1 (voice/video/background), а cake эти метки уже поддерживает. Планирую добавить поддержку NQB в cake со временем...

Дизайн L4S настойчиво пытается поставить себя в приоритет над всеми остальными типами трафика и создаёт проблемы с обратной совместимостью в интернете. Документ, который пытается это описать и который, возможно, никогда не станет официальным RFC, но крайне необходим для операторов, желающих внедрить L4S, доступен здесь: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4sops/

Решение вопроса, улучшат ли методы L4S облачные игры или нет, пока открыто. Важный момент — битовые манипуляции и NQB кодпоинт ставят пакеты в конкретную очередь DOCSIS-LL с улучшенным интервалом запрос/выдача, что делает кабель почти конкурентоспособным с оптикой (уменьшает r/g интервал примерно с 10 мс до 1 мс). Очень хотелось бы, чтобы специалисты по DOCSIS просто внедрили этот улучшенный интервал, нежели пытаться разделять трафик таким способом. GPON и беспроводные сети уже обычно работают с задержками меньше 1 мс.

fq_codel в Linux 6.1 уже поддерживает L4S. Это всего два простых патча, которые можно обратно портировать, если интересно. В настоящий момент ce_threshold около 2–2.5 мс кажется оптимальным на основе опубликованных тестов. Возможно, на виртуальных инстансах это по-другому — тут я точно не скажу, может быть, 8 мс? Не цитируйте меня.

L4S изначально задумывался больше для аппаратной реализации, чем программной. Частичная реализация в железе возможна, если можно А) дифференцировать трафик по ECN битам и Б) настроить RED в жёстком режиме. Я не видел много устройств, способных на пункт А). Если пункт Б) выполнен, но нет возможности применять AQM или fq_codel к обычной очереди, получается FIFO для обычного трафика.

Что совсем неясно во всей рекламе L4S — это то, что в реальной жизни для обычного трафика, такого как веб, VoIP, игры и т. д., производительность оставляет желать лучшего по сравнению с fq_codel или cake, потому что обычный трафик там и понижен в приоритете, и использует одну очередь PIE AQM.

Так что если обновить ваш транспорт и обновить промежуточные маршрутизаторы на пути, то можно получить хотя бы часть обещанных преимуществ, но это непростая задача. Иначе это шаг назад по сравнению с fq_codel или cake, которые работают со всеми современными контроллерами перегрузок (Reno, cubic, ledbat и прочими). PIE — это шаг вперёд по сравнению с FIFO, но посмотрите: http://burntchrome.blogspot.com/2014/05/i-dont-like-this-pie-more-bufferbloat.html

Весь L4S код для Linux (транспорты и AQM) находится вне основного ядра Linux, доступен только для версии 5.15, и есть серьёзные препятствия для внедрения. Особенно меняют дело то, что код, который я смотрел два—три года назад, не поддерживает GRO/TSO/GSO. К тому же dualpi AQM работает в однопоточном режиме, чтобы вообще функционировать — например, не масштабируется нормально на многоядерных процессорах. По моему мнению, это фатальные недостатки.

Концепция транспорта DCTCP (хотя, может, не BBRv3) просто не сможет работать с Wi-Fi до версии 7.

Было много других проблем — «красная» (SCE) команда выложила код, чтобы показать, как люди пытались её реализовать: https://github.com/heistp/l4s-tests?tab=readme-ov-file#elaboration-on-key-findings

С тех пор появились улучшения. Исследования продолжаются. Недавно меня порадовал прогресс в работе с субоконными пакетами. Я бы очень хотел, чтобы сторонники и противники сравнили по производительности fq_codel и dualpi на аппаратуре, на которой они работают.

Поскольку сейчас я в основном занят Linux 6.8, жду поступления этого кода в основную ветку Linux и полноценного обзора, прежде чем возьмусь за него. Ни за что не стал бы отправлять это в промышленный продукт, пока код не пройдет более тщательное ревью.

Транспорты, использующие L4S, вроде apple transport, будут по-другому использовать ECN, чем RFC3168. Но fq_codel в текущем состоянии, без патчей, в конечном итоге тоже изменит ECN-биты и обеспечит какую-то безпотерьную сигнализацию.

Лично моё предположение — если L4S всё же приживётся, учитывая огромную проблему обратной совместимости с RFC3168, то более правильным решением станет BBRv3 вместе с установкой ce_threshold в fq_codel для L4S-сигнализации (что, по крайней мере, дает безпотерьную сигнализацию).

Похоже, что широкое внедрение этого скоро станет реальностью. Сегодня узнал о L4S из технических новостей, и после небольшого изучения это выглядит очень многообещающе. Comcast/Xfinity объявили, что начинают его внедрять: https://www.theverge.com/news/601100/comcast-l4s-low-latency-internet. Apple уже несколько месяцев поддерживает эту технологию в своих операционных системах и призывает разработчиков добавить поддержку: https://www.youtube.com/watch?v=y6-Q449DlTQ. Я, в основном, только своим домашним сетевым хозяйством занимаюсь, но думаю, что для WISP это будет полезной функцией (и, разумеется, я тоже захочу, чтобы моя домашняя сеть это поддерживала).