Retransmisiones rápidas espurias por reordenamiento de paquetes Reordering triggers spurious fast retransmit
ID de la causa rt-reorder · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Cuando los paquetes cambian de orden al pasar por varias rutas o por enlaces agregados, el receptor avisa con ACK duplicados de que “falta un paquete”, y el emisor reenvía paquetes que estaban bien.
Por qué Los dispositivos que reparten el tráfico entre rutas paquete a paquete, los LAG (agregación de enlaces) que reparten paquete a paquete o el instante de un cambio de ruta desordenan los paquetes → Efecto Los paquetes posteriores llegan antes y se acumulan 3 ACK duplicados → retransmisión rápida → En pantalla Los paquetes del juego, que van espaciados, casi no se ven afectados. Las actualizaciones grandes en zonas con mucha gente y las descargas de parches se vuelven lentas, y a veces hay tirones
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de infraestructura)
Red: repartir el tráfico por conexión, nunca paquete a paquete (ECMP y LAG con hash de dirección y puerto). Servidores/SO: usar RACK (detección de pérdidas basada en el tiempo, resistente al reordenamiento; si detecta retransmisiones espurias con DSACK, amplía automáticamente el margen de reordenamiento), revisar el grado de reordenamiento que Linux estima automáticamente para cada conexión (valor reordering de ss -ti, que parte de tcp_reordering=3).
En el gráfico
Siempre alto · Reordenamientos detectados, DSACK recibidos
Dónde mirar
TcpExtTCPSACKReorder y TcpExtTCPTSReorder (reordenamientos detectados) y TcpExtTCPDSACKRecv de nstat; por conexión, reordering (aparece si no vale 3) y reord_seen de ss -ti. En la captura de paquetes, el filtro de Wireshark tcp.analysis.out_of_order
Se confirma si
Los contadores de reordenamiento y los DSACK suben de forma constante a cualquier hora, y el valor reordering de las conexiones que pasan por una ruta o un dispositivo concreto es mayor que 3. En la captura del receptor, los paquetes posteriores llegan antes y los anteriores llegan enseguida
Se descarta si
Si los contadores de reordenamiento no cambian y sube TcpExtTCPLostRetransmit, es pérdida real. Si los DSACK solo suben cuando salta el RTT, apunta a “Retransmisiones espurias por picos de latencia”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF RACK detecta las pérdidas por tiempo, lo que lo hace resistente al reordenamiento, y al recibir DSACK amplía el margen de tiempo para el reordenamiento (reo_wnd)
IP SysctlLinux kernel tcp_reordering: valor inicial 3 (se ajusta automáticamente en cada conexión hasta tcp_max_reordering); configuración de RACK en tcp_recovery
misc/ss.ciproute2 ss -ti muestra reordering:valor cuando el reordering de la conexión difiere del valor predeterminado 3, y reord_seen:veces si alguna vez hubo reordenamiento
SNMP counterLinux kernel TcpExtTCPSACKReorder y TcpExtTCPTSReorder (reordenamiento detectado), TcpExtTCPDSACKRecv (DSACK recibidos), TcpExtTCPLostRetransmit (un paquete retransmitido se vuelve a perder)
include/uapi/linux/tcp.hLinux kernel tcpi_reord_seen de tcp_info: veces que la conexión sufrió reordenamiento