Desbordamiento de la cola en el cuello de botella (pérdida por congestión) Tail drop at a congested bottleneck
ID de la causa rt-queue-drop · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Externo (Externo), Desarrollo de cliente (Equipo de desarrollo)
Cuando se llena la cola del punto más estrecho, como el router, la interconexión entre ISP o el enlace del centro de datos, los paquetes que llegan se descartan.
Por qué El video, las descargas o el tráfico de otras personas llenan el cuello de botella → Efecto Mientras la cola está llena, los paquetes que llegan se descartan uno tras otro (tail drop). Los que no se descartan también esperan al final de una cola llena → En pantalla Desaparecen varios paquetes a la vez: congelamiento largo seguido de cámara rápida, frecuente por la noche
Horas pico de la noche, Cuando se junta mucha gente
Responsable
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Externo (Externo), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Mostrar en pantalla el estado de la red cuando se concentran las pérdidas o el ping se dispara (avisar de que puede haber una transferencia grande en la misma conexión).
Tareas (Equipo de infraestructura)
Asegurar margen en los enlaces del centro de datos, revisar los contadores de descartes de cola (output drops) de nuestros enlaces y puertos de switch, desviar el tráfico por otros enlaces o por otro peering cuando el tramo del ISP esté congestionado.
Tareas (Externo)
Indicar a los jugadores que usen SQM en el router (fq_codel, CAKE) y ECN (para que se reduzca la velocidad antes de que la cola se desborde), pedir al ISP que amplíe la capacidad del cuello de botella.
Cifras de referencia
En el momento en que la cola se desborda, desaparece de golpe buena parte de los paquetes que llegan durante decenas de ms. Como es fácil perder paquetes seguidos e incluso sus retransmisiones, a menudo se llega hasta el RTO.
En el gráfico
Alto solo a ciertas horas · Tasa de retransmisión, RTT (ping)
Dónde mirar
Tasa de retransmisión del servidor (incremento de TcpRetransSegs ÷ TcpOutSegs con nstat ejecutado cada minuto) y RTT por conexión, desglosados por región, ISP y franja horaria, junto con los descartes de salida (ifOutDiscards) de nuestros enlaces y puertos de switch. Comparar un mtr hacia la región afectada en horas pico y en horas tranquilas
Se confirma si
La tasa de retransmisión sube solo en el pico de la noche, y el RTT sube justo antes de la pérdida (la cola llenándose). En el mtr, solo en horas pico aumentan juntas la pérdida y la latencia desde un salto concreto hasta el final
Se descarta si
Si el RTT no sube justo antes de la pérdida, apunta a “Descarte del exceso por un policer”. Si la pérdida es parecida a cualquier hora, a “Errores físicos (cables, transceptores ópticos o conectores defectuosos)” o “Cambio de ruta o ruta ECMP defectuosa”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: paquetes que no se enviaron y se descartaron aunque no había errores, por ejemplo, para liberar espacio de búfer
An Internet-Wide Analysis of Traffic PolicingGoogle Distinción entre el desbordamiento de cola, en el que la espera y el RTT suben antes de la pérdida, y el policing, que descarta el exceso sin que suba el RTT (SIGCOMM 2016)