Game-Lag-Whitepaper › Grundursachen von TCP-Retransmissions

Unnötiger Fast Retransmit durch vertauschte Reihenfolge Reordering triggers spurious fast retransmit

Ursachen-ID rt-reorder · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Kommt die Paketreihenfolge über mehrere Pfade oder gebündelte Links durcheinander, meldet der Empfänger per doppelter ACKs „Paket fehlt“, und der Sender schickt intakte Pakete erneut.

Warum Geräte, die Pfade pro Paket aufteilen, LAG (Link-Bündelung) mit Verteilung pro Paket oder der Moment eines Routenwechsels bringen die Reihenfolge durcheinander → Folge Spätere Pakete kommen zuerst an, 3 doppelte ACKs sammeln sich → Fast Retransmit → Auf dem Bildschirm Vereinzelte Spielpakete sind kaum betroffen. Große Updates an vollen Orten und Patch-Downloads werden langsamer, gelegentlich Ruckeln

Symptome

Ruckeln, Input-Lag

Faktoren

Jitter

Wer ist betroffen

Bestimmte Region oder Provider, Ganzer Server

Wann

Immer, Bei großem Andrang

Zuständigkeit

Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

Aufgaben Infrastrukturteam

Netzwerk: Verteilung pro Paket auf Verteilung pro Verbindung umstellen (ECMP und LAG per Hash über Adresse und Port). Server/OS: RACK nutzen (zeitbasierte Verlusterkennung, robust gegen vertauschte Reihenfolge. Erkennt RACK per DSACK unnötige Retransmissions, vergrößert es automatisch die Toleranz für vertauschte Reihenfolge), den von Linux pro Verbindung automatisch geschätzten Grad der Vertauschung prüfen (Wert reordering in ss -ti, Startwert tcp_reordering=3).

Im Graphen

Von Anfang an dauerhaft hoch · Erkannte Vertauschungen der Reihenfolge, empfangene DSACKs

Wo nachsehen

TcpExtTCPSACKReorder und TcpExtTCPTSReorder (erkannte Vertauschungen der Reihenfolge) sowie TcpExtTCPDSACKRecv in nstat prüfen, pro Verbindung reordering (angezeigt, wenn ungleich 3) und reord_seen in ss -ti. Im Paketmitschnitt den Wireshark-Filter tcp.analysis.out_of_order nutzen

Spricht dafür

Reordering-Zähler und DSACKs steigen unabhängig von der Tageszeit stetig, bei Verbindungen über einen bestimmten Pfad oder ein bestimmtes Gerät ist reordering größer als 3. Im Mitschnitt auf Empfängerseite kommen spätere Pakete zuerst, und die früheren folgen kurz darauf

Spricht dagegen

Reordering-Zähler unverändert, TcpExtTCPLostRetransmit steigt: echter Verlust. DSACKs steigen nur in Momenten mit RTT-Spitzen: „Unnötige Retransmission durch Latenzsprünge“

Prüfmittel

Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

1. RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
   Wird der Pfad pro Paket aufgeteilt, ändert sich die Reihenfolge, und kommen 3 oder mehr spätere Pakete zuerst an, führt TCP einen unnötigen Fast Retransmit aus
2. RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
   ECMP, das den Pfad per Hash über die Headerfelder wählt, die den Flow identifizieren (Verteilung pro Flow)
3. RFC 5681: TCP Congestion Control IETF
   Fast Retransmit beim dritten doppelten ACK
4. RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
   RACK erkennt Verluste zeitbasiert und ist daher robust gegen vertauschte Reihenfolge, bei empfangenem DSACK vergrößert es das Toleranzfenster für vertauschte Reihenfolge (reo_wnd)
5. IP Sysctl Linux kernel
   tcp_reordering mit Startwert 3 (pro Verbindung automatisch bis tcp_max_reordering angepasst), RACK-Einstellung in tcp_recovery
6. misc/ss.c iproute2
   ss -ti zeigt reordering:Wert, wenn der reordering-Wert der Verbindung vom Standardwert 3 abweicht, und reord_seen:Anzahl, wenn die Verbindung schon vertauschte Reihenfolge erlebt hat
7. SNMP counter Linux kernel
   TcpExtTCPSACKReorder und TcpExtTCPTSReorder (erkannte Vertauschungen), TcpExtTCPDSACKRecv (empfangene DSACKs), TcpExtTCPLostRetransmit (auch das erneut gesendete Paket ging verloren)
8. include/uapi/linux/tcp.h Linux kernel
   tcpi_reord_seen in tcp_info: Zahl der Vertauschungen, die die Verbindung erlebt hat
9. Display Filter Reference: Transmission Control Protocol Wireshark
   Anzeigefilter tcp.analysis.out_of_order

Verwandte Ursachen

Gleiche Schicht: Grundursachen von TCP-Retransmissions

• Verlust auf der Funkstrecke
• Warteschlangenüberlauf am Engpass (Verlust durch Überlast)
• Überlauf flacher Puffer durch Sende-Bursts
• Policer verwirft Überschuss
• Physische Fehler (defekte Kabel, optische Module, Stecker)
• Duplex-Mismatch
• Verworfene Pakete auf dem empfangenden Server-Host
• Verworfene Pakete in Firewall und Connection Tracking
• Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz)
• MTU-Blackhole (nur große Pakete gehen wiederholt verloren)
• Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung
• Routenwechsel oder defekter ECMP-Pfad
• Unnötige Retransmission durch Latenzsprünge
• Verspätete oder verlorene ACKs (ausgelasteter Upload)
• RTO-Einstellung passt nicht zur Umgebung
• Langsame Wiederherstellung bei Thin Streams
• Zwischengeräte entfernen TCP-Optionen
• Zero Window (Stillstand, der wie eine Retransmission aussieht)
• Retransmission der Verbindungsanfrage (SYN)

Ursachen aus anderen Schichten mit demselben Symptom (Ruckeln)

• Frametime-Spikes L1 Spielprozess auf dem Client
• Garbage Collection auf dem Client L1 Spielprozess auf dem Client
• Synchrones Laden und Shader-Kompilierung im Main-Thread L1 Spielprozess auf dem Client
• Langsamer Datenträger bremst Asset-Streaming L1 Spielprozess auf dem Client
• Renderlast durch große Spielermengen L1 Spielprozess auf dem Client
• Fehlender oder zu kurzer Interpolationspuffer L1 Spielprozess auf dem Client
• Übermäßige Extrapolation (Dead Reckoning) L1 Spielprozess auf dem Client
• Aufholspirale bei festem Zeitschritt L1 Spielprozess auf dem Client

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen