Кратко

  • Истечение PTO запускает один или два зонда, запрашивающих ACK, и увеличивает backoff.
  • Оно само по себе не объявляет пакет потерянным и не доказывает перегрузку или потерю ACK.
  • Таймер, packet number space, содержимое зонда, последующие ACK, объявление потери и результат приложения — разные факты.

Ошибочная интерпретация появляется, когда операционный конвейер превращает срабатывание таймера в готовый диагноз. Истечение PTO — прежде всего событие таймера в конкретном packet number space. Оно означает, что пакеты, запрашивающие ACK, не дали ожидаемого продвижения за рассчитанный период, либо серверу требуется зондирование до проверки адреса клиента. Ответ протокола — поиск продвижения: endpoint отправляет как минимум один и может отправить до двух полноразмерных дейтаграмм-зондов, запрашивающих ACK, после чего увеличивает backoff PTO. Из этого не следует, что какой-либо пакет потерян.

Состояние PTO ведётся отдельно для каждого packet number space. Initial, Handshake и Application Data нельзя свести в одну очередь. Обычный расчёт имеет вид smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay. Для Initial и Handshake слагаемое max_ack_delay принимается равным нулю. PTO для Application Data не запускается до подтверждения handshake. Отправка или подтверждение пакетов, запрашивающих ACK, а также удаление ключей Initial или Handshake могут перезапустить PTO. После истечения следующий период удваивается; последовательные периоды растут экспоненциально в разных пространствах номеров пакетов и в конечном счёте ограничиваются отдельным idle timeout.

Обнаружение потерь создаёт иное доказательство. Таймер обнаружения потери по времени, time-threshold loss-detection timer, имеет приоритет, поэтому PTO не следует запускать, когда такой таймер установлен. Позднейшие диапазоны ACK могут привести к объявлению потери по packet threshold или time threshold согласно RFC 9002. Это последующее объявление нельзя приписать моменту истечения PTO. Если отметить все неподтверждённые пакеты потерянными сразу после истечения, система делает вывод до появления нужного порогового или ACK-доказательства.

Термин «повторная передача» также требует точности. При наличии новых данных следует использовать их. Если новых данных нет, ранее отправленная информация может быть снова помещена в новый фрейм и новый пакет. При отсутствии данных можно отправить PING или другой фрейм, запрашивающий ACK. RFC 9000 говорит, что потерянные QUIC-пакеты не отправляются целиком повторно: нужная для восстановления информация переносится в новых фреймах и новых пакетах. Повторная отправка информации не является воспроизведением того же пакета; PING и PADDING не содержат информации, пригодной для повторной передачи.

До проверки адреса зонды сервера учитываются в anti-amplification limit. Если разрешённый объём передачи не позволяет отправить дополнительные данные, сервер не должен запускать PTO, пока новая дейтаграмма клиента не увеличит доступный предел передачи. Клиент при этом может быть вынужден зондировать, чтобы разблокировать сервер. Это ограничение передачи, а не доказательство потери. Одно истечение PTO также не доказывает, что причиной отсутствия продвижения была перегрузка, что получатель обработал данные приложения, что сервис ответил или что операция завершилась.