1. Einführung (Introduction)

Van Jacobsons Paketerhaltungsprinzip (packet conservation principle) [Jacobson88] definiert einen Selbsttaktungsprozess, bei dem N an den Empfänger gelieferte Datensegmente Bestätigungen erzeugen, die der Datensender als Takt verwendet, um das Senden weiterer N Datensegmente in das Netzwerk auszulösen.

Staukontrollalgorithmen wie Reno [RFC5681] und CUBIC [RFC9438] basieren auf der konzeptionellen Grundlage dieses Selbsttaktungsprozesses. Sie steuern den Sendeprozess einer Transportprotokollverbindung, indem sie ein Staufenster (congestion window, "cwnd") verwenden, um "inflight" zu begrenzen, das Datenvolumen, das eine Verbindung zu einem bestimmten Zeitpunkt als im Netzwerk im Flug befindlich schätzt. Darüber hinaus erfordern diese Algorithmen, dass Transportprotokollverbindungen ihr cwnd als Reaktion auf Paketverluste reduzieren. Schnelle Wiederherstellung (fast recovery) (siehe [RFC5681] und [RFC6675]) ist der Algorithmus zur Verwendung des Feedbacks von Bestätigungen, um diese cwnd-Reduzierung durchzuführen. Ihr erklärtes Ziel ist es, die Selbsttaktung des Senders aufrechtzuerhalten, indem sie sich auf zurückkehrende ACKs verlässt, um während der Wiederherstellung mehr Daten in das Netzwerk zu takten.

Ohne proportionale Ratenreduzierung (Proportional Rate Reduction, PRR) passt die schnelle Wiederherstellung das Fenster typischerweise an, indem sie auf den größten Teil einer Umlaufzeit (round-trip time, RTT) wartet (eine halbe RTT von ACKs für Reno [RFC5681] oder 30% einer RTT für CUBIC [RFC9438]), bevor sie Daten sendet.

[RFC6675] macht die schnelle Wiederherstellung mit Unterstützung für selektive Bestätigung (Selective Acknowledgment, SACK) [RFC2018] genauer, indem es "pipe" (die Schätzung des Senders der Anzahl noch ausstehender Bytes im Netzwerk) berechnet. Mit [RFC6675] wird die schnelle Wiederherstellung implementiert, indem Daten bei jedem ACK nach Bedarf gesendet werden, um pipe an ssthresh (die Zielfenstergröße, wie vom Staukontrollalgorithmus für die schnelle Wiederherstellung festgelegt) anpassen zu können. Dies schützt die schnelle Wiederherstellung in vielen Fällen, in denen es zu erheblichen Verlusten kommt, vor Zeitüberschreitungen. [RFC6675] hat jedoch zwei bemerkenswerte Mängel.

Erstens kann es zu einer Zeitüberschreitung kommen, wenn Daten oder ACKs für die gesamte zweite Hälfte des Fensters verloren gehen, da es zu Beginn der schnellen Wiederherstellung eine sehr große multiplikative Reduzierung von cwnd vornimmt. Zweitens kann ein einzelnes ACK mit SACK-Optionen, die eine große Menge fehlender Daten implizieren, dazu führen, dass der Pipe-Schätzer eine Sprungdiskontinuität aufweist, was dazu führen kann, dass bei der schnellen Neuübertragung ein Burst von Daten übertragen wird.

PRR reguliert den Übertragungsprozess während der schnellen Wiederherstellung so, dass diese übermäßigen Fensteranpassungen vermieden werden, sodass die Übertragungen reibungslos verlaufen und am Ende der Wiederherstellung die tatsächliche Fenstergröße so nah wie möglich an ssthresh liegt.

Der von PRR gewählte Ansatz wurde von Van Jacobsons Paketerhaltungsprinzip inspiriert. PRR verlässt sich so weit wie möglich auf den Selbsttaktungsprozess und wird nur schwach von der Genauigkeit von Schätzern beeinflusst, wie z. B. denen für die Menge der im Flug befindlichen Daten. Aus diesem Grund behält der Algorithmus seine Genauigkeit auch bei Ereignissen bei, die bei anderen Schätzern Unsicherheit verursachen.

