Zusammenfassung

  • PRR berechnet für jedes ACK eine exakte Sendefreigabe und führt die tatsächlich im Netz befindliche Datenmenge schrittweise zu dem ssthresh, das ein getrenntes Staukontrollverfahren festgelegt hat.
  • Das ACK belegt einen eng umrissenen Lieferfortschritt, nicht die Genesung des gesamten Pfads; belastbare Betriebsnachweise müssen Zielwahl, PRR-Zweig, reale Sendemenge, Pacing und Wirkung getrennt festhalten.

Gleicher Endwert, anderer Eingriff ins Netz

Zwanzig Segmente seien unterwegs, als ein Verlust die Staukontrolle veranlasst, zehn als Ziel der Erholung zu wählen. Ein älteres Verfahren kann das Fenster sofort absenken, warten, bis die geschätzte Flugmenge fällt, und dann mehrere Segmente gemeinsam freigeben. Das Rechenbeispiel in RFC 9937 nennt diese Pause ein halbes Fenster Schweigen. Springt eine Schätzung wie pipe, kann umgekehrt eine große ungetaktete Sendemöglichkeit entstehen.

PRR behandelt nicht nur die zehn am Schluss. Es verteilt die freiwillige Fensterverkleinerung auf die zurückkehrenden ACKs. Der Sender berechnet nach jedem Beleg neu, wie viel er senden darf. Dieselbe Gesamtmenge erhält dadurch eine andere zeitliche Form.

Die Forschungsarbeit von 2011 stammt von Nandita Dukkipati, Matt Mathis, Yuchung Cheng und Monia Ghobadi. Sie untersuchte kurze Flows, Anwendungspausen, Burstverluste, ACK-Verlust und -Umordnung sowie Stretch-ACKs. Frühere Verfahren konnten das Fenster übermäßig verkleinern oder große Bursts senden. In der untersuchten Population verringerten PRR und die begleitende Arbeit zu früher Retransmission die TCP-Latenz verlustbetroffener Verbindungen je nach Antwortgröße um 3 bis 10 Prozent. Das ist ein historisches Messergebnis, keine allgemeine Leistungszusage.

2013 folgte die experimentelle RFC 6937 von Mathis, Dukkipati und Cheng. Im Dezember 2025 ersetzte sie die Standards-Track-RFC 9937 von Mathis, Neal Cardwell, Cheng und Dukkipati. Diese Dokumente zeigen Dukkipatis anhaltende Verbindung von der Messfrage über das Experiment bis zur überarbeiteten Spezifikation. Sie begründen weder Alleinerfindung noch Kontrolle über jede Implementierung.

Wer das Ziel setzt, wer Fortschritt sieht

PRR wird verständlich, sobald drei Zuständigkeiten nicht vermischt werden.

Das Staukontrollverfahren wählt ssthresh, die gewünschte Flugmenge am Ende der Episode. Reno, CUBIC oder ein anderes kompatibles Verfahren trifft diese Entscheidung. PRR bewertet nicht eigenständig die Schwere des Staus und schreibt das Ziel nicht vor.

Die Erholungslogik wertet ACKs aus. DeliveredData ist die beste Schätzung des Senders, wie viele Bytes das aktuelle ACK seit dem vorigen als zugestellt ausweist. Die Formulierung „beste Schätzung“ setzt eine Grenze: Das Signal beschreibt weder die vollständige Hin- und Rückstrecke noch die Ursache des Verlusts oder den Zustand der Anwendung.

PRR berechnet danach SndCnt, also die genaue Zahl von Bytes, die als Antwort gesendet werden darf. Eine andere Funktion entscheidet, ob fehlende Daten erneut oder neue Daten übertragen werden. PRR regelt Menge und Zeitpunkt, nicht die Auswahl der Bytes.

So sieht eine minimale, aber präzise Spezifikation aus. Die gemeinsame Regel ist lokal nachrechenbar. Entscheidungen, die andere Zustände benötigen, bleiben bei den zuständigen Modulen. Ein ACK wird durch seine Ankunft nicht zur übergeordneten Instanz.

Ein Lieferbeleg als Freigabetakt

Zu Beginn hält der Sender RecoverFS fest, seine Schätzung der anfänglichen Flugmenge, die in der Episode zugestellt werden könnte. prr_delivered sammelt den bestätigten Fortschritt, prr_out die während der Erholung gesendeten Daten.

Solange inflight über ssthresh liegt, berechnet PRR proportional, wie viel bis dahin angesichts des gelieferten Anteils und des kleineren Ziels hätte freigegeben werden sollen. Nach Abzug von prr_out bleibt das nächste SndCnt.

