4. Änderungen gegenüber RFC 6937 (Changes Relative to RFC 6937)

Die größte Änderung seit [RFC6937] ist die Einführung einer neuen Heuristik, die guten Wiederherstellungsfortschritt (für TCP, wenn das neueste ACK SND.UNA vorantreibt und nicht anzeigt, dass eine vorherige Fast Retransmit verloren ging) verwendet, um die Reduktionsgrenze (PRR-CRB oder PRR-SSRB) auszuwählen.

[RFC6937] überließ die Wahl der Reduktionsgrenze dem Ermessen des Implementierers, empfahl aber die Verwendung von PRR-SSRB als Standard. Für alle in der früheren PRR-Forschung untersuchten Umgebungen ist die neue Heuristik mit der alten Empfehlung konsistent.

Einführung der SafeACK-Heuristik

Das Papier „Internet-weite Analyse des Traffic Policing" [Flach2016policing] entdeckte einen zuvor unerforschten kritischen Fall, in dem beide Reduktionsgrenzen schlecht funktionieren, aber aus unterschiedlichen Gründen.

Herausforderung der Token-Bucket-Policer

In vielen Konfigurationen können Token-Bucket-Traffic-Policer plötzlich beginnen, den größten Teil des Verkehrs fallen zu lassen, wenn die Token erschöpft sind, ohne dass die Endsysteme gewarnt werden. Die Transportstaukontrolle hat keine Gelegenheit, die Token-Rate zu messen und ssthresh basierend auf zuvor beobachteter Pfadleistung zu setzen. Dieser ssthresh-Wert kann zu einer Datenrate führen, die weit über der Token-Nachfüllrate liegt, was zu hohen Paketverlustrat führt.

Unter diesen Bedingungen funktionieren beide Reduktionsgrenzen schlecht:

• PRR-CRB ist zu konservativ - führt manchmal zu einer sehr langen Wiederherstellung mit einem viel kleineren Fenster als nötig
• PRR-SSRB ist zu aggressiv - führt oft zu mehreren Runden verlorener Neuübertragungen, wobei beide Fälle zu verlängerten Wiederherstellungszeiten führen, die die Anwendungslatenz und/oder den Durchsatz stark beeinträchtigen

SafeACK-Lösung

Die Untersuchung dieser Umgebungen führte zur Entwicklung der „SafeACK"-Heuristik zum dynamischen Wechseln der Reduktionsgrenze:

• Standard PRR-CRB - Wiederherstellung konservativ beginnen
• Bedingung zum Wechsel zu PRR-SSRB - nur wenn ein ACK anzeigt, dass die Wiederherstellung gut voranschreitet (SND.UNA schreitet voran und kein neuer Paketverlust erkannt)

Die SafeACK-Heuristik wurde im Content Distribution Network (CDN) von Google [Flach2016policing] experimentiert und ist seit 2015 in Linux TCP implementiert.

Anwendungsszenarien

Die SafeACK-Heuristik wird nur aufgerufen, wenn:

• Paketverlust, anwendungsbegrenztes Verhalten oder andere Ereignisse dazu führen, dass die aktuelle Schätzung der übertragenen Daten unter ssthresh fällt
• Hohe Paketverlustrat die Heuristik kritisch machen, was nur bei schweren Paketverlusten häufig ist, wie z.B. Traffic Policer [Flach2016policing]
• In diesen Umgebungen übertrifft die Heuristik die Verwendung einer der beiden Grenzen allein