Sendet eine Verbindung wie bei Spielen nur vereinzelt kleine Pakete, läuft das RTO ab, bevor „3 nachfolgende Pakete“ beisammen sind. Beim selben Verlust steht sie deutlich länger still als eine große Übertragung.
Warum Paketabstand um die 100 ms, daher nur wenige noch unbestätigte Pakete (in flight) → Folge Bis 3 doppelte ACKs beisammen sind, vergehen über 300 ms, daher greift zuerst das RTO (Ping + 200 ms), bei Verlusten in Folge jeweils doppelt so lang → Auf dem Bildschirm Pro Verlust etwa 0,3 s Freeze, geht auch die Retransmission verloren, fast 1 s Freeze, danach Zeitraffer
Server: TCP_NODELAY aktivieren (bei aktivem Nagle fehlen die nachfolgenden Pakete, die RACK zur Erkennung braucht), Echtzeitpakete mit eigener Retransmission über UDP senden. Client: TCP_NODELAY aktivieren, Echtzeitpakete wie der Server per UDP senden.
Aufgaben Infrastrukturteam
RACK-TLP nutzen (Standard in aktuellen Linux-Kerneln), per tcp_thin_linear_timeouts das Verdoppeln bei aufeinanderfolgenden RTOs abschalten.
Größenordnungen
Bei 100 ms Paketabstand und 60 ms Ping dauert es bis zum Fast Retransmit etwa 360 ms (bis 3 nachfolgende Pakete angekommen sind und deren Bestätigung zurück ist), das RTO beträgt etwa 260 ms. Mit RACK wird nach etwa 160 ms erneut gesendet, sobald die Bestätigung des nächsten Pakets zurückkommt. Liegt der Paketabstand über 200 ms, ist auch RACK nicht schneller als das RTO.
Im Graphen
Lücke, dann alles auf einmal · Empfangsvolumen pro Verbindung, abgelaufene RTOs
Wo nachsehen
Zuwachs von TcpExtTCPTimeouts (abgelaufene RTOs), TcpExtTCPFastRetrans (Fast Retransmit), TcpExtTCPLossProbes und TcpExtTCPLossProbeRecovery (TLP) in nstat vergleichen, Spielverbindungen mit ss -ti auf rto und backoff prüfen. Auch die Werte von net.ipv4.tcp_recovery, tcp_early_retrans und tcp_sack auf dem Server kontrollieren
Spricht dafür
Unter den Retransmissions gibt es mehr abgelaufene RTOs als Fast Retransmits, bei Spielverbindungen ist backoff häufig größer als 0 (die Verbindung steckt gerade im RTO). Während des Stillstands ist das Empfangsvolumen 0, nach der Wiederherstellung kommt alles auf einmal
Spricht dagegen
Große Übertragungen desselben Servers stehen genauso lange still: Verlustproblem unabhängig vom Verbindungsprofil. Häufung bei Verbindungen ohne SACK und Timestamps: „Zwischengeräte entfernen TCP-Optionen“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Linux hatte früher für Thin Streams auch eine Option, die schon nach einem doppelten ACK erneut sendet (tcp_thin_dupack). Sie wurde 2017 entfernt, heute übernimmt RACK diese Aufgabe. Ist Nagle aktiv (TCP_NODELAY aus), werden während des Wartens auf die Bestätigung des verlorenen Pakets auch keine neuen Pakete gesendet. Dann fehlen RACK die nachfolgenden Pakete zur Erkennung, und es wird bis zum RTO gewartet.
Quellen
Thin-streams and TCPLinux kernel Thin Streams mit vereinzelten Sendungen wie bei Spielen profitieren kaum von Fast Retransmit und sind auf lange Timeouts angewiesen, Kriterium: weniger als 4 noch unbestätigte Pakete (in flight)
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF RACK erkennt Verluste daran, dass später gesendete Pakete zugestellt wurden, TLP wartet 2·SRTT (bei nur einem unbestätigten Paket zuzüglich einer Reserve für Delayed ACK)
include/net/tcp.hLinux kernel TCP_RTO_MIN 200 ms, Einstufung als Thin Stream (weniger als 4 Pakete in flight) und 6 lineare Wiederholungen
tcp: remove thin_dupack featureLinux kernel Entfernung von thin_dupack im Januar 2017 (Linux 4.11), mit der Begründung, dass RACK diese Aufgabe übernimmt
IP SysctlLinux kernel tcp_thin_linear_timeouts: bei Thin Streams wird das RTO bis zu 6-mal nicht verdoppelt (standardmäßig aus)