Der Täter ist ein TCP-Phänomen und dies wird als „Bufferbloat“ bezeichnet. Vor einigen Jahren lud ein Programmierer von Google von zu Hause eine große Datei auf seinen Arbeitsserver. Seine Kinder beschwerten sich bei ihm, dass seine Arbeit den Internet-Verkehr seiner Kinder negativ beeinflussen würde. Natürlich fragte sich der Experte, wie seine Upload-Aktivitäten die Downloads seiner Kinder beeinflussen könnten. Da es keine eindeutige Antwort gab, machte er sich auf die Erforschung dieser Fragestellung.
Durch das Experimentieren mit Pings und verschiedenen Belastungsstufen auf seiner Internetverbindung entdeckte er, dass die Latenzzeiten oft vier- bis zehnmal größer waren als erwartet. Er nannte dieses Phänomen „Bufferbloat“. Seine Schlussfolgerung lautete: Einige Datenpakete sind kurzzeitig in übermäßig großen Puffern gefangen.
Von der Zeit an, als der Programmierer seine Beobachtungen veröffentlichte, untersuchten auch Forscher von Unternehmen (Google, Cisco) Standardisierungsgruppen (IETF) und einige großen Forschungsuniversitäten das Bufferbloat-Phänomen mit folgendem Resultat: Bufferbloat ist real, aber seine Auswirkungen auf den normalen Datenfluss im Internet wurde bisher noch nicht vollständig verstanden.
Wer oder was ist am meisten von diesem Phänomen betroffen?
Jeder, der aktiv surft oder eine der bekannten Suchmaschinen nutzt, ist vom Bufferbloat-Phänomen mehr oder weniger betroffen. Nutzt jemand Echtzeit-Anwendungen (Sprache oder Video) kann ihm Bufferbloat das Leben schwer machen. Die Forschung beweist, dass die WLAN-Hotspots in Hotels und Cafes besonders anfällig für Bufferbloat-Probleme sind.
Welche Art von Verkehr ist betroffen?
Der gesamte Verkehr in der entgegengesetzten Richtung, der auf Verbindungen mit einer hohen Bandbreitennutzung übermittelt wird, verschlechtert sich. Anwendungen, die geringe Paketgrößen übermitteln (beispielsweise VoIP, DNS und ARP) können ebenfalls unter dem Phänomen leiden. Das Bufferbloat-Phänomen wirkt sich auf VoIP durch eine erhöhte Verzögerung und Jitter aus. Bei DNS-Abfragen kann sich durch Bufferbloat die Antwortzeit um das Achtfache verlängern.
Warum konnte sich das Problem so lange verbergen?
Es gibt für das späte Erkennen des Bufferbloat-Phänomens drei Hauptgründe:
- Das Bufferbloat-Problem ist eng mit der Funktionsweise des TCP-Protokolls und der Verwaltung von dynamischen Netzwerkpuffern verknüpft. Das Management von dynamischen Puffern wird immer noch nicht vollständig verstanden.
- Es gibt einen weit verbreiteten Irrglauben, dass das Verwerfen von Pakete im Internet immer ein Problem darstellt. Die Wahrheit lautet jedoch, dass das Verwerfen von Paketen eine ordnungsgemäße Funktion des TCP-Protokolls darstellt.
- Es herrscht im Internet eine breite Überzeugung vor, dass der beste Weg zur Beseitigung einer schlechten Performance ausschließlich über die Erhöhung der Bandbreite führt.
Was ist Bufferbloat genau?
Bei dem Versuch die Paketverluste im Internet zu reduzieren, haben die Netzbetreiber, Entwickler und Ingenieure die Größe der Netzwerkpuffer um ein Vielfaches erhöht. Durch diese Maßnahme erhöht sich zwar die Verzögerung, aber hat wenig Einfluss auf den Durchsatz. Folglich können kleine Pakete (beispielsweise VoIP, DNS und TCP Acks) in den größeren Puffern hinter größeren Paketen anderer Datenströme, gefangen werden.
Es gibt ein Wahrnehmungsproblem im Zusammenhang mit dem Puffermanagement. Oft werden Puffer als kleine Stücke von Memory beschrieben. Diese Puffer können in der Praxis Hunderte und sogar Tausende von Pakete zwischenspeichern. Diese Puffer befinden sich nicht nur in den Netzwerkkomponenten, sondern können auch in den Protokoll-Stacks der Endgeräte der Netzwerkkarten und den Gateways im Pfad zwischen den Endstationen angesiedelt sein.
Welchen Einfluss hat Bufferbloat auf den TCP-Betrieb?
Die überwiegende Mehrheit unseres Netzwerkverkehrs verwendet TCP als Transportprotokoll. Will man Bufferbloat komplett verstehen, dann muss man wissen wie das TCP-Protokoll im Detail funktioniert. Zum Aufbau einer TCP-Verbindung wird ein Handshake-Verfahren (three way handshake) genutzt. Mit Hilfe dieses Handshake-Verfahrens werden zwischen den an der Verbindung beteiligten (sendende und empfangende) TCP-Entitäten die individuellen Parameter ausgehandelt. Hierzu gehören beispielsweise die Initial-Sequenznummern.
Soll ein FTP-Server eine große Datei übertragen, dann beginnt das TCP-Protokoll in der Regel seine Übertragung mit dem Übermitteln von vier Segmenten. Danach wartet der Sender auf die Bestätigung des richtigen Empfangs dieser Pakete. Üblicherweise erfolgt ein solcher Empfang durch das Übermitteln einer Bestätigung (Acknowledegement). Das Acknowledegement (Ack) wird üblicherweise nach jedem empfangenen Segment übermittelt.
Nachdem die vier Segmente bestätigt wurden, erhöht der Empfänger die Senderate, indem er acht Segmente übermittelt und auf deren Bestätigungen wartet. Nach der Bestätigung dieser Segmente wird das Sendefenster auf den Wert 16 gesetzt. Danach kann das Sendefester nach dem beschriebenen Prinzip noch weiter erhöht werden.
Die erste Verbindungsphase wird als Slow-Start-Mechanismus bezeichnet. Die Idee dabei besteht darin, dass die Pakete am Anfang „langsamer“ zu verschicken, um keine Überlastsituation hervor zu rufen.
Zu Beginn der Verbindung wird zwischen Sender und Empfänger eine geeignete Fenstergröße (window size) gewählt. Diese basiert auf der Puffergröße des Empfängers. Damit soll ein Pufferüberlauf auf der Seite des Empfängers verhindert werden. Dennoch kann es jederzeit zu einer internen Überlastung des genutzten Netzwerks kommen. Deshalb beginnt der Sender erst einmal mit einem kleinen Fenster von einer MSS (Maximum-Segment-Size). Falls der Empfänger den Empfang bestätigt, verdoppelt der Sender die Größe des Fensters. Es kommt also zu einem exponentiellen Wachstum. Dies geht entweder so lange bis die Größe des maximalen Fensters des Empfängers erreicht ist, oder aber es zu einem Timeout (Empfänger quittiert nicht den Empfang) kommt. In diesem Fall fällt die Fenstergröße wieder auf 1 MSS und das ganze spielt mit der Verdopplung der Fenstergröße fängt von vorne an.
Die Überlastkontrolle (Congestion-Avoidance) nutzt noch ein weiterer Schwellenwert. Wird dieser Schwellenwert erreicht, wächst das Fenster nur noch um eine MSS. Statt einem exponentiellen Wachstum erhält man nun ein lineares Wachstum. Auch dieses nimmt so lange zu bis die Größe des maximalen Fenster des Empfängers erreicht ist, oder es zu einem Timeout kommt.
Stellt der Sender fest, dass Paketverluste auf der Strecke aufgetreten sind, reduziert dieser seine Senderate um die Hälfte und initiiert einen Slow-Start. Dadurch passt sich die TCP-Rate dynamisch an die Kapazität der genutzten Verbindung an.
Wie stört Bufferbloat den Verkehr?
Vergleichen wir im Folgenden eine Verbindung über einen Highspeed Link und einer Verbindung über einen langsameren Link. In diesen Situationen erreichen die Puffer kritische Zustände. Angenommen wir nutzen eine 1 GBit/s schnelle Verbindung von einem Gateway via CATV-Kabel oder DSL zu einem Wohnhaus. Angenommen, das Gateway ist mit einer ISP-Verbindung verbunden, die in Download-Richtung 10 MBit/s und in Upload-Richtung 2 MBit/s überträgt. Der oben beschriebene FTP-Server füllt den Puffer über die schnelle Verbindung, schneller als die Senderate in Richtung des langsameren Uploads die empfangenen Pakete bestätigen kann. Letztendlich bestimmen die Bestätigungen (Acks) des langsameren Links den Gesamtdurchsatz der Verbindung. Wurden die Puffer jedoch zu groß gewählt, dann können mehrere Dinge auftreten: Wenn sich der Puffer füllt, kann das zuletzt ankommende Paket gelöscht werden. Dies wird als „tail drop“ bezeichnet. Die Bestätigung, die den Absender über das Verwerfen des Pakets informiert wird so lange nicht übermittelt, bis das nächste gültige Paket (welches nach dem verworfenen Paket ankommen muss) empfangen wird. Bei großen Puffern kann dies eine erhebliche Zeit in Anspruch nehmen. Experimente mit adaptivem Bitratenvideo zeigen, dass nahezu 200 Segmente empfangen wurden, bevor die sendende Station das verlorene Segment erneut übermittelte. Werden mehrere Verkehrsströme über eine Verbindung abgewickelt, dann entwickelt sich eine Art von permanenter Warteschlange. Eine nahezu feste Anzahl von Paketen befindet sich deshalb immer in der Warteschlange. Reichen diese Pakete nicht aus um den hierfür bereitgestellten Puffer zu überfüllen, werden keine Pakete verworfen und die TCP-Überlastungssteuerung wird nicht aufgehoben. Die Verzögerung aller Benutzer des Puffers wird sich jedoch dadurch erhöhen.
Puffer-Management
Eine Zeitlang wurden die Warteschlangen in den Netzwerken verwaltet. Zur Priorisierung bestimmter Verkehre können die Diffserv-Bits der IP-Schicht so genutzt werden, dass diese für bestimmten Verkehrstypen (beispielsweise Netzwerksteuerung oder VoIP) einen Vorzug bei der Übermittlung realisieren. Letztendlich wird durch die Diffserv-Bits eine Trennung der jeweiligen Verkehrstypen erreicht.
Aber dies beseitigte noch nicht Bufferbloat. Einige Warteschlangen, die für die Übermittlung der nicht priorisierten Verkehre zuständig waren, können weiterhin zu groß ausfallen. Diese enthalten daher viele große TCP-Segmente. Dadurch haben wir immer noch das Problem der negativen Auswirkungen auf den TCP-Überlastungsmechanismus.
Mehrere aktive Warteschlangenmanagementtechniken nutzen das RED- (Random-Early-Discard-)-und das WRED- (Weighted-RED-)Verfahren. Diese sorgen dafür, dass bestimmte Pakete verworfen werden, wenn der Puffer ein kritisches Niveau erreicht (aber noch nicht voll ist). Aber diese Techniken wiesen Fehler auf und das Konfigurieren von RED war schwierig. Folglich wurden die RED- und WRED-Mechanismen nicht weiter genutzt. Es wurde nach einer sich automatisch konfigurierenden Methode gesucht.
Im Jahr 2012 nutzten Kathie Nichols und Van Jacobsen eine Technik namens Controlling-Queue-Delay (CoDel). Diese Methode verwaltet eine Warteschlange und kontrollieren die Zeit, die sich ein Paket ist in der Warteschlange befindet. Hierfür gibt es zwei kritische Parameter: der Intervall und der Schwellwert. Dauert ein Intervallwert an Paketen länger als die eigentliche Verzögerungen zum Ziel, dann werden Pakete zufällig gelöscht. Diese Löschtechnik ist weder von der Größe der Warteschlange abhängig, noch erfolgt der Tail-Drop-Mechanismus. Tests dieses Verfahrens zeigen ein besseres Verzögerungsverhalten und weit bessere Ergebnisse als beim RED-Verfahren. Dies trifft insbesondere für drahtlose Zugangsverbindungen zu. Zudem versprach die CoDel-Technik eine einfache Realisierung in Hardware.
Das nächste Verfahren zur Milderung der Auswirkungen von Bufferbloat wurde von Dave Taht, Eric Dumazet und Jim Gettys vorgestellt und wurde „fq-codel Verfahren“ genannt. Dieses Verfahren hatte einen gleichmäßigeren Einfluss auf die verschiedenen Datenströme in den Warteschlangen. Die fq-codel-Methode teilt die Warteschlange standardmäßig in 1024 weitere Warteschlangen auf. Anschließend wird jedem neuen Datenfluss zufällig eine separate Warteschlange zugeordnet. Innerhalb jeder Sub-Warteschlange wird Codel genutzt, um bei TCP-Überlasten die Probleme zu beseitigen. Die verschiedenen Warteschlangen werden bei diesem Verfahren mit dem DRR- (Deficit-Round-Robin-)Mechanismus aufgelöst.
Was machen Codel und fq-codel?
Zunächst stellen die Verfahren sicher, dass die TCP-Überlastkontrolle ordnungsgemäß arbeitet. Darüber hinaus werden durch das Mischen der Pakete in den Warteschlangen kleine Pakete (beispielsweise DNS-Antworten und TCP-Acks) nicht mehr in großen Warteschlangen gefangen gehalten. Die Verarbeitung von großen Paketen und kleinen Paketen wird dadurch gerechter.
Wie geht es weiter?
Leider ist Bufferbloat noch immer weitgehend unbekannt. Das Internet benötigt mehr Benutzer, die eigenständige Tests zum Thema ausführen können. Beispielsweise steht der ICSI Netalyzr –Test unter http://netalyzr.icsi.berkeley.edu kostenlos zur Verfügung.
Vermuten Sie ein Bufferbloat-Problem in ihren Verbindungen, dann stehen zur Analyse mehrere Alternativen zur Verfügung:
- Ändern Sie die Access-Hardware und wechseln Sie auf ein Geräte mit einer neuen Linux-Distribution (welche auch fq-codel enthält). Stellen Sie sicher, dass diese Zusatzfunktion auch aktiviert ist.
- Platzieren Sie das Gerät mit der aktivierten fq-codel-Funktion zwischen ihrem Computer und dem genutzten Router. Dadurch wird die Verwendung großer Puffer im Router unterbunden.
- Wenn alle anderen Maßnahmen fehlschlagen, beschränken Sie die Durchsatzrate auf dem Up- und Down-Link knapp unterhalb der jeweiligen Nennkapazität. Dies beseitigt die großen Puffer. Sie bezahlen diese Maßnahme mit einer Verringerung des Durchsatzes bei geringer Last. Allerdings sollte sich die Datenflüsse von DNS-, ARP- und TCP-Acks drastisch verbessern
Es gibt mehrere Anbieter die stark an der Beseitigung der Bufferbloat-Effekte interessiert sind. Cisco hat in Zusammenarbeit mit Comcast eine Warteschlangenmanagement-Technik namens PIE (Proportional-Integral-Controller-Enhanced) implementiert. Ruckess Wireless engagiert sich darüber hinaus im Bereich der Access-Link-Pufferprobleme. Leider bieten die meisten Hersteller von Netzwerktestern keine Möglichkeiten zur Analyse von Bufferbloat.
