9. Anpassung von PRR an andere Transportprotokolle
Der Haupt-PRR-Algorithmus und die Reduktionsgrenzen können an jedes Transportprotokoll angepasst werden, das [RFC6675] unterstützen kann. In einer wichtigen Implementierung (Linux TCP) ist PRR seit seiner Einführung im Jahr 2011 der Fast-Recovery-Algorithmus für seine Standard- und unterstützten Staukontrollmodule [First_TCP_PRR].
Die SafeACK-Heuristik kann auf jedes ACK für eine Neuübertragung verallgemeinert werden, das nicht dazu führt, dass ein anderes Segment zur Neuübertragung markiert wird.
10. Messstudien (Measurement Studies)
Für [RFC6937] bewertete ein Begleitpapier [IMC11] [RFC3517] und verschiedene experimentelle Versionen von PRR in groß angelegten Messstudien. Zum Zeitpunkt der Veröffentlichung existierten die in der Studie verwendeten Legacy-Algorithmen nicht mehr in den für die Studie verwendeten Codebasen, was solche Vergleiche ohne Neuerstellen historischer Algorithmen schwierig macht.
Leser, die sich für Messstudien interessieren, sollten Abschnitt 5 von [RFC6937] und das IMC-Papier [IMC11] konsultieren.
11. Betriebliche Überlegungen (Operational Considerations)
11.1. Inkrementelle Bereitstellung (Incremental Deployment)
PRR ist inkrementell einsetzbar, da es nur vorhandene Transportprotokollmechanismen nutzt, um die Datenzustellung zu bestätigen und verlorene Daten zu erkennen.
Bereitstellungsanforderungen:
- PRR erfordert nur Änderungen an der Transportprotokollimplementierung des Datensenders
- Keine Änderungen am Datenempfänger erforderlich
- Keine Änderungen am Netzwerk erforderlich
Dies ermöglicht es Datensendern, die PRR verwenden, korrekt mit jedem vorhandenen Datenempfänger oder Netzwerk zu arbeiten. PRR erfordert keine Änderungen oder Unterstützung von Routern, Switches oder anderen Geräten im Netzwerk.
11.2. Fairness
PRR zielt darauf ab, die Fairness-Eigenschaften des Staukontrollalgorithmus beizubehalten, mit dem es eingesetzt wird.
Funktionsweise:
- PRR läuft nur während einer Staukontroll-Antwortphase (wie Fast Recovery oder eine cwnd-Schritt-Reduktion aus einer TCP-ECN-Reaktion, die in [RFC3168] definiert ist)
- Trifft nur kurzfristige Entscheidungen pro Bestätigung, um die Menge der übertragenen Daten während der Regulierungsphase reibungslos zu regulieren
- So dass sie am Ende der Phase dem vom Staukontrollalgorithmus bestimmten Slow-Start-Schwellenwert (ssthresh) so nahe wie möglich kommt
Nicht geänderte Mechanismen:
- PRR ändert keine Mechanismen zur Erhöhung oder Verringerung des Staukontroll-cwnd außerhalb von Staukontroll-Antwortphasen
11.3. Schutz des Netzwerks vor übermäßiger Warteschlange und Paketverlust
Langfristige Auswirkungen
Auf langen Zeitskalen zielt PRR darauf ab, die Warteschlangen- und Paketverlust-Eigenschaften des Staukontrollalgorithmus beizubehalten, mit dem es eingesetzt wird.
Wie oben beschrieben, läuft PRR nur während einer Staukontroll-Antwortphase (wie Fast Recovery oder Antwort auf ECN) und trifft nur kurzfristige Entscheidungen pro Bestätigung, um die Menge der übertragenen Daten während der Regulierungsphase reibungslos zu regulieren, so dass sie am Ende der Phase dem vom Staukontrollalgorithmus bestimmten Slow-Start-Schwellenwert (ssthresh) so nahe wie möglich kommt.
Kurzfristige Auswirkungen
Auf kurzen Zeitskalen zielt PRR darauf ab, niedrigere Paketverlustrat als vorhergehende Ansätze wie [RFC6675] zu erzielen.
Vorteilsprinzip:
- PRR ist vom Prinzip der Paketerhaltung inspiriert
- Verlässt sich wo immer möglich auf selbst getaktete Prozesse
- Mit [RFC6675] kann ein einzelnes ACK mit SACK-Optionen, das eine große Menge fehlender Daten impliziert, eine Schrittdiskontinuität im Pipe-Schätzer verursachen
- Dies kann dazu führen, dass Fast Retransmit einen großen Datenburst sendet, der die Menge der zugestellten Daten bei weitem übersteigt
- PRR vermeidet solche Bursts, indem Übertragungsentscheidungen basierend auf der Menge der zugestellten Daten und nicht auf der Menge der verlorenen Daten getroffen werden
Leistungsverbesserung:
- Wie oben beschrieben, ist PRR-SSRB weniger aggressiv als [RFC6675] (überträgt weniger Segmente oder benötigt mehr Zeit für deren Übertragung)
- Aufgrund einer geringeren Wahrscheinlichkeit zusätzlicher Paketverluste während der Wiederherstellung übertrifft es letzteres
12. IANA-Überlegungen (IANA Considerations)
Dieses Dokument hat keine IANA-Aktionen.
13. Sicherheitsüberlegungen (Security Considerations)
PRR ändert das Risikoprofil des Transportprotokolls nicht.
ACK-Divisions-Angriffsschutz:
Implementierer, die PRR vom Bytezählen zum Segmentzählen anpassen, müssen vorsichtig mit den Auswirkungen von ACK-Divisions-Angriffen [Savage99] sein, bei denen Empfänger Teilsegmente bestätigen, um die Stauabrechnung des Senders zu verwirren.
Empfehlung: Die Verwendung von Bytezählung anstelle von Segmentzählung bietet besseren Schutz gegen solche Angriffe.