Кратко

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

Счётчик увидел двадцать четыре, путь — только десять

В примере начальное окно равно десяти сегментам. Отправитель передаёт их и останавливается. Без потерь, с одним ACK на сегмент, slow start повышает cwnd до двадцати.

Позднее приложение даёт четыре сегмента. Они также доставлены и подтверждены. Без предела четыре ACK увеличивают cwnd до двадцати четырёх. Максимальный полёт за RTT остаётся равным десяти.

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

Это расчётный пример, не описание сбоя. Он намеренно убирает delayed ACK, байтовый учёт, pacing и потери, чтобы поставить вопрос: какое наблюдение даёт хосту право увеличить объём неподтверждённых данных в сети?

Одобрение не завершает цепочку

Объявление от 24 августа, 17:57 UTC, одобряет редакцию 10 «Increase of the Congestion Window when the Sender Is Rate-Limited» как Proposed Standard. Документ Congestion Control Working Group обновляет DCCP CCID 2, TCP, QUIC, SCTP и CUBIC.

28 августа Datatracker всё ещё показывал Active Internet-Draft в RFC Ed Queue с ожиданием ответа авторов. Действия IANA не требуются. Решение IESG, номер RFC, выпуск кода, включение и измеренный результат — отдельные состояния.

Объявление сообщает о нескольких реализациях и поведении в Linux начиная с 3.16. Это свидетельство опыта, но не доказательство версии, конфигурации и телеметрии конкретного сервиса.

Кто на самом деле ограничил отправку

Контроль перегрузки может разрешать больше, чем передаётся. У приложения нет данных. Получатель ограничивает TCP rwnd или credit соединения и stream в QUIC. Pacer растягивает отправку.

Cwnd-limited поток использует разрешение. Rate-limited поток по RFC 7661 использует не больше половины cwnd и остаётся в непроверенной фазе.

У состояний разные владельцы. Приложение поставляет байты, получатель открывает credit, транспорт рассчитывает окно, pacer назначает время, путь даёт потери, ECN, задержку и доставку. Общая метка недоиспользования скрывает, какая поверхность закрылась.

Cwnd — разрешение, а не измерение полосы. Оно задаёт объём неподтверждённых данных в полёте, но не гарантирует будущую ёмкость, готовность получателя или неизменный маршрут.

maxFS связывает разрешение с исполнением

Новое правило хранит maxFS — наибольший FlightSize после последнего уменьшения cwnd. Начальное значение равно initcwnd; затем сохраняется максимум каждой оценки полёта.

Любое снижение cwnd обнуляет maxFS. Следующий полёт создаёт новую основу. Потеря, ECN или другая реакция тем самым прекращает и полномочие прежнего максимума.

При FlightSize < cwnd ACK по-прежнему могут увеличивать окно, но итог не превосходит limit(maxFS). Это значение, которое алгоритм дал бы после успешного подтверждения полного окна размера maxFS.

Для slow start RFC 5681 примерный предел равен 2 * maxFS, для congestion avoidance — maxFS + SMSS. ACK не отбрасываются; ограничивается их доказательная сила.

В примере десять плюс четыре первое окно законно достигает двадцати. Следующие четыре ACK не пересекают предел. Только реально больший полёт двигает maxFS и обосновывает новый потолок.

Общая граница не означает одинаковый код

Стандартный TCP не имел явного потолка для этого состояния. DCCP CCID 2 мог расти, не будучи cwnd-limited. QUIC не рекомендовал рост при недоиспользовании. SCTP и CUBIC также имели более консервативные барьеры.

Новый текст разрешает ограниченный рост вместо полного запрета и одновременно закрывает неограниченный кредит. Контроллеры на основе скорости не должны превышать устойчивую скорость, которую разрешил бы метод cwnd. Pacing совместим, если меняет интервалы, но не объём полёта за RTT.

Для BBR и гибридов отдельно наблюдают оценку скорости, pacing rate, cwnd и application-limited samples. Общим становится предел доказательства, а не реализация.

Старый максимум способен пережить старый путь

Без снижения cwnd maxFS может сохраняться долго и перестать отражать текущий end-to-end путь. Мобильное переключение, новый маршрут, туннель или очередь не обязаны вызвать reset.

RFC 7661 решает родственную задачу Congestion Window Validation и определяет pipeACK для недавно подтверждённого размера канала. Механизмы не одинаковы: один управляет ростом, другой — недоиспользованным окном и реакцией на перегрузку.

Сохранение максимума избавляет от повторного обучения после каждой паузы. Без времени, пути и истории снижения оно превращается в память без происхождения.

Подлинный ACK всё равно имеет узкий смысл

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

Допустимость ACK, подтверждённая передача и локально разрешённый рост должны храниться раздельно. Текущий код Linux Reno и CUBIC проверяет cwnd-limited до роста. Это открытый running-code пример, не аттестация производственного парка.

Операционная цепочка объединяет транспорт и build, очередь приложения, credit получателя, pacing, cwnd, FlightSize, maxFS, initcwnd, ssthresh, подтверждённые байты, снижение по потере или ECN, рассчитанный потолок, путь и результат после возобновления. Стандарт задаёт минимум; локальное измерение доказывает эффект.

Источники