Кратко

  • В классической RFC 3168 получатель после CE продолжает ставить ECE в подтверждениях, пока не получит новый сегмент данных с CWR.
  • Поэтому одна метка CE может дать много ACK с ECE: они удерживают надёжное состояние обратной связи, а не обозначают независимые события.
  • При установлении соединения те же флаги согласуют поддержку ECN; туннели и последующие эксперименты ещё сильнее ограничивают выводы из сырого количества.

Повторение сохраняет уведомление

Десять ACK с ECE в трассе — это десять наблюдаемых пакетов. Превращение их в десять случаев перегрузки уже требует допущения, которого в протоколе нет. В фазе установившейся передачи получатель, увидев Congestion Experienced на пакете данных, устанавливает ECE в подтверждении. Если отложенный ACK охватывает несколько сегментов и хотя бы один имел CE, такой ACK тоже несёт ECE.

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

Такой механизм выдерживает потерю ACK. Если бы эхо отправлялось единожды, случайная потеря обратного пакета уничтожила бы уведомление. Повторение оставляет следующую возможность доставки. Поэтому полезная единица наблюдения — интервал, который открывает CE, поддерживает серия ECE и закрывает CWR.

CWR закрывает состояние, а не пересчитывает пакеты

В классическом алгоритме отправитель принимает ECE как сигнал перегрузки и уменьшает окно примерно так же, как при признаке потери. Однако каждый повторный ACK не должен вызывать новое уменьшение. Для серии потерь или CE внутри одного окна данных, то есть приблизительно за время одного кругового прохода, окно сокращается один раз.

После реакции отправитель ставит CWR на первый новый пакет данных. RFC 3168 рекомендует не использовать для ответа повторно передаваемый сегмент. Получив новый сегмент, приёмник прекращает ставить ECE на подтверждения последующих немаркированных данных. Новая CE открывает новый интервал.

Если пакет с CWR потерялся, состояние ECE остаётся и последующее подтверждение вновь доносит сигнал; позднее может появиться ещё один CWR. Этот путь отказа объясняет множество флагов без множества меток. CWR подтверждает, что после отправки соответствующих данных последовала реакция, но не доказывает доставку конкретного ECE ACK и не называет маркировавшее устройство.

В SYN тот же набор означает переговоры

До передачи данных действует иная грамматика. Инициатор ставит ECE и CWR одновременно в SYN, запрашивая ECN. Поддерживающая сторона отвечает SYN-ACK с ECE, но без CWR. Здесь ECE сообщает о возможности, а не отражает перегрузку, встреченную SYN.

Извлечение одного булева поля без TCP-фазы, направления и соседних флагов создаст фиктивное событие при каждом успешном согласовании. Само согласование также не обещает, что каждый последующий исходящий пакет получит код ECT. Контекст является частью значения.

Чистые ACK задают другую границу: классическая RFC 3168 отправляет их Not-ECT. Цепочка ECE отражает состояние, созданное данными прямого направления; тем же способом она не обследует перегрузку обратного пути.

Эхо не указывает адрес очереди

Активное управление очередью, описанное в RFC 7567, может маркировать вместо сброса при лёгкой или умеренной перегрузке и срабатывать до заполнения очереди. CE сама по себе не доказывает переполнение буфера, потерю, конкретную задержку или порог устройства.

Туннели дополнительно разделяют сигнал и место. Узел внутри туннеля может видеть и менять только внешний заголовок. RFC 6040 задаёт объединение внутренних и внешних полей ECN на границах. Конечный ECE может достоверно передавать перегрузку, не раскрывая точку появления CE.

Повторный ECE нельзя подменять дублирующим ACK из RFC 5681. У такого ACK свои условия; причиной могут быть потеря, изменение порядка или репликация. Номер ACK, последовательности, повторная передача, ECE, CWR и время остаются отдельными свидетельствами.

Наконец, RFC 8311 допускает документированные эксперименты, ослабляющие отдельные ограничения RFC 3168 и проверяющие иные маркировки или реакции. Описанная защёлка относится к классическому TCP, а не служит универсальной схемой всех вариантов ECN.

Источники