Engpass Bandwidth and Round-Trip Propagation Time (BBR) ist ein Algorithmus zur Kontrolle von TCP-Engpässen, der aufgrund seiner Fähigkeit, einen höheren Durchsatz zu erzielen, wie von vielen Content Providern berichtet, erhebliche Aufmerksamkeit auf dem Markt erlangt hat. In diesem Beitrag bewerten wir BBR (Version 1) im Kontext der CDN-Workloads (Content Delivery Network) von Verizon Media (jetzt Edgio), die erhebliche Mengen (mehrere Tbit/s) an Software-Updates und Video-Streaming bereitstellen, und quantifizieren die Vorteile und Auswirkungen auf den Datenverkehr. Wir hoffen, dass eine solche Bewertung in einem großen CDN anderen Content-Anbietern helfen wird, das richtige Protokoll zur Kontrolle von Engpässen für ihren Datenverkehr zu wählen.
Hintergrund
Viele Inhaltsanbieter und akademische Forscher haben herausgefunden, dass BBR einen höheren Durchsatz bietet als andere Protokolle wie TCP-Cubic. Im Gegensatz zu verlustbasierten Algorithmen zur Überlastungskontrolle, wie dem allgegenwärtigen TCP-Cubic, hat BBR ein anderes Operationsparadigma: Es aktualisiert kontinuierlich, wie viele Daten im Flug sein können, basierend auf der minimalen RTT, die die Sitzung bisher gesehen hat, um Pufferbloat zu vermeiden. Weitere Informationen zum Betrieb von BBR finden Sie in der Originalveröffentlichung von Google hier.
Messungen und Analysen
Um das Potenzial für BBR in unserem CDN zu verstehen, haben wir BBR in mehreren Phasen evaluiert und die Auswirkungen auf TCP-Ströme von einigen Points of Presence (POPs) gemessen. POPs stellen eine Konzentration von Caching-Servern dar, die sich in großen U-Bahn-Bereichen befinden. Anfangs führten wir einen kleinen BBR-Test bei einem POP durch und führten auch einen vollständigen POP-Test durch, wobei alle Ströme zu den Kunden führten, die BBR ausführen. Um die Vorteile für Kunden zu ermitteln, haben wir den Durchsatz unserer internen Proxying-Webserver-Protokolle während des Tests sowie Analysen auf Socket-Ebene gemessen.
Auszuwertende Metriken
Unser mandantenfähiges CDN erkennt eine große Vielfalt an Client-Datenverkehr. Viele Kunden haben viele kleine Objekte, während andere viel größere Objekte mit mehreren Gigabyte haben. Daher ist es wichtig, Erfolgskennzahlen zu identifizieren, die die tatsächlichen Leistungssteigerungen über verschiedene Datenverkehrsmuster hinweg erfassen. Insbesondere für diese Bewertung haben wir den Durchsatz und die Abschlusszeiten des TCP-Flusses als Erfolgsparameter identifiziert. In Abbildung 1 zeigen wir eine Heatmap mit allgemeinen Objektgrößen, die vom CDN angefordert werden, im Vergleich zu der Zeit, die für die Bereitstellung dieser Objekte benötigt wird. Der Farbverlauf gibt die Anzahl der Anforderungen in jeder Kategorie an. Dies sind repräsentative Zahlen von einem kleinen Satz von Servern, die nur das allgemeine Verhalten erfassen.
Abbildung 1. Heatmap mit gemeinsamen Objektgrößen.
Die Heatmap gibt uns ein Verständnis der verschiedenen Anforderungsmuster. Im Allgemeinen ist ein höherer Durchsatz der beste Indikator für eine Leistungssteigerung. Der Durchsatz als Messung kann jedoch sehr verrauscht sein, insbesondere in Fällen, in denen die Objektgröße klein ist (weniger als einige MB). Daher verwenden wir auf der Grundlage einer separaten Bewertung, welche Größen die zuverlässigste Bewertung des Durchsatzes bieten, nur Objektgrößen von mehr als 3 MB für Durchsatzauswertungen. Bei Objektgrößen unter 3 MB ist die Nachverfolgung der Abwicklungszeiten eine bessere Kennzahl.
Als ersten Schritt unserer Evaluierung haben wir BBR auf einigen Servern in einem POP in Los Angeles aktiviert und Durchsatz und Durchlaufzeiten für alle TCP-Flows überwacht. In den folgenden Ergebnissen werden einige spezifische Fallstudien für Internetdienstanbieter untersucht.
Ein großer Mobilfunkanbieter
Abbildung 2 zeigt den Unterschied nach dem Einschalten des BBR.
Abbildung 2. Auswirkungen auf den Durchsatz bei Clients eines großen Mobilfunkanbieters bei eingeschaltetem BBR (Test) im Vergleich zu kubischen Strömen (Steuerung). Links: Durchsatzmessungen über zwei Tage. Die vertikale blaue Linie zeigt an, wann BBR aktiviert wurde. Hier sehen wir eine Gesamtverbesserung von etwa 6-8% mit BBR. Rechts: Eine CDF des 5. Perzentildurchsatzes. BBR-Ströme zeigen eine deutliche Verbesserung.
Bei diesem Mobilfunkanbieter konnte der Durchsatz, sobald wir BBR aktiviert haben, durchschnittlich um 6 bis 8 % verbessert werden. Insgesamt konnten wir auch niedrigere TCP-Durchlaufzeiten feststellen. Diese Feststellung stimmt mit anderen Berichten von Spotify, Dropbox und YouTube überein, in denen in drahtlosen Netzwerken, in denen Paketverluste häufig vorkommen, ein deutlicher Durchsatzgewinn zu verzeichnen ist, dies aber nicht unbedingt ein Indikator für Überlastung ist.
Ein großer Anbieter von drahtgebundenen Leitungen
Als Nächstes haben wir die Leistung eines großen Kabelnetzanbieters untersucht. Auch hier konnten wir sowohl Durchsatz (für große Objekte) als auch Durchlaufzeit (siehe Abbildung 3) mithilfe von BBR verbessern.
Abbildung 3. Die durchschnittliche Zeit, die für den Abschluss eines Datenflusses für einen großen drahtgebundenen Anbieter benötigt wird. BBR-(Test-)Flows zeigen weniger Jitter und benötigten weniger Zeit, um die Datenübertragung abzuschließen. Die Vorteile sind bei größeren Objekten wirkungsvoller. Bei großen Dateigrößen sehen wir jedoch einen ähnlichen Jitter sowohl für Cubic als auch BBR.
Die durch diese Tests gemeldeten Gewinne zeigen sehr vielversprechende Ergebnisse für den clientseitigen Datenverkehr.
Da sich diese Vorteile auf einer aggregierten Ansicht befinden, haben wir beschlossen, etwas tiefer zu gehen, um zu prüfen, ob alle TCP-Flows am POP den Vorteil der Verwendung von BBR sahen oder ob einige TCP-Flows darunter litten und welche?
Am CDN-Edge führen wir vier verschiedene Arten von TCP-Sitzungen durch:
- Pop-to-Client (wie oben gezeigt)
- Pop-to-Pop (zwischen Rechenzentren)
- Intra-POP-Kommunikation (zwischen den Caches desselben POP)
- POP-to-Origin (POP-to-Customer Origin Datacenter)
Für diese Studie haben wir Pop-to-Client, Pop-Pop und Intra-Pop-Flüsse berücksichtigt, da Edge-to-Origin nicht so groß ist wie die anderen drei.
Pop-to-Pop- und Intra-Pop-Traffic
Es ist wichtig, auch die Auswirkungen auf diese TCP-Flows zu bewerten, da diese Flows in vielen Fällen Blocker für die Client-Bereitstellung sind, z. B. für dynamische Inhalte.
Beim Durchsatz von Pop-to-Pop- und Intra-Pop-Traffic wurde ein großer Leistungsrückgang festgestellt. Abbildung 4 zeigt die Auswirkungen auf Intra-Pop- und Pop-to-Pop-Traffic während desselben Zeitraums:
Abbildung 4. Auswirkung auf den Durchsatz bei Intra-Pop- und Pop-to-Pop-Verkehr bei eingeschaltetem BBR (Test) im Vergleich zu kubischen Strömen (Kontrolle). Durchsatzmessungen über zwei Tage. Die vertikale blaue Linie zeigt an, wann BBR aktiviert wurde. Der Durchsatz sank mit BBR um etwa die Hälfte.
Solche eindeutigen Leistungsunterschiede zwischen den Datenflüssen an Endbenutzer und zwischen Rechenzentren wurden in früheren Ergebnissen nicht berichtet. Wir müssen herausfinden, warum diese speziellen TCP-Flows betroffen sind, ob dies ein Artefakt der Hardware oder der Konfigurationen auf unserem CDN ist und wenn ja, welche Optimierungen geändert werden müssten.
Aus weiteren Untersuchungen unter Verwendung von Webserver-Zugangsprotokollen und Auswertungen von serverseitigen Socket-Daten ergab sich, dass die TCP-Ströme, die sehr niedrige RTT aufweisen, unter der Verwendung von BBR litten. Wir bewerteten Fälle, in denen weniger als 0,5 KB an Daten übertragen wurden, und stellten fest, dass BBR in den meisten Fällen ähnlich wie Cubic ablief.
Auf der Grundlage dieser Ergebnisse kamen wir zu dem Schluss, dass es für unsere Verkehrsmuster besser ist, Cubic für Intra-Pop- und Pop-to-Pop-Kommunikation zu verwenden, bei der RTTs und Verluste gering sind. Für den clientseitigen Datenverkehr lohnt sich die Verwendung von BBR.
Vollständiger POP-Test
Um den Leistungsvorteil von BBR in großem Maßstab zu bewerten, haben wir bei einem POP in Rio de Janeiro einen vollständigen POP-Test für den gesamten Kundenverkehr aus unserem Netzwerk an diesem POP durchgeführt. Dieser POP war eine interessante Fallstudie, da die Standortbedingungen und Peering-Einschränkungen in der Region zu höheren Medianen RTTs führen als in anderen Regionen.
Abbildung 5. Durchsatzverbesserung mit BBR für den Kunden, DA hohe Reübertragungen (ASN1) gezeigt werden.
Wir implementierten die Änderung des Algorithmus zur Kontrolle von Engpässen und überwachten die Leistung. Es wird eine CDF des Durchsatzes gezeigt, der mit BBR im Vergleich zu kubisch für die beiden größten ASEs (Autonomous Systems) in Rio beobachtet wurde. Wie in Abbildung 5 zu sehen ist, sah eine AS insgesamt den Nutzen von BBR, während eine andere nicht.
Um die Gründe dafür zu untersuchen, haben wir nach anderen TCP-Metriken gesucht, die während des Tests mit dem Dienstprogramm ss erfasst wurden. Eine klare Unterscheidung ist in der Wiederholungsrate zwischen diesen beiden ASEs zu erkennen. Selbst bei ASEs mit höheren RTTs ist BBR nur in Fällen mit einer hohen Anzahl von Wiederholübertragungen gut, d. h. bei ASEs mit weniger Verlusten hat Cubic keinen Grund, sich zurückzuziehen und liefert bessere Ergebnisse als BBR. Es ist jedoch wichtig zu beachten, dass viele der Parameter von TCP Cubic sorgfältig auf unserem CDN abgestimmt wurden.
Als Nächstes wurde untersucht, ob alle Verbindungen des ASN1, wie in Abbildung 5 gezeigt, eine Verbesserung des Durchsatzes zeigten. Abbildung 6 ist eine Darstellung der Zeit (niedriger bedeutet besseren Durchsatz), die BBR- und kubische Verbindungen für verschiedene Objektgrößen benötigen. Hier sehen wir, dass BBR erst bei größeren Objekten in der Reihenfolge der MB bemerkenswerte Vorteile zeigte. Wir haben eine anomale Instanz mit BBR gesehen, konnten sie aber nicht auf ein bestimmtes Problem im Zusammenhang mit dem Engpasskontrollprotokoll zurückführen.
Abbildung 6. Bei ASEs, die Verbesserungen aufweisen, zeigt sich der Vorteil von BBR bei langen Datenflüssen mit großen Dateien.
Warum geschieht das?
Diese Ergebnisse haben zwei Dimensionen: Kubisch vs. BBR und BBR vs. BBR.
Kubisch vs. BBR
BBR reagiert stark auf Puffergrößen und RTT, wenn Engpassbandbreite geschätzt wird. Bei großen Puffern, bei denen Middleboxen eine Warteschlange bilden könnten, erhöht sich die geschätzte RTT von BBR. Da es keinen Paketverlust gibt, wird Cubic in solchen Fällen nicht zurückgehalten, d. h. im Pop-to-Pop-Verkehr, und Cubic erzielt daher einen höheren Durchsatz. Bei kleinen Puffern, wie z. B. drahtlosen Clients, füllt sich der Puffer schnell und führt zu einem Verlust. Dadurch werden kubische Flows wieder abgeleitet, und BBR-Flows funktionieren besser.
BBR vs. BBR
In diesem Szenario wird bei einem Verlust kein Fluss zurückgestellt. Wenn jedoch zwei Flüsse mit unterschiedlichen RTT um einen Anteil der Bandbreite konkurrieren, hat der Fluss, der eine höhere RTT hat, auch eine größere minimale RTT und somit ein Produkt mit höherer Bandbreitenverzögerung. Somit erhöht dieser Fluss seine Borddaten mit einer viel schnelleren Rate als der Fluss, der eine niedrigere RTT hat. Dies führt zur Umverteilung der Bandbreite an die Flüsse in absteigender Reihenfolge von RTTs, und Flüsse mit höheren RTTs füllen Puffer schneller als Flüsse mit kleinen RTTs.
Reproduzieren von Ergebnissen in einer Laboreinstellung
Um ein besseres Verständnis der Interaktionen zwischen Flüssen zu entwickeln, haben wir eine Testumgebung in virtuellen Maschinen erstellt, die das Verhalten in der Produktion erfasst. Wir haben wie folgt Möglichkeiten zur Simulation verschiedener Verkehrsklassen auf einem Edge-Server identifiziert:
Die Verzögerung des Client-Datenverkehrs wurde auf ~50 ms mit Verlusten zwischen 0,001 und 0,1 und einer Engpassbandbreite von 50 Mbit/s eingestellt. In ähnlicher Weise wurden für Pop-to-Pop nur Verlust und Verzögerung auf ~15 ms und 0,0001 auf 0,01 eingestellt. Für Intra-POP-Datenverkehr lassen wir die verfügbare Kapazität der VMs maximal ausschöpfen. Schließlich wurden Simulationen mit verschiedenen Objektgrößen ausgeführt, um den Multi-Tenant-Charakter unseres Datenverkehrs zu erfassen. Wir führen alle drei Verkehrsmuster parallel zu einer exponentiellen Ankunft von Strömen durch, um eine poisson-ähnliche Verteilung der Strömung zu erfassen. Abbildung 7 zeigt die Einrichtung des Testbetts.
Ziel dieses Tests war es, die Probleme zu reproduzieren, die wir in Produktionstests sehen, insbesondere den Durchsatzabfall bei kleinen RTT-Flows für Intra-Pop-Traffic und Pop-to-Pop.
Abbildung 7. Laboreinrichtung mit den Dienstprogrammen KVM, iperf, netem und tc.
Mit diesem Setup haben wir die Simulation hundertmal mit simuliertem Hintergrundverkehr ausgeführt, sowohl kubisch als auch BBR, und die Zeit gemessen, die zum Abschluss der Ströme benötigt wurde. Ziel des Hintergrundverkehrs ist es, eine produktionsähnliche Umgebung zu simulieren. Viele bestehende Studien konzentrierten sich auf die Durchführung einiger kubischer und BBR-Ströme und die Bewertung ihres Verhaltens. In diesen Fällen ist es zwar nützlich, das Verhalten pro Fluss zu verstehen, aber es repräsentiert die Komplexität eines großen CDN mit hohem Volumen nur unzureichend. Wir haben die Zeit für den clientseitigen Ablauf als zuverlässigen Indikator verwendet, da der Durchsatz bei kleinen Dateigrößen zu verrauschen ist.
Abbildung 8. Zeit, die iperf-Flows benötigen. Links: Clientflüsse. Rechts: Pop-to-Pop-Flows. Objektgröße: 3 MB. BBR hat sich bei simulierten Client-Flows besser als Cubic entwickelt.
Wir sahen das Muster auch wieder in unserem Testbett. In Abbildung 8 wird ein CDF der Zeit dargestellt, die BBR- und Cubic iperf-Flows in zwei Szenarien benötigt haben: Client-Datenverkehr und Pop-to-Pop-Datenverkehr für 3 MB (mittlere Größe) Dateien. BBR-Ströme können bei verlustarmer Konfiguration mit hoher Bandbreite nicht auf den Cubic-Wert zurückgreifen. Der Client-Datenverkehr (geringe Bandbreite) konnte verbessert werden, d. h. die Zeit, die BBR-Flows benötigt, war geringer. Verbesserungen bei kleinen Dateien sind jedoch nur geringfügig. Die Reproduktion dieser Verhaltensweisen in der Testumgebung gibt uns die Gewissheit, dass sie das Ergebnis der Interaktion zwischen verschiedenen Strömungsarten sind. Daher muss sich jeder Einsatz von BBR auf dem CDN bewusst sein, welche weiteren Auswirkungen es auf eine Mischung von Strömungsarten haben kann.
Schlussfolgerung
Aus unserer Bewertung ergab sich, dass BBR-Ströme nicht in allen Szenarien gut abschneiden. Insbesondere der Datenverkehr innerhalb eines Rechenzentrums/Point-of-Presence (POP) und der Datenverkehr zwischen Rechenzentren (POP-to-POP) wurde bei der Verwendung von BBR beeinträchtigt. In einigen extremen Fällen wird der Durchsatz um die Hälfte reduziert. Wir konnten jedoch eine Verbesserung des Durchsatzes von Pop-to-Client-Datenverkehr um 6 bis 8 % feststellen.
In diesem Beitrag haben wir die Bewertung von BBR (Version 1) im Kontext unseres CDN erläutert. Wir begannen mit einem kleinen Test von einigen Servern in einem einzigen POP und evaluierten verschiedene Variablen, die für uns als großen Content Provider von Interesse sind. In einem umfangreichen, vollständigen POP-Test haben wir festgestellt, dass BBR bei ASEs, bei denen die erneuten Übertragungen hoch sind, am meisten hilfreich ist. Daher ist es sinnvoll, BBR für große Dateien zu verwenden.
Wohin gehen wir von hier?
Wenn wir BBR auf Systemebene aktivieren (alle Flüsse), besteht die Gefahr, dass der Durchsatz des Intra-Pop- und Pop-to-Pop-Verkehrs sinkt.
BBR hat jedoch Potenzial gezeigt und ist für den clientseitigen Datenverkehr gut geeignet. Dies motiviert uns, BBR für Kunden selektiv zu aktivieren, möglicherweise beginnend mit Wireless Providern. Darüber hinaus verfügen diese Pfade über flache Puffer und WLAN-Verluste, was eine ideale Situation für BBR ist, um besser als andere kubische Ströme zu funktionieren.
Wir hoffen, dass dieser Entwurf etwas Klarheit über die Nutzung von BBR bei großen Inhaltsanbietern und seine Auswirkungen auf verschiedene Arten von Datenverkehr bringt, die möglicherweise gemeinsame Engpässe haben. Die Alpha-Version von BBRv2 ist jetzt verfügbar, mit der einige dieser Probleme behoben werden sollten. Wir planen, die Evaluierung neuerer Versionen von BBR fortzusetzen und eine intelligente Transportsteuerung zu verwenden, die die richtige Staukontrolle für die richtige Art von Fluss auswählt. Wir werden in Zukunft weitere Einzelheiten dazu mitteilen.
Dank des Beitrags verschiedener Teams im gesamten Unternehmen, der diese Analyse ermöglicht hat!