Das ACK ist damit kein Gesundheitszeugnis des Pfads, sondern ein Beleg, der einen begrenzten Kredit öffnet. Kleine Fortschritte lösen kleine Sendungen aus. Gehen Zwischen-ACKs verloren, kann ein späteres ACK mehr kumulierten Fortschritt ausweisen; die Rechnung holt auf, ohne einem Schätzsprung einen unbegrenzten Burst zu schenken.

Die Trennung ist entscheidend. Das ACK meldet Lieferung. Die Staukontrolle besitzt das Ziel. PRR bemisst die Freigabe. Keines dieser Elemente beweist allein, dass der Pfad wieder gesund ist.

Unterhalb des Ziels gilt abgestufte Vorsicht

Bei starken Verlusten kann inflight unter ssthresh fallen. Streng konservatives Senden kann die Erholung verzögern, ungeprüftes Auffüllen neue Verluste auslösen. RFC 9937 unterscheidet deshalb zwei Reduction Bounds.

Standardmäßig bindet der Conservative Reduction Bound die Ausgabe eng an zugestellte Daten. Ist SafeACK wahr, darf der Slow Start Reduction Bound höchstens ein Sender-Maximum-Segment zusätzlich freigeben. Das ACK muss den kumulativen Bestätigungsstand voranbringen und darf keinen neuen Verlust anzeigen.

Die Fassung von 2025 wählt adaptiv. Anlass war ein Problem mit Token-Bucket-Policern: Nach Verbrauch der Tokens können sie plötzlich viel Verkehr verwerfen, ohne dem Endsystem zuvor die Auffüllrate gezeigt zu haben. Ein aus früherer Pfadleistung abgeleitetes Ziel kann dann deutlich zu hoch sein. PRR bleibt zunächst konservativ und gestattet den Extraschritt erst mit dem definierten Fortschrittsnachweis.

SafeACK bedeutet nicht, dass der Pfad sicher ist. Der Name besagt nur, dass dieses ACK die zwei Bedingungen für die begrenzte Zusatzfreigabe erfüllt.

Auch der Abschluss braucht Pacing

Jede Übertragung erhöht prr_out; am Ende setzt PRR cwnd auf ssthresh. RFC 9937 hält jedoch fest, dass dieser Abschluss in bestimmten Situationen aufeinanderfolgende Segmente als Burst zulassen kann, und empfiehlt Pacing.

Die Spezifikation behauptet also nicht, jedes Zeitrisiko beseitigt zu haben. Auch mögliche Vorteile des weicheren Takts sind nicht durchgehend quantifiziert. Standardsstatus belegt Prüfung der Spezifikation, nicht die Korrektheit eines bestimmten Binaries oder dessen Nutzen in einem Dienst.

RFC 9937 dokumentiert außerdem, dass PRR seit der ersten weithin eingesetzten Umsetzung 2011 das Fast-Recovery-Verfahren von Linux TCP für dessen standardmäßige und unterstützte Staukontrollmodule ist. Das ist wichtige Laufzeitgeschichte. Sie verrät nicht, welchen Zweig ein bestimmter Kernel nahm, ob Pacing aktiv war oder ob Nutzer eine Latenzverbesserung sahen.

Welche Quittung der Betrieb braucht

Ein prüfbarer Nachweis nennt Transport- oder Kernel-Build, Staukontrollmodul, Auslöser der Verlustdetektion, die Startwerte von cwnd, inflight und RecoverFS sowie Komponente, Version und Konfiguration der ssthresh-Wahl.

Für jedes relevante ACK gehören kumulativer Fortschritt, neuer Verlust, DeliveredData, Wert und Begründung von SafeACK, proportionaler Zweig, CRB oder SSRB, berechnetes SndCnt, tatsächlich gesendete Bytes und neues prr_out in das Protokoll. Die getrennte Wahl zwischen Wiederholung und neuen Daten bleibt sichtbar.

Beim Abschluss braucht es Fenster- und Flugmengenschätzung, Pacing-Zustand, Burst, Timeout und Wiederholungsverlust sowie Latenz- und Goodput-Verteilungen gegenüber einer vergleichbaren Kontrollgruppe. Tests umfassen Umordnung, Anwendungspausen, SACK und Nicht-SACK soweit unterstützt sowie Token-Bucket-Policing. Auch Gegenbelege zählen: ACKs können vorankommen, obwohl Pfad oder Anwendung schlecht bleiben.

Diese Quittung bewahrt die Reihenfolge der Aussagen. Das ACK beobachtete Lieferung. Die Staukontrolle wählte ein Ziel. PRR berechnete eine Freigabe. Ein anderes Modul wählte Bytes. Laufender Code sendete. Nur die Messung belegt die Wirkung.

Quellen