Переполнение очереди в узком месте (потери от перегрузки) Tail drop at a congested bottleneck
ID причины rt-queue-drop · Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Внешние стороны · Внешние стороны, Команда разработки · Разработка клиента
Когда заполняется очередь в самом узком месте (в роутере, на стыке провайдеров, на линии связи ЦОД), новые пакеты выбрасываются.
Почему Видео, загрузки и трафик других пользователей забивают узкое место → Следствие Пока очередь заполнена, новые пакеты выбрасываются подряд (tail drop). Даже не выброшенные пакеты ждут в конце забитой очереди → На экране Разом пропадает несколько пакетов: долгий фриз, потом перемотка, чаще по вечерам
Все в одном доме, Один регион или провайдер, Весь сервер
Когда
Вечерний пик, При наплыве игроков
Ответственные
Основной ответственный Команда инфраструктуры · Сетевая инфраструктура · Совместно Внешние стороны · Внешние стороны, Команда разработки · Разработка клиента
Команда разработки: задачи
При серии потерь или скачке пинга показывать на экране состояние сети (с подсказкой, что через это же подключение, возможно, идёт большая загрузка).
Команда инфраструктуры: задачи
Обеспечить запас пропускной способности на линиях связи ЦОД, проверять счётчики отбрасываний в очереди (output drops) на наших линиях и портах коммутаторов, если забит участок провайдера, обходить его через другие линии или пиринг.
Внешние стороны: задачи
Посоветовать игрокам SQM на роутере (fq_codel, CAKE) и ECN (скорость снижается раньше, чем очередь переполнится), попросить провайдера расширить узкое место.
Цифры для ориентира
В момент переполнения очереди в течение десятков ms разом пропадает значительная часть входящих пакетов. Пакеты теряются подряд, легко теряется и повторная передача, поэтому дело часто доходит до RTO.
На графике
Высоко только в определённые часы · доля повторных передач, RTT (пинг)
Где смотреть
Разбить долю повторных передач на сервере (прирост TcpRetransSegs ÷ TcpOutSegs по nstat, запускаемому раз в минуту) и RTT соединений по регионам, провайдерам и времени суток и смотреть вместе с выходными отбрасываниями (ifOutDiscards) на наших линиях и портах коммутаторов. Запустить mtr в проблемный регион в час пик и в спокойное время и сравнить
Подтверждает
Доля повторных передач растёт только в вечерний пик, и перед потерями сначала растёт RTT (так выглядит заполнение очереди). В mtr только в час пик начиная с какого-то участка и до конца растут и потери, и задержка
Опровергает
Если перед потерями RTT не растёт, это «Отбрасывание избытка полисером». Если потери примерно одинаковы в любое время суток, это «Физические ошибки (неисправные кабели, оптические модули и разъёмы)» или «Смена маршрута и неисправный путь ECMP»
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: число исходящих пакетов, отброшенных без отправки, хотя ошибок не обнаружено (например, чтобы освободить место в буфере)
An Internet-Wide Analysis of Traffic PolicingGoogle Различие: при переполнении очереди до потерь сначала растут время ожидания и RTT, а полисинг отбрасывает избыток без роста RTT (SIGCOMM 2016)