Der TCP (Transmission Control Protocol) Congestion Control Algorithmus (CCA) regelt, wie viele Daten zwischen Clients und Servern gesendet werden sollen, um die Nutzung der verfügbaren Bandbreite zu maximieren und Überlastungen zu vermeiden. Seit ihrer Gründung wurden andere CCAs entwickelt, wie Engpass Bandwidth, Round-Trip Propagation Time (TCP BBR) und CUBIC. Während TCP BBR und CUBIC darauf abzielen, Engpässe zu vermeiden, war es für unsere Engineering- und Forschungsteams eine ständige Aufgabe, ihre Effektivität zu verstehen.
TCP BBR zielt darauf ab, einen höheren Durchsatz zu erzielen, indem Paketverzögerung als Indikator anstelle von Paketverlust verwendet wird. Unsere früheren Untersuchungen haben jedoch gezeigt, dass BBR in allen Fällen schlecht abschneidet. Insbesondere kam unsere Bewertung zu dem Schluss, dass der Durchsatz für kleine Dateien (<100 KB) kaum bis gar nicht von Vorteil ist. Darüber hinaus beobachteten wir, dass die BBR-Leistung für Ströme mit niedriger Round-Trip-Zeit (RTT) und niedriger Retransmitts schlechter war als KUBISCH. Schließlich wurden die Vorteile von BBR nur für den Client-bezogenen Datenverkehr gesehen, während Back-Office-Verbindungen (niedrige RTT und vernachlässigbare Weiterübertragungen) mit CUBIC besser ablieferten.
Edgecast, heute Edgio, ist ein globales Multi-Tenant-CDN, das Webverkehr für viele große (VOD- und Live-) Video-Streaming-Kunden bereitstellt. Da die Optimierung der Überlastungskontrolle, die BBR für einen Kunden verwendet, die Leistung eines anderen Kunden beeinträchtigen kann und eine umfassende Aktivierung in einigen Szenarien zu Leistungseinbußen führen kann, haben wir einen Mechanismus implementiert, um Fälle zu erkennen, in denen BBR eine verbesserte Leistung bietet und diese dynamisch für alle CDN-Kunden aktivieren kann. Das Ergebnis ist eine neue, dynamische Tuning-Funktion für die Staukontrolle, die wir allen unseren Kunden zur Verfügung gestellt haben.
Einblicke in die Methodik
Der vielleicht wichtigste Input für solch ein dynamisches System sind die Daten, die es antreiben. Unser Optimierungsmechanismus für die dynamische Überlastungskontrolle steht auf unserer umfangreichen Socket-Datenerfassung, die TCP-(xTCP-)Socket-Performance-Daten aus allen Edge-Caches exportiert. Insbesondere extrahiert er über NetLink Informationen aus der tcp_Info-Struktur des Linux-Kernels und streamt sie über Kafka in einen ClickHouse-Cluster. Wenn wir diese Socket-Leistungsdaten skalieren, können wir die Leistung der Verbindungen zu unseren Cache-Servern mit sehr hoher Granularität überwachen. XTCP hat sich als leistungsstarkes Tool für viele CDN-Optimierungen erwiesen. So haben wir beispielsweise kürzlich unser anfängliches IPv6-Überlastungsfenster umgestellt und die Leistungssteigerungen mithilfe von xTCP überwacht.
XTCP ähnelt der Arbeit des tcp-Info-Tools von Google Measurement Lab (M-Lab). Wesentliche Unterschiede ergeben sich aus Optimierungen, die erforderlich sind, um die große Anzahl von Sockets zu verwalten, die von unseren Edge-Caches gesehen werden (im Vergleich zu M-Lab-Servern), und der Möglichkeit, die Daten im Protobuf-Format zu exportieren. Bleiben Sie auf dem Laufenden, wir planen, in Kürze xTCP-Open Source zu öffnen.
In der folgenden Abbildung sehen Sie eine Übersicht über unser System. XTCP-Daten werden skaliert aus allen unseren Edge-Caches gesammelt, die in Kafka gestreamt werden. Die xTCP-Daten werden dann in einem ClickHouse-Cluster erfasst, der unsere Netzwerkdatenanalyse unterstützt, einschließlich des BBR-Controllers, der die unzureichenden Präfixe an jedem Edge Pop erkennt.
Abbildung 1. Überblick über die Datenerfassung mit einem xTCP- und BBR-Konfigurationsstoß.
Wir möchten die Dynamik unseres Workflows beibehalten, müssen aber auch an jedem Edge Point of Presence (POP) Präfixe auswählen, um ein Flipflopping zwischen KUBIK und BBR über kurze Zeiträume zu vermeiden. Und wie bereits erwähnt, aktivieren wir BBR selektiv für Anforderungen, bei denen die Dateigröße größer als 100 KB ist. Ein fein abgestimmter KUBISCHER Fluss ist für kleine Dateien besser geeignet.
Der BBR-Controller verwendet zwei Metriken, um den Zustand jedes beobachteten Client-Präfixes zu bewerten:
- Arbeitszyklus: Wie lang war ein Präfix (/24 oder /56) in der unteren 20. Perzentilleistungsgruppe?
- Klappenrate: Wie oft erscheint und verschwindet das Präfix in der unteren 20. Perzentilleistungsgruppe, d. h. bei Statusänderung?
Der Algorithmus erkennt dann konsistent Präfixe mit schlechterer Leistung in den letzten Stunden. Diese Erkennung wird alle 5 Minuten durchgeführt. Während die Gesamtzahl der pro Edge Pop ausgewählten Präfixe Hunderte betragen könnte, haben wir festgestellt, dass die Präfixleistung relativ konsistent bleibt. Die gleichen Präfixe werden regelmäßig ausgewählt, und in jeder Runde sind nur wenige neue Ergänzungen (wie in der folgenden Abbildung aus dem Chicago Pop gezeigt) vorhanden.
Abbildung 2. Die Anzahl der neuen Präfixe, die pro Konfigurationsgenerierungsrunde ausgewählt wurden, ist niedrig.
Falls vorhanden, werden neue Präfixe ausgewählt, um BBR zu aktivieren, und eine Konfiguration wird generiert, durch einen Validierungsschritt übergeben und global in unsere Edge-Caches übertragen.
Leistungssteigerungen
Wir freuen uns, Ihnen mitteilen zu können, dass die weltweite Aktivierung von BBR zu erheblichen Leistungsverbesserungen geführt hat. Eine Schlüsselmetrik, die wir aus den xTCP-Socket-Daten verfolgen, ist die in TCP_INFO gemeldete Zustellungsrate. Da wir BBR für die am wenigsten leistungsfähigen Präfixe dynamisch aktivieren, erwarten wir, dass sich unsere niedrigere Perzentilausgaberate (Worst Case) verbessert.
Die folgende Abbildung zeigt die Verbesserung der Lieferrate des 5. Und 10. Perzentils bei unserem Los Angeles POP, sobald die BBR-Änderung aktiviert wurde.
Abbildung 3. Verbesserungen wurden bei der 5. Und 10. Perzentilrate nach Änderung der BBR beobachtet.
In ähnlicher Weise zeigen wir in der folgenden Abbildung eine erhebliche Verbesserung (~2x) der niedrigeren Perzentilzustellungsrate für einen großen privaten ISP in den USA, sobald wir BBR in allen unseren nordamerikanischen Pops dynamisch aktiviert haben.
Abbildung 4. Verbesserungen wurden bei einem großen ISP für Wohnzwecke beobachtet, nachdem BBR dynamisch aktiviert wurde.
Die aus TCP-Info extrahierte Übertragungsrate liefert eine gute Schätzung der vom Client ermittelten Performance. Der genaueste Leistungsindikator ist jedoch der Durchsatz, der in den HTTP-Zugriffsprotokollen für die Clientverbindung angezeigt wird, d. h. Goodput.
Wir messen den Goodput von einem Edge-Cache-Server. Wie die folgende Abbildung zeigt, führte die Änderung zu einem erhöhten Goodput. Insgesamt stieg der Goodput des zehnten Perzentils um 12 %.
Abbildung 5. Der Goodput des zehnten Perzentils stieg um 12 %.
Ein besonderer Dank gilt dem BBR-Entwicklungsteam bei Google für seine erstaunliche Arbeit an BBRv1 und seine fortgesetzten Bemühungen an BBRv2. Wir freuen uns auf BBRv2 und werden auch in Kürze relevante Änderungen an unserer Plattform vorantreiben. Ein Lob an Sergio Ruiz, Joseph Korkames, Joe Lahoud, Juan Bran, Daniel Lockhart, Ben Lovett, Colin Rasor, Mohnish Lad, Muhammad Bashir, Zach Jones und Dave Andrews bei Edgecast, die diese Veränderung während der Entwicklung, des Tests und des Rollouts unterstützt haben. Das Engineering-Team von Edgio möchte Dave Seddon besonders für seinen Beitrag zur Entwicklung des xTCP-Tools danken, das einen Großteil der Analyse ermöglicht hat.
Dank der dynamischen Optimierung der Engpasskontrolle profitieren Edgio-Kunden nun automatisch von Leistungsverbesserungen für ihre Kunden mit schlechter Leistung und verbessern ihre Betriebsergebnisse, was zu einer schnelleren Web-Bereitstellung und weniger Puffern für Video-Streamingführt.
