http://mikrotik.moscow Новое в теме Поддержка L4S в RouterOS7 форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Tue, 14 Jul 2026 05:51:57 +0300 Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
@dtaht — Хорошее резюме. Есть какие-нибудь догадки по текущему статусу L4S среди основных участников? Можешь представить реальный сценарий, где BBRv3 сосуществует с fq_codel или L4S? И да, наверное, стоит перейти с внутренних менеджеров очередей на BQL.
31.01.2025 10:27:00, Larsa.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422935 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422935 Fri, 31 Jan 2025 10:27:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Похоже, что широкое внедрение этого скоро станет реальностью. Сегодня узнал о L4S из технических новостей, и после небольшого изучения это выглядит очень многообещающе. Comcast/Xfinity объявили, что начинают его внедрять: https://www.theverge.com/news/601100/comcast-l4s-low-latency-internet. Apple уже несколько месяцев поддерживает эту технологию в своих операционных системах и призывает разработчиков добавить поддержку: https://www.youtube.com/watch?v=y6-Q449DlTQ. Я, в основном, только своим домашним сетевым хозяйством занимаюсь, но думаю, что для WISP это будет полезной функцией (и, разумеется, я тоже захочу, чтобы моя домашняя сеть это поддерживала).
31.01.2025 08:08:00, NReilingh.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422934 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422934 Fri, 31 Jan 2025 08:08:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Итак, да, BQL действительно очень полезен для dualpi в программном обеспечении. BQL — это первый шаг…
01.02.2024 04:00:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422933 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422933 Thu, 01 Feb 2024 04:00:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
В целом, я рекомендую поэкспериментировать с этими концепциями. Скачайте код 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-сигнализации (что, по крайней мере, дает безпотерьную сигнализацию).
01.02.2024 03:53:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422932 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422932 Thu, 01 Feb 2024 03:53:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Согласен со всеми перечисленными функциями и комментариями. Однако я очень хотел бы, чтобы MikroTik ASIC перенёс любые базовые методы простых очередей, такие как pfifo, bfifo, на уровень аппаратного обеспечения. Независимо от того, используется ли fq_Codel или нет, хотя бы простая очередь должна обрабатываться аппаратно уже сегодня. Если это удастся реализовать на стороне BNG, это будет большой успех.
13.12.2023 09:02:00, thenetworks.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422931 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422931 Wed, 13 Dec 2023 09:02:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
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
13.12.2023 05:37:00, DarkNate.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422930 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422930 Wed, 13 Dec 2023 05:37:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Модифицированное использование ECN поддерживает алгоритмы управления перегрузкой, которые избегают задержек из-за очередей у отправителя, тем самым устраняя знакомые вам колебания в отправке пакетов. Но это новая архитектура с сопутствующими проблемами при её внедрении. RFC 9330 достаточно понятен: https://datatracker.ietf.org/doc/rfc9330/
12.12.2023 15:35:00, Brough.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422929 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422929 Tue, 12 Dec 2023 15:35:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
В чём преимущество L4S перед fq_codel и/или CAKE?
12.12.2023 15:03:00, DarkNate.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422928 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422928 Tue, 12 Dec 2023 15:03:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Похоже, что патчи ядра для L4S уже в разработке https://github.com/L4STeam/linux
12.12.2023 11:29:00, pi0.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422927 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422927 Tue, 12 Dec 2023 11:29:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Как добавить голоса? Меня, по крайней мере, очень интересует этот вопрос.
11.12.2023 13:09:00, Brough.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422926 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422926 Mon, 11 Dec 2023 13:09:00 +0300 RouterOS Поддержка L4S в RouterOS7 RouterOS в форуме RouterOS.
Какое у вас отношение к поддержке RouterOS функции очередей с L4S и точной маркировке ECN? Мне это не интересно, меня устраивает текущее предложение (CoDel, CAKE и т.п.) — приятно иметь, но не критично для моей сети. Мне интересно — это обязательно.

0 голосов

Несколько месяцев назад на @IETF вышел набор новых RFC:

RFC9330 Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service Architecture  
RFC9331 The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)  
RFC9332 Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)  
в черновиках: More Accurate Explicit Congestion Notification (ECN) Feedback in TCP

Эти RFC описывают решение, минимизирующее накопление очередей и, следовательно, уменьшающее задержки при перегрузках сети. В основе лежит маркировка ECN и так называемое «двухочередное» связанное активное управление очередями (Dual Coupled AQM), которое позволяет трафику с «низкой задержкой» и масштабируемым контролем перегрузок обходить накопление очередей, характерное для «наследственного» трафика.

Не думайте, что это как DSCP EF или отдельные очереди для низкой задержки — здесь всё про трафик «лучших усилий» по умолчанию. И самая важная особенность этого механизма с двумя ветвями — связь между очередями «наследственного» и L4S трафика: трафик L4S не может захватывать всё соединение и никак не ограничит обычные TCP-потоки. Конкуренция за пропускную способность остается равной (хотя сам TCP не идеален в справедливости распределения).

Очередь для L4S будет очень короткой — всего на несколько миллисекунд пакетов, и если длина очереди достигнет порога, все пакеты будут отмечены, чтобы сигнализировать о перегрузке приёмнику. Приёмник может посчитать, сколько пакетов пришло за определённое время и сколько из них было ECN-маркировано — это не просто сигнал о наличии перегрузки, но и её степень, что позволяет алгоритму управления скоростью реагировать гораздо быстрее и точнее, чем традиционные алгоритмы, основанные на задержках и потерях.

Лучшая реализация доступна бесплатно в виде набора патчей для ядра Linux, так что, вероятно, их можно интегрировать в текущий код.

Почему я считаю это важным? Apple уже поддерживает L4S в iOS17/iPadOS17/macOS14 для TCP и QUIC, и к выпуску этой осенью разработчики смогут включать поддержку L4S в свои приложения просто перекомпилировав их с актуальными инструментами.

Хотя все хвалят низкую задержку L4S, связывая её с AR/VR/ER приложениями, облачными играми или традиционными realtime-протоколами, остальные два «L» (Low Loss и Scalable Throughput) не менее важны.

Мы провели множество экспериментов, сравнивая потоки с L4S и классическими алгоритмами контроля перегрузок, и заметили, что даже нереалтайм трафик выигрывает от L4S: обратная связь ECN — это очень быстрый и точный сигнал, который позволяет отправителю «угадывать» подходящую пропускную способность и скорость, существенно снижая накопление очереди и потери пакетов.

Ключ — масштабируемый контроль перегрузок на стороне отправителя. И самое классное: L4S не нужен по всей цепочке маршрутов, а только там, где вероятна перегрузка, так что поэтапное внедрение вполне реально.

Над воплощением L4S работают и фиксированная, и мобильная индустрия, Cable Labs активно продвигается, а Apple, Google, Meta, Nvidia участвуют в IETF хакатонах.

Считаю, что Mikrotik получил бы огромное преимущество, выпустив RouterOS с поддержкой L4S уже в 2023 году — тогда они оказались бы одними из первых производителей на рынке.

Ссылки на документы:  
https://www.rfc-editor.org/rfc/rfc9330.txt  
https://www.rfc-editor.org/rfc/rfc9331.txt  
https://www.rfc-editor.org/rfc/rfc9332.txt  
https://www.ietf.org/archive/id/draft-ietf-tcpm-accurate-ecn-24.txt
03.07.2023 17:48:00, doneware.]]> http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422925 http://mikrotik.moscow/forum/forum57/88048-podderzhka-l4s-v-routeros7/message422925 Mon, 03 Jul 2023 17:48:00 +0300 RouterOS