Ist die Warteschlange an der engsten Stelle voll, etwa am Router, am Übergabepunkt zwischen Providern oder an der Leitung des Rechenzentrums, werden neu ankommende Pakete verworfen.
Warum Videos, Downloads oder Traffic anderer Nutzer füllen den Engpass → Folge Solange die Warteschlange voll ist, werden neu ankommende Pakete nacheinander verworfen (Tail Drop). Auch die nicht verworfenen Pakete warten am Ende der vollen Warteschlange → Auf dem Bildschirm Mehrere Pakete verschwinden auf einmal: langer Freeze, dann Zeitraffer, häufig abends
Bei gehäuften Verlusten oder sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen (mit Hinweis auf mögliche große Übertragungen über dieselbe Leitung).
Aufgaben Infrastrukturteam
Reserven auf der Leitung des Rechenzentrums schaffen, Zähler für in der Warteschlange verworfene Pakete (output drops) an den eigenen Leitungen und Switch-Ports prüfen, bei verstopfter Providerstrecke über andere Leitungen oder Peerings umleiten.
Aufgaben Extern
Spieler auf SQM (fq_codel, CAKE) und ECN am Router hinweisen (damit die Senderate sinkt, bevor die Warteschlange überläuft), beim Provider einen Ausbau des Engpasses anfragen.
Größenordnungen
Im Moment des Überlaufs verschwindet einige Dutzend ms lang ein großer Teil der ankommenden Pakete auf einmal. Weil Pakete in Folge verloren gehen und dabei leicht auch die Retransmission verloren geht, läuft es oft auf ein RTO hinaus.
Im Graphen
Nur zu bestimmten Tageszeiten hoch · Retransmission-Rate, RTT (Ping)
Wo nachsehen
Retransmission-Rate des Servers (Zuwachs von TcpRetransSegs ÷ TcpOutSegs, nstat im Minutentakt) und RTT pro Verbindung nach Region, Provider und Tageszeit aufschlüsseln, dazu verworfene ausgehende Pakete (ifOutDiscards) an den eigenen Leitungen und Switch-Ports prüfen. mtr zur betroffenen Region zur Stoßzeit und zu ruhigen Zeiten aufzeichnen und vergleichen
Spricht dafür
Retransmission-Rate steigt nur in der abendlichen Stoßzeit, kurz vor dem Verlust steigt zuerst die RTT (die Warteschlange füllt sich). In mtr nehmen nur zur Stoßzeit ab einem bestimmten Hop bis zum Ziel Verlust und Latenz gemeinsam zu
Spricht dagegen
RTT steigt vor dem Verlust nicht: „Policer verwirft Überschuss“. Verlust unabhängig von der Tageszeit immer ähnlich: „Physische Fehler“ oder „Routenwechsel oder defekter ECMP-Pfad“
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: Zahl ausgehender Pakete, die verworfen wurden, obwohl kein Fehler vorlag, etwa um Pufferplatz freizumachen
An Internet-Wide Analysis of Traffic PolicingGoogle Unterscheidung: Bei Warteschlangenüberlauf steigen vor dem Verlust zuerst Wartezeit und RTT, Policing verwirft den Überschuss ohne RTT-Anstieg (SIGCOMM 2016)
Verwandte Ursachen
Gleiche Schicht: Grundursachen von TCP-Retransmissions