Wenn inflight über ssthresh liegt, reduziert PRR inflight schrittweise auf ssthresh, indem es Übertragungen mit einer Rate taktet, die proportional zu den gelieferten Daten und ssthresh ist.

Wenn inflight unter ssthresh liegt, wählt PRR adaptiv zwischen zwei Reduktionsgrenzen (Reduction Bounds), um die gesamte Fensterreduzierung durch alle Mechanismen (einschließlich transienter Anwendungsstopps und der Verluste selbst) zu begrenzen. Als Baseline verwendet PRR seine konservative Reduktionsgrenze (Conservative Reduction Bound, CRB), um die Paketerhaltung strikt einzuhalten, zur Vorsicht, wenn es zu erheblicher Stauung kommen kann. Wenn die Wiederherstellung gut voranzuschreiten scheint, verwendet PRR seine Slow-Start-Reduktionsgrenze (Slow Start Reduction Bound, SSRB), die um höchstens ein Segment pro ACK aggressiver ist als PRR-CRB.

PRR-CRB erfüllt die starke Paketerhaltungsgrenze (Strong Packet Conservation Bound), die in Anhang A beschrieben wird; seine Leistung in tatsächlichen Netzwerken ist jedoch nicht so gut wie der in [RFC6675] beschriebene Algorithmus, der sich bei Verwendung als einziger Algorithmus in einer großen Anzahl von Fällen als aggressiver erwiesen hat. PRR-SSRB bietet einen Kompromiss, indem es einer Verbindung ermöglicht, in bestimmten Situationen ein zusätzliches Segment pro ACK im Vergleich zu PRR-CRB zu senden. Obwohl PRR-SSRB weniger aggressiv ist als [RFC6675] (weniger Segmente übertragen oder mehr Zeit benötigt, um sie zu übertragen), übertrifft es diesen aufgrund der geringeren Wahrscheinlichkeit zusätzlicher Verluste während der Wiederherstellung.

Die ursprüngliche Definition des Paketerhaltungsprinzips [Jacobson88] behandelte als verloren vermutete Pakete (z. B. als Kandidaten für die Neuübertragung markiert) als das Netzwerk verlassen habend. Diese Idee spiegelt sich im von PRR verwendeten Inflight-Schätzer wider, unterscheidet sich jedoch von der in Anhang A beschriebenen starken Paketerhaltungsgrenze, die nur auf der Grundlage der Daten definiert ist, die tatsächlich beim Empfänger angekommen sind.

Dieses Dokument spezifiziert mehrere wichtige Änderungen gegenüber der früheren Version von PRR in [RFC6937]. Erstens führt es eine neue adaptive Heuristik ein, die einen manuell konfigurierten Parameter ersetzt, der bestimmte, wie konservativ PRR sein würde, wenn inflight unter ssthresh liegt (ob PRR-CRB oder PRR-SSRB verwendet werden soll).

Zweitens spezifiziert der Algorithmus das Verhalten für Nicht-SACK-Verbindungen (Verbindungen, die keine SACK-Unterstützung [RFC2018] über die Option "SACK-permitted" ausgehandelt haben). Drittens gewährleistet der Algorithmus ein reibungsloses Senden auch in Fällen, in denen ein Sender eine hohe Neuordnung erfährt und die Verlustrestauration erst startet, nachdem ein erheblicher Sequenzraum SACKt wurde.

Schließlich enthält dieses Dokument auch zusätzliche Diskussionen über die Integration von PRR mit Staukontroll- und Verlusterkennungsalgorithmen.

PRR hat seit der ersten weit verbreiteten TCP-PRR-Implementierung im Jahr 2011 [First_TCP_PRR] umfangreiche Bereitstellungserfahrung in mehreren TCP-Implementierungen.