Кратко

  • draft-ietf-ccwg-ratelimited-increase-11 допускает ограниченный рост окна, когда передачу сдерживает приложение или flow control получателя, и выводит предел из максимального наблюдавшегося FlightSize.
  • maxFS ограничивает локальное состояние отправителя, но не бронирует будущую полосу, не открывает credit получателя и не гарантирует pacing либо успешность следующего всплеска.

Соединение может держать двадцать неподтверждённых сегментов, а приложение выдаёт лишь четыре. Все четыре подтверждены, явной потери нет, окно выглядит готовым к продолжению.

Но оставшиеся шестнадцать сегментов путь не проверяли.

Рабочая группа CCWG опубликовала draft-ietf-ccwg-ratelimited-increase-11 6 сентября, чтобы согласовать различающиеся правила TCP, QUIC, SCTP, DCCP и CUBIC. Одни спецификации не увеличивают окно, если отправитель использует его не полностью. Другие способны накапливать значение, оторванное от недавно испробованного объёма. Проект разрешает рост, но связывает его с наблюдением.

Rate-limited здесь означает, что отправитель передаёт меньше, чем разрешает congestion control. Приложение могло не предоставить данные, либо получатель мог ограничить credit соединения или потока. FlightSize—отправленный, но ещё не подтверждённый накопительным ACK объём—остаётся меньше cwnd. Ни одна причина сама по себе не говорит о перегрузке.

Переменная maxFS хранит наибольший FlightSize после последнего уменьшения окна. Более крупное наблюдение обновляет её, а любое снижение cwnd сбрасывает в ноль. Следующий рост не должен превышать limit(maxFS): значение, которое алгоритм получил бы после ACK для одного успешно переданного окна такого размера. В примере Slow Start предел равен 2*maxFS, в Congestion Avoidance—maxFS+SMSS.

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

Историческое измерение стареет. Проект прямо предупреждает: без отдельного механизма уменьшения maxFS может храниться долго и перестать отражать текущий end-to-end путь. Поэтому он ссылается на RFC 7661 и Congestion Window Validation. Переменная pipeACK оценивает подтверждённый объём за измерительный RTT и отделяет недавно проверенное окно от состояния, основанного на прежней ёмкости. Это ограниченные во времени свидетельства, а не право на будущую передачу.

Необходимо разделять три управления. Приложение решает, есть ли байты. Получатель выдаёт credit. Congestion control ограничивает ввод по сигналам сети. Большая cwnd не создаёт спрос, не отменяет back-pressure и не сохраняет маршрут, очереди, policers или конкурирующий трафик неизменными.

Pacing также требует собственного подтверждения. Стек может иметь право держать больше данных в полёте, но распределять пакеты во времени. Проект этому не мешает, однако не доказывает, что конкретная реализация включила pacing, выбрала безопасный интервал или избежала группировки из-за offload. Нужны фактическая конфигурация и наблюдение линии.

ACK сообщает о прежних данных в рамках семантики транспорта. Он помогает восстановлению и обновляет состояние перегрузки, но не обещает новый credit, неизменный маршрут или принятие следующего объекта приложением. Аутентификация укрепляет происхождение ACK, не его способность предсказывать будущее.

При утверждении проект обновит RFC 4341, 5681, 9002, 9260 и 9438. Пока это изменяемый Internet-Draft без запроса к IANA. Продвижение стандарта, наличие кода, включение функции и результат эксплуатации требуют разных доказательств.

Источники