Ложные повторные передачи из-за скачков задержки Spurious RTO from delay spikes

ID причины rt-spurious-delay · Основной ответственный Внешние стороны · Внешние стороны · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка клиента

Открыть карточку в основной версии с иллюстрациями и экспериментами →

Пакет цел и лишь ненадолго сильно задерживается. Если эта задержка дольше RTO, отправитель считает пакет потерянным и передаёт его повторно.

Почему Bufferbloat, энергосбережение Wi-Fi, переключение состояний радиомодуля в мобильной сети или пауза виртуальной машины дают мгновенную задержку в сотни ms → Следствие RTO истекает раньше, происходит повторная передача, вскоре приходит и оригинал (получатель получает дубликат) → На экране Фриз и перемотку вызывает сам скачок задержки. Ложная повторная передача почти не удлиняет фриз, она только поднимает метрики повторных передач, и её принимают за потери

Симптомы: Фриз, Перемотка, Задержка ввода
Факторы: Задержка, Джиттер
У кого: Только у меня, Весь сервер
Когда: Изредка, случайно, После бездействия
Ответственные: Основной ответственный Внешние стороны · Внешние стороны · Совместно Команда инфраструктуры · Серверная инфраструктура, Команда разработки · Разработка клиента
Команда разработки: задачи: На клиентах с Android 10 и новее запрашивать во время игры режим Wi-Fi с низкой задержкой (блокировка Wi-Fi WIFI_MODE_FULL_LOW_LATENCY, действует, только когда экран включён и игра на переднем плане), чтобы уменьшить скачки задержки из-за энергосбережения.
Команда инфраструктуры: задачи: Избегать инстансов с burst-производительностью, не занижать сильно минимальный RTO, оставить включёнными F-RTO и временные метки (tcp_frto, tcp_timestamps), смотреть метрики повторных передач вместе с TCPSpuriousRTOs и TCPDSACKRecv из nstat, чтобы не принять их за потери.
Внешние стороны: задачи: Чтобы уменьшить сами скачки задержки, посоветовать игрокам SQM на роутере и отключение энергосбережения Wi-Fi.
Цифры для ориентира: Linux с помощью F-RTO обнаруживает ложные RTO и может отменить снижение скорости отправки. Проверяют по TCPSpuriousRTOs в nstat (сколько RTO признано ложными) и TCPDSACKRecv (сколько раз получатель сообщил «это уже получено»).
На графике: Случайные всплески · RTT (пинг), число ложных RTO
Где смотреть: Запуская nstat раз в минуту, смотреть вместе прирост TcpExtTCPTimeouts (истечения RTO), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv и TcpExtTCPLostRetransmit. Если есть захват пакетов, использовать фильтр Wireshark tcp.analysis.spurious_retransmission
Подтверждает: Когда растут RTO, вместе с ними растут TcpExtTCPSpuriousRTOs или TcpExtTCPDSACKRecv, и в те же моменты RTT подскакивает до сотен ms. В захвате на стороне получателя есть и оригинал, и повторная передача
Опровергает: Если TcpExtTCPSpuriousRTOs и DSACK не меняются, а растёт TcpExtTCPLostRetransmit (потеряна и повторная передача), это реальные потери. Если RTT не скачет, а DSACK стабильно много, это «Ложные быстрые повторные передачи из-за нарушения порядка»
Чем проверить: Инструменты инфраструктуры (игровой код не нужен)

Источники

RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP IETF
F-RTO: по ACK, пришедшим после RTO, определяет, был ли RTO ложным
RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
Скачки задержки в мобильной сети (хендовер, восстановление канала и т. п.) вызывают ложные таймауты и повторные передачи TCP и уменьшение окна перегрузки
RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP IETF
DSACK: получатель сообщает о дубликатах, и отправитель узнаёт о ложной повторной передаче
SNMP counter Linux kernel
TcpExtTCPSpuriousRTOs (ложные RTO, обнаруженные F-RTO), TcpExtTCPDSACKRecv (число полученных DSACK), TcpExtTCPLostRetransmit (сколько раз SACK сообщил, что повторно отправленный пакет снова потерян)
IP Sysctl Linux kernel
tcp_frto по умолчанию включён (полезно в беспроводных сетях с нестабильным RTT), tcp_timestamps по умолчанию 1
RFC 6298: Computing TCP's Retransmission Timer IETF
Обоснование того, что для защиты от ложных повторных передач нужен большой минимальный RTO (рекомендация не меньше 1 с)
WifiManager Android (Google)
WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): блокировка Wi-Fi с низкой задержкой, действует, только когда устройство подключено к AP, экран включён и приложение на переднем плане
net/ipv4/proc.c Linux kernel
Названия счётчиков в выводе nstat: TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv, TCPLostRetransmit
net/ipv4/tcp_timer.c Linux kernel
TCPTimeouts растёт при истечении таймера повторной передачи (RTO)
nstat(8) — Linux manual page iproute2
nstat по умолчанию показывает прирост с предыдущего запуска
Display Filter Reference: Transmission Control Protocol Wireshark
Фильтр отображения tcp.analysis.spurious_retransmission

Смотрите также

Тот же слой: Первопричины повторных передач TCP

Причины с тем же симптомом (Фриз) на других слоях

Всплески времени кадра L1 Процесс игрового клиента
Сборка мусора на клиенте L1 Процесс игрового клиента
Синхронная загрузка и компиляция шейдеров в главном потоке L1 Процесс игрового клиента
Стриминг ассетов отстаёт из-за медленного накопителя L1 Процесс игрового клиента
Проверки модуля защиты игры (античита) L1 Процесс игрового клиента
Переключение Wi-Fi ↔ LTE/5G L2 ОС и устройство клиента
Нехватка памяти и своп на клиенте L2 ОС и устройство клиента
Нехватка видеопамяти (VRAM) L2 ОС и устройство клиента

Карточка в основной версии с иллюстрациями и экспериментами