Кратко

  • В DualQ по RFC 9332 раздельные очереди L4S и Classic сочетаются со связанными сигналами перегрузки. ECT(1) и, в соответствующих условиях, CE обозначают L4S, но не являются журналом фактической очереди, решения AQM или времени ожидания.
  • Оператор вправе направить пакет с идентификатором L4S в очередь Classic, не стирая сквозную метку. Он также может допустить выбранный не-L4S-трафик в L, не превращая его ECN-идентификатор в L4S.
  • Koen De Schepper, Bob Briscoe, выступивший также редактором, и Greg White назвали недостающие эксплуатационные свидетельства: трафик, маркировки, сбросы, среднюю задержку, 99-й процентиль и эпизоды перегрузки для каждой очереди.

Метка не меняется, а режим уже другой

На границе сети наблюдается ECT(1). До перегрузки пакет попадает в L и быстро выходит. Во время перегрузки та же метка может встретить насыщение ECN-сигнала и дополнительный сброс. После события она снова читается так же. Если журнал хранит только идентификатор, три разных режима превращаются в одну строку.

ECT(1) сообщает узлу, понимающему L4S, о протокольном выборе отправителя. В нём нет версий классификаторов, локальных правил, названий очередей, решений Active Queue Management, пройденных узких мест и времени ожидания. Два бита не могут быть историей маршрута.

RFC 9332 была опубликована в январе 2023 года в категории Experimental. Она описывает Dual-Queue Coupled AQM: очередь L для обработки L4S, очередь C для Classic, отдельный AQM на каждой стороне и механизм связи сигналов перегрузки. Планировщик даёт L приоритет, но ограничивает его, чтобы C не голодала. Очень малая очередь — цель механизма, а не факт, автоматически удостоверенный ECT(1).

Локальное исключение не отменяет сквозную идентичность

RFC 9331 определяет ECT(1), а в нужном контексте и CE, как идентификатор L4S. Отправитель должен применять подходящее масштабируемое управление перегрузкой. Узел L4S обычно классифицирует такой пакет в L.

Слово «обычно» сохраняет полномочия оператора. RFC 9332 допускает, что по локальной политике отдельные пакеты L4S выводятся из L. При этом узел не должен переписывать сквозной идентификатор. Следующий оператор должен видеть исходное заявление и принимать собственное решение.

Поэтому запись обнаружен ECT(1); на узле X сработало правило Y; выбрана C; идентификатор сохранён внутренне согласована. Идентичность исходит от конечной системы, обработка — от конкретного оператора.

Возможен и обратный случай. Адреса, Diffserv-кодовые точки или протоколы вроде DNS могут служить дополнительными признаками для допуска в L, если это не вредит сервису. Но локальная привилегия не позволяет менять Not-ECT или ECT(0) на ECT(1). Очередь L не создаёт идентичность L4S, а идентичность L4S не доказывает очередь L на каждом участке.

DualQ связывает контуры управления

Это не просто две полосы разных цветов. Classic-алгоритмам нередко нужен некоторый объём данных в очереди для полного использования канала. Scalable-алгоритмы могут отвечать на частые ECN-сигналы небольшими изменениями скорости. Без защиты Scalable-поток окажется намного агрессивнее Reno-совместимого.

DualQ разделяет задержку и связывает давление перегрузки. В объяснении RFC Classic AQM создаёт базовую вероятность. Её квадрат используется для маркировки или сброса Classic, а масштабированное значение становится связанным сигналом для L. L-AQM выбирает более сильный из собственного сигнала, обусловленного мгновенной задержкой, и давления, пришедшего из C.

Следовательно, CE — не замер времени. Марка может отражать динамику самой L, связанное давление C или перегрузочный режим. Её задача — заставить конечную систему изменить скорость. Время ожидания конкретного пакета измеряется отдельно.

Несовпадения особенно нуждаются в журнале ветвления. Для ECT(1) в C Classic AQM должен использовать связанную вероятность. ECT(0) в L требует обращения, подходящего и для Classic-контроля, и для целевой задержки L. Обработка Not-ECT в L зависит от наличия защиты против неотзывчивых потоков. Счётчик ECT(1) не показывает, какая ветвь сработала.

У низкой задержки несколько часов

Даже достоверная запись L доказывает только одну часть пользовательского опыта. RFC 9332 исключает из queue delay сериализацию пакета в голове очереди и получение доступа к среде. Туда не входят распространение, другие узлы, восстановление транспорта, планирование сервера и работа приложения.

Пакет может провести микросекунды в DualQ и завершить медленный запрос. Короткий Classic-пакет может быстро пройти пустую C и не стать L4S. Время очереди, сквозной RTT и отклик приложения должны оставаться разными рядами.

Среднего значения тоже недостаточно. Экспериментальная реализация должна позволять получать среднее и 99-й процентиль по каждой очереди и интервалу; максимум полезен для диагностики. Низкое среднее скрывает тяжёлый хвост. Максимум без окна превращает старую аномалию в вечный статус. Нужны название статистики, интервал, знаменатель и место наблюдения.

Одна DualQ на доступе не удостоверяет весь путь. Другая точка перегрузки, Wi-Fi-планировщик, туннель, вышестоящий интерфейс или сервер могут определять результат. «Путь L4S» — распределённое утверждение.

Сто процентов маркировки — не бесконечный сигнал

При обычной отзывчивой нагрузке связь должна сохранять мелкую L, не лишая Classic обслуживания. Приоритет L не может быть безусловным: постоянно занятая L способна задержать даже DNS-запрос или начальное окно в C.

Устойчивое переполнение достигает предела. После 100-процентной ECN-маркировки добавить более сильный сигнал той же маркой невозможно. RFC 9332 требует от DualQ с обнаружением перегрузки вводить Classic-сброс для обоих типов ECN-трафика, пока событие не закончится. Следует также сообщать начало и продолжительность с гистерезисом, чтобы не создавать шквал событий.

ECT(1) при этом остаётся прежним, хотя вероятность сброса и задержка меняются. Достоверная панель должна показать временную перегрузочную фазу, а не бессрочный значок L4S.

Точная граница коллективного труда

RFC 9332 подписали Koen De Schepper, Bob Briscoe и Greg White; Briscoe также указан как редактор. Разделы благодарностей и вкладов показывают ещё более широкое сообщество. Документ не поддерживает историю одинокого изобретателя и не даёт оснований приписывать Briscoe решения конкретного оператора.

Сохранённый для статьи профиль IETF Datatracker документирует его многолетнюю работу над ECN, управлением перегрузкой и транспортом. Официальный личный сайт даёт публичную биографию и источник портрета. Они подтверждают человека и документированный вклад, а не текущую долю внедрения или поведение определённой сети.

Значима проведённая граница: общий идентификатор остаётся малым и совместимым, локальное решение остаётся у обладателя контекста, а реализация измеряет всё, чего бит сказать не может. Это близко к Minimum Initial Specification Хэна Лу. Running-Code Primacy добавляет правило доказательства: RFC и настройка показывают доступность механизма, исполнение — реально выбранную ветвь.

Проблема принципала и агента появляется, когда самый дешёвый факт получает самое широкое обещание. Поставщику легко показать число ECT(1). Оператору дороже экспортировать версии правил, покомпонентные счётчики и хвост задержки. Риск несёт клиент. Если закупке достаточно «L4S включён», субъект с наименьшим объёмом доказательств получает наибольшую власть над формулировкой.

Шесть квитанций вместо одного значка

Квитанция отправителя содержит транспорт, реализацию и версию управления перегрузкой, решение выставить ECT(1), границу потока и время. Пограничная квитанция хранит ECN, инкапсуляцию, интерфейс, направление, метку времени и целостность захвата.

Классификатор фиксирует устройство, ПО, редакцию политики, совпавшее правило, дополнительные признаки и результат L/C. Очередь фиксирует экземпляр AQM, вход и выход, выбор планировщика и ветвь для неожиданной комбинации.

Квитанция перегрузки связывает собственное и сопряжённое давление с CE, ECN- и не-ECN-сбросами, началом и концом перегрузки, числами прибывших, поданных в AQM и переданных пакетов. Квитанция результата хранит загрузку, среднее, p99, необязательный максимум, интервал и гистограмму по каждой очереди. RTT и приложение измеряются отдельно.

Эти свидетельства не опровергают L4S. Они оставляют идентификатору ровно его полномочие — сообщить протокольную идентичность, не выдавая её за наблюдение обработки и результата.

Источники