Summary
- RFC 9599 описывает перенос явного сигнала перегрузки из нижнего кадра или внешнего заголовка туннеля в IP до удаления этого заголовка.
- Наблюдаемое на выходе
CEподтверждает состояние конкретного заголовка в точке наблюдения. Оно само по себе не называет маркировавшую очередь и не доказывает отчёт получателя или снижение нагрузки отправителем.
Пакет выходит из туннеля с CE. Это достоверное измерение. Фраза «перегружен был именно этот туннель» уже требует доказательной цепочки.
Метка могла присутствовать во внутреннем заголовке до инкапсуляции. Её могла добавить очередь второго уровня. Декапсулятор мог объединить два состояния и сохранить более строгое. Переформирование кадров могло перенести событие на чуть более поздний IP-пакет. Если семантика зависела от DSCP, граница домена могла сохранить биты, но изменить контекст их толкования.
RFC 9599 опубликован в августе 2024 года как часть BCP 89. Документ решает задачу сохранения сигнала. Потеря кадра автоматически означает потерю внутреннего пакета. Маркировка нижнего заголовка исчезает при его снятии, если выход явно не перенесёт её наверх.
Поэтому декапсулятор входит в контур обратной связи. Поддержки ECN на транспортных концах недостаточно. Все функции, необходимые для возврата сигнала регулятору нагрузки, должны уметь его передать. ECN-PDU — свойство всего контура, а не только видимых битов. Способность может задаваться заголовком, меткой, состоянием потока, конфигурацией или контекстом плоскости управления.
RFC различает четыре режима. Feed-forward-and-up ведёт сигнал к выходу нижнего уровня, поднимает его в IP и возвращает от назначения к источнику. Feed-up-and-forward позволяет нижнему устройству маркировать вложенный IP-заголовок напрямую. Feed-backward отправляет управление ко входу подсети. Null предполагает отсутствие самостоятельного места перегрузки внутри нижней ткани.
Feed-backward способен регулировать закрытую подсеть, но не обращается напрямую к исходному IP-источнику. Вход снижает темп, источник продолжает передачу, и очередь смещается к границе. Управляющее сообщение на входе не подтверждает реакцию исходного приложения.
Feed-up-and-forward ограничен видимостью. Шифрование, неизвестный shim или глубокая вложенность могут скрыть IP-заголовок. RFC требует ограничить поиск и перейти к безопасному сигналу, например к сбросу. Отсутствие маркировки может означать невозможность проверки, а не отсутствие перегрузки.
В feed-forward-and-up вход должен знать, что выход не уничтожит сигнал. MPLS может обеспечить это согласованной конфигурацией домена. TRILL использует безопасный отказ: старый выход, не понимающий критическую отметку, сбрасывает кадр вместо бесшумного удаления предупреждения.
Выход не должен слепо копировать внешнее поле. Он вычисляет результат по внутреннему и внешнему состояниям. Если внутри Not-ECT, а снаружи самая строгая индикация, пакет следует отбросить: транспорт не обещал читать CE. При двух допустимых уровнях сохраняется более строгий. Неожиданное сочетание требует журнала и политики, но не всегда вечного жёсткого сброса.
Входу также не следует обнулять накопленную историю. Сохранение уровня во внешнем заголовке позволяет по агрегированной разнице оценить перегрузку, добавленную на участке.
Оценка не является паспортом происхождения отдельного пакета. Нужны сопоставимые совокупности, известный sampling и одинаковые правила границ. При переформировании сохранение времени и сохранение доли маркировок — разные цели. Конвейер может перенести сигнал на следующий пакет.
Два бита не имеют единого смысла вне контекста. Классический ECN, PCN и L4S могут по-разному использовать ECT(0), ECT(1) и CE; иногда толкование связано с DSCP. Копирование битов после смены DSCP не гарантирует сохранения значения.
Есть и граница целостности. Поле, которое законно меняют транзитные узлы, должно быть объявлено изменяемым; иначе правильная маркировка нарушит аутентификацию якобы неизменного заголовка. Даже обратная связь получателя не доказывает, что отправитель снизил скорость. Получение и действие — разные факты.
Надёжная приёмка сохраняет внутренние ECN и DSCP на входе, правило инкапсуляции, идентичность туннеля, способность выхода, конфигурацию AQM, оба состояния при декапсуляции, пересылку или сброс, обратную связь, её получение отправителем и измеренное изменение скорости либо очереди.
RFC 9599 делает сигнал переносимым. Переносимость не создаёт происхождение. Метка остаётся доказательством, а источник, сохранность, смысл и эффект требуют дополнительных квитанций.
Sources
- RFC 9599
- Запись Datatracker
- Errata RFC 9599
- RFC 3168: ECN в IP
- RFC 6040: ECN в туннелях
- RFC 5129: маркировка MPLS
- RFC 7141: байтовые и пакетные уведомления
- RFC 7713: ConEx
- RFC 8087: преимущества ECN
- RFC 3819: рекомендации для подсетей
- RFC 8311: эксперименты ECN
- RFC 7567: рекомендации AQM
- RFC 4774: альтернативная семантика ECN
- RFC 9331: архитектура L4S
- RFC 9600: ECN в TRILL
- RFC 9601: ECN в IP-туннелях с shim
- Heng Lu: уровни реальности
- Heng Lu: первичность работающего кода
- Heng Lu: реальность, а не адвокация
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

