Summary

  • Редакция 02 проекта STAMP CoS ECN добавляет EC1 для запроса маркировки ECN на ответном пакете и RPE для сообщения о действиях отражателя. Поле EC2 по-прежнему передаёт значение ECN пакета, пришедшего к отражателю.
  • Отражатель сообщает RPE=0b11, если установил запрошенное значение, и 0b10, если вынужден отправить ноль. Устройство, поддерживающее только RFC 8972, возвращает 0b00 в бывших резервных битах и не выполняет новый тест обратного пути.
  • При нескольких тестах с меткой ECT в течение одного RTT отправитель должен отслеживать CE и иметь возможность снижать объём своих пакетов и вызванных ими ответов.

У STAMP две простые роли. Отправитель посылает тест; отражатель возвращает пакет. При редких проверках такой трафик легко не заметить. При частой автоматической диагностике каждый тест и каждый ответ начинают потреблять пропускную способность именно того пути, состояние которого проверяется. Прибор может правильно измерять перегрузку и одновременно добавлять в неё собственный вклад.

RFC 8972 уже позволял отражателю скопировать ECN полученного тестового пакета в EC2. Отправитель видел состояние маркировки на дальнем конце прямого пути. Для обратного пути не хватало отдельного запроса: с каким ECN должен выйти отражённый пакет и удалось ли отражателю это сделать? Ответ без CE не говорит о поведении сети по отношению к пакету с ECN, если такой пакет вообще не был отправлен назад.

Проект от 2 ноября 2026 года использует бывшие резервные биты. EC1 содержит значение, которое отправитель хочет видеть в исходящем от отражателя IP-пакете. RPE объясняет итог: 0b11 при успешной установке, 0b10, если политика или платформа не позволяют её выполнить и отражатель выставил 0b00. Отправитель также читает реальный IP-заголовок вернувшегося пакета. Так отдельно фиксируются вход у отражателя, его решение на выходе и результат на другом конце.

Совместимость со старой версией встроена в ответ. Отражатель RFC 8972 игнорирует EC1 как резервное поле и возвращает RPE=0b00. Это признак отсутствующей функции. 0b10 сообщает другую причину: функция понятна, но конкретная маркировка не применена. Оператору нужны оба различия. Иначе пустой график CE превращается в красивый вывод об исправном обратном пути без доказательства того, что тестовый пакет имел требуемую отметку.

Далее проект назначает ответственного за скорость. Если отправитель выпускает несколько пакетов с ECT(0) или ECT(1) за один RTT, он должен проверять возвращённое EC2 и уметь снижать темп при CE. Если через EC1 заказаны ответы с ECT, нужно смотреть ECN в заголовке ответов и сокращать вызываемую ими нагрузку. Если дополнительный механизм позволяет запросить несколько отражённых пакетов на один тест, отправитель должен менять параметры будущих запросов. Команду на нагрузку даёт он, даже когда физически ответ посылает отражатель.

Конкретный алгоритм торможения остаётся за реализацией, но должен следовать требованиям RFC 3168 и RFC 9330. Есть и режим намеренного эксперимента: чтобы измерить маркировку при перегрузке, можно держать заданный темп вопреки CE в контролируемой среде по согласию операторов проверяемых сетей, ограничив скорость, длительность и влияние на сторонний трафик. У ежедневного мониторинга такой экспериментальной привилегии нет.

Что находится за цифрой на экране

Сопоставление отправленного ECN с EC2, запроса EC1 с RPE и полученным IP-заголовком выявляет изменение метки. Два конца пути сами по себе не называют промежуточное устройство. Один пакет без CE не описывает все потоки. Доказательство работы конкретной системы — это датированные заголовки обоих направлений, значения полей, частота тестов, число ответов и фактическое уменьшение нагрузки после CE.

Документ пока остаётся действующим проектом рабочей группы IETF. Он задаёт оператору точный вопрос: если тест измерил перегрузку, что тест сделал со своей скоростью? Отсутствие ответа означает, что половина измерительной петли так и не была замкнута.

Проект 02 · RFC 8972 · RFC 8762