Кратко

  • RFC 9768 оставляет получателю роль универсального механического отражателя ECN, а выбор алгоритма реакции — отправителю данных.
  • Обязательный ACE имеет три бита и быстро переполняется; опциональные 24-битные счётчики байтов подробнее, но зависят от TCP-опций и поведения пути.
  • Эксплуатационный вывод должен хранить переговоры, единицы, пропуски ACK, гипотезы переполнения, сверку каналов и локальное решение отправителя отдельно.

Когда подробный канал исчезает

Классический ECN для TCP возвращает не больше одного сигнала за RTT, даже если CE получили несколько пакетов. Для реакций на долю маркировки этого недостаточно. RFC 9768, опубликованный в апреле 2026 года как Standards Track, обновляет обратную связь и переговоры RFC 3168 механизмом AccECN.

Получатель считает codepoint на допустимых TCP-сегментах и повторяет состояние. Отправитель знает, какие ECT-значения он установил, сопоставляет историю и выбирает ответ. Сам RFC не определяет алгоритм управления перегрузкой. Поэтому получатель назван универсальным механическим отражателем: новые алгоритмы отправителя могут использовать прежний формат без передачи получателю новой политики.

ACE остаётся в фиксированном заголовке

AccECN Counter использует три TCP-флага ECN и передаёт младшие три бита счётчика CE-пакетов. Повторение текущего значения позволяет восстановиться после одиночной потери ACK. Но восемь состояний быстро замыкаются в круг.

Переход от шести к одному даёт минимальный прирост три, но длинная пауза может скрыть ещё восемь или шестнадцать отметок. Задержка, фильтрация и перестановка ACK меняют доступную историю. RFC требует достаточно частой обратной связи и даёт более строгие рекомендации для неподтверждённых данных. При отсутствии опции отправитель обязан сохранить консервативную гипотезу, а не выдавать минимум за точное значение.

ACE учитывает допустимые CE-пакеты TCP, включая управляющие и повторно переданные, кроме SYN. Это не уникальные байты приложения. Сравнение ACE с полезным трафиком без поправки на единицы неизбежно вводит в заблуждение.

Три 24-битные книги

Опция AccECN переносит младшие 24 бита счётчиков payload, принятого с CE, ECT(0) и ECT(1). Заголовки не считаются, а повторно переданный payload считается снова. Полный незаметный оборот такого счётчика за реалистичную паузу ACK маловероятен.

Однако этот канал занимает дефицитное пространство TCP-опций. Если минимальная опция AccECN не помещается рядом с двумя блоками SACK, приоритет получает SACK. Посредник может удалить неизвестную опцию, proxy — разделить соединение, GRO/LRO — сгруппировать пакеты до наблюдения. Доступность может меняться в середине сеанса.

Значит, байтовые книги дополняют ACE, но не заменяют его. Обязательный канал грубее и устойчивее; дополнительный подробнее и условен. Отправитель держит базовые значения и сверяет модульные разности, помня о разных единицах.

Переговоры не сводятся к флагу «включено»

Комбинации AE, CWR и ECE в трёхстороннем рукопожатии согласуют AccECN и позволяют откатиться к классическому ECN или режиму без ECN. В первом SYN слишком мало места, поэтому сама опция проверяется в SYN/ACK и первом ACK. Успешные переговоры AccECN не гарантируют прохождения 24-битных счётчиков.

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

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

Сверка до объяснения причины

Если байты CE растут, а пакетный счётчик не может им соответствовать, отправитель проверяет повторные передачи, единицы, потери ACK, оборот, исчезновение опции и изменение пути. Если законного объяснения нет, он может отключить ECT для этой половины соединения. Это локальная защита, а не установление виновного устройства.

CE доказывает codepoint на принятом пакете. Он не сообщает длину очереди, порог маркировки, оператора или ущерб приложению. И не предписывает одну реакцию: DCTCP, CUBIC и масштабируемые схемы работают по-разному.

Операционный чек хранит по каждому направлению: флаги переговоров, отправленные и принятые ECN, последовательность ACE и дельты, базы трёх байтовых счётчиков, форму и доступность опции, пропуски и порядок ACK, давление SACK, повторы, offload, proxy, результат сверки, решение по ECT и алгоритм отправителя. Данные очереди, пропускной способности и приложения остаются отдельным слоем.

Испытания должны терять отдельные и серии ACK, скрывать полный оборот, переставлять первый ACK, удалять опцию после старта, теснить её SACK, обнулять флаги и менять ECN асимметрично. Правильная система может потерять точность, но должна показать это явно и не создавать уверенность из отсутствующих данных.

Источники