Fairer Internet-Verkehr: Google will fremde Streams nicht mehr kannibalisieren
Ein Großteil des Internet-Verkehrs gründet auf einem TCP-Standard. Mit einer eigenen Methode bremst Google jedoch fremde Downloads einfach aus.
Jede Millisekunde Verzögerung beim Datentransport ist aus Sicht von Google eine Millisekunde zu viel – insbesondere, wenn sie vermeidbar ist. Mit der hauseigenen Staukontrolle Bottleneck, Bandwidth and Roundtrip Propagation Time (BBR) will der Konzern die klassische TCP-Staukontrolle (congestion control) revolutionieren und insbesondere die Kapazitäten von Hochgeschwindigkeitsstrecken besser ausschöpfen. Bloß geht das – wie eine Reihe von Forschern gezeigt hat – auf Kosten aller anderen. Nun rudern die BBR-Verfechter vorsichtig zurück.
Bei der klassischen TCP-Steuerung erhöht der Server seine Sendegeschwindigkeit allmählich. Genauer: Er erhöht die Anzahl der abgeschickten Pakete, die der Empfänger noch nicht quittiert hat (das congestion window wächst). Dabei orientiert er sich an der Geschwindigkeit, mit der Quittungen des Empfängers bei ihm eingehen, um die Geschwindigkeit an die aktuelle Streckenkapazität anzupassen (ACK-clocking). Paketverluste wertet der Sender als Indiz für einen oder mehrere überlastete Router auf der Strecke und macht dann langsamer. Je höher die Paketverlustrate, desto häufiger drosselt der Server seine Sendegeschwindigkeit.
Dieses Prinzip funktioniert seit den Anfängen des Internet zuverlässig und wurde seitdem in vielen Punkten verfeinert, aber letztlich beibehalten. Inzwischen zeigen Messungen aber, dass man damit die Kapazitäten von superschnellen Leitungen nicht mehr ausschöpfen kann. Teile der Kapazitäten bleiben ungenutzt, weil das congestion window nach einer Drosselung zu langsam wächst.
Googles Forschungsgruppe rund um Neal Cardwell, Yuchung Cheng und Van Jacobson setzt an der Rückkopplung zwischen Paketverlust und Drosselung der Senderate an: Diese Messung sei viel zu ungenau. Denn die Verlustmeldungen des Empfängers sind nicht aktuell, wenn sie beim Sender ankommen, sondern eben mindestens eine halbe Round-Trip-Time (RTT) alt. Schon bei kurzen Strecken summiert sich der Verzug auf 10 Millisekunden und mehr, bei Interkontinentalstrecken gehen die Werte schnell über 50 und 100 ms hinaus. Zusätzlich können bestimmte Puffer-Konstellationen das Bild des laufenden Verkehrs verzerren. Und auf drahtlosen Übertragungsstrecken (WLAN, Mobilfunk, Richtfunk, etc.) gehen Pakete auch ohne Stausituation leicht verloren.
Aggressives Probing und die Folgen
Deshalb orientieren sich die BBR-Macher beim Einstellen der Sendegeschwindigkeit hauptsächlich an der beobachteten Empfangsrate der Pakete und erhöhen stur die Senderate, auch wenn Pakete verloren gehen (natürlich liefern sie die auf Verlangen des Empfängers wie üblich nach). BBR ermittelt also erstmal eine Senderate und sendet dann mit dieser blind weiter. Paketverluste, die ja eine Überlastsituation signalisieren können, ignoriert BBR grundsätzlich. Dabei nimmt die Methode kurzerhand an, dass noch Kapazität übrig ist, wenn eine Steigerung der Senderate zu einer Steigerung der gemessenen Empfangsrate führt. Einzelheiten hat die BBR-Arbeitsgruppe unter anderem in diesem PDF veröffentlicht.
Das funktioniert prima – aber nur, solange auf der Strecke nur diese eine Übertragung läuft. Deshalb nutzt ein einzelner BBR-Stream die Kapazität einer Strecke tatsächlich weit besser als herkömmliche TCP-Steuerungen. Das bestätigen auch Messungen von Geoff Huston, Chefwissenschaftler des APNIC, und Roland Bless vom Karlsruhe Institute of Technology. Wenn sich aber mehrere Datenströme zumindest einen Teil der Strecke teilen (was in Realität fast immer der Fall ist) und jeder einzelne BBR-Datenstrom seine Senderate auch dann noch erhöhen will, wenn die physische Kapazität ausgeschöpft ist, dann geht das nur noch auf Kosten der anderen.
Deshalb kannibalisieren sich dann auch parallele BBR-Übertragungen gegenseitig. In einem Test konnte einer der Sender mit BBR-Steuerung 90 Prozent der Kapazität für sich gewinnen, während der ebenfalls per BBR arbeitende Konkurrent lediglich die restlichen 10 Prozent der Datenrate bekam. Unterm Strich muss man sagen: Google hat es etwas übertrieben, den Paketverlust als Stausignal komplett zu ignorieren.
Höflichkeitsregeln
BBR-Entwickler Cardwell kündigte unter anderem deshalb auf dem 102. IETF-Meeting in Montreal an, an einer kooperativeren BBR-Variante zu arbeiten. Und das geht nicht anders, als Paketverluste und die standardmäßig vorgesehenen Explicit Congestion Notifications (ECN) zu berücksichtigen. Zusätzlich werde BBR die Senderate "weniger drastisch" hochtreiben.
So soll die kommende Version BBR 2 anderen Übertragungen Luft zum atmen lassen. Als neue Messparameter werden Inflight-Lo(w) und Inflight-Hi(gh)-Werte eingeführt. Der untere Wert soll, basierend auf ECN und Paketverlustraten, BBR mäßigen. Der obere Wert soll als Trigger dienen, um zum aggressiveren Probing zurückzukehren.
Wie weiter?
"Das klingt ganz gut", sagt Geoff Huston in einer ersten Reaktion, mahnt aber auch: "Solange man die Veränderungen nicht messen kann, bleibt eine abschließende Beurteilung schwer". Der Australier schätzt, dass BBR weiterhin zu sechs Achteln im gierigen Blindflug unterwegs ist, also nicht rechts und links nach Opfern schaut. Die Spannung zwischen Kooperation mit anderen TCP-Flows und Maximierung der eigenen Datenrate wird auch in BBR 2 bleiben, denn die Maximierung macht die Besonderheit dieses Verfahrens aus.
Auch Roland Bless vom KIT bleibt skeptisch. Das Modell ist aus seiner Sicht problematisch. "Ob es besser wird, wenn man hier und da an einzelnen Stellschrauben nachjustiert, ist fraglich", sagt er. Zudem bleibe BBR 1 erst einmal die Variante, an die man sich halten müsse. Sie ist in Entwürfen für die Standardisierung bei der IETF dokumentiert. Sie wird für TCP- und QUIC-Verkehr auf google.com, YouTube, im Google-Backbone sowie Googles Cloud Platform bereits eingesetzt.
"BBR 2 ist noch eine Blackbox", sagt Bless, "da weder eine zusammenhängende Beschreibung noch Code öffentlich verfügbar ist". Und Jana Iyengar, der Vorsitzende der IETF-Arbeitsgruppe zur TCP-Steuerung, ermahnte Caldwell und Swett, sie sollten die BBR-2-Spezifikation bitte veröffentlichen. Caldwell sagt das zwar zu, schränkt aber noch ein: "Das wollen wir erst dann tun, wenn wir den neuen Code selbst gründlich ausprobiert haben". (dz)
