Zusammenfassung

  • PTO-Ablauf löst eine oder zwei ACK-auslösende Probes aus und erhöht den Backoff.
  • Er erklärt kein Paket allein für verloren und beweist weder Überlastung noch ein verlorenes ACK.
  • Timer, packet number space, Probe, spätere ACKs, Verlustdeklaration und Anwendungsergebnis sind getrennte Belege.

Die typische Fehlinterpretation entsteht, wenn eine Betriebspipeline aus einem Timerereignis sofort ein Verlustereignis macht. Der Ablauf von PTO ist zunächst ein Ereignis in einem bestimmten packet number space. ACK-auslösende Pakete haben innerhalb der berechneten Zeit keinen erwarteten Bestätigungsfortschritt erzeugt, oder ein Server muss vor der Adressvalidierung des Clients sondieren. Die vorgesehene Reaktion besteht darin, Fortschritt zu suchen: Der Endpoint sendet mindestens eine und darf bis zu zwei vollformatige ACK-auslösende Probe-Datagramme senden. Danach wird der PTO-Backoff erhöht. Diese Handlung benennt kein verlorenes Paket.

PTO wird je packet number space geführt. Initial, Handshake und Application Data sind deshalb keine gemeinsame Warteschlange. Die normale Berechnung lautet smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay. Für Initial und Handshake wird der max_ack_delay-Term auf null gesetzt. Application Data PTO wird vor der Handshake-Bestätigung nicht aktiviert. Das Senden oder Bestätigen ACK-auslösender Pakete sowie das Verwerfen von Initial- oder Handshake-Schlüsseln kann den PTO neu starten. Nach dem Ablauf verdoppelt sich der nächste Zeitraum; aufeinanderfolgende Zeiträume wachsen über die verschiedenen packet number spaces exponentiell und werden schließlich durch den separaten idle timeout begrenzt.

Die Verlusterkennung liefert andere Evidenz. Ein time-threshold loss-detection timer hat Vorrang; solange er gesetzt ist, darf PTO nicht aktiviert werden. Spätere ACK-Bereiche können nach RFC 9002 eine Verlustdeklaration durch packet threshold oder time threshold ermöglichen. Diese spätere Deklaration darf nicht in den früheren Timerablauf hineininterpretiert werden. Wer beim PTO-Ablauf alle unbestätigten Pakete als verloren markiert, zieht eine Schlussfolgerung vor, für die noch die passende Schwellen- oder ACK-Evidenz fehlt.

Auch der Begriff „Retransmission“ ist irreführend. Wenn neue Daten vorhanden sind, sollen sie verwendet werden. Andernfalls darf zuvor gesendete Information in einem neuen Frame und einem neuen Paket erneut übertragen werden. Wenn keine Daten verfügbar sind, kann PING oder ein anderer ACK-auslösender Frame eingesetzt werden. RFC 9000 stellt klar: Verlorene QUIC-Pakete werden nicht als Ganzes erneut gesendet; reparaturbedürftige Information wird in neuen Frames und neuen Paketen erneut übertragen. Information erneut zu senden ist nicht das Abspielen desselben Pakets. PING und PADDING enthalten keine erneut übertragbare Information.

Vor der Adressvalidierung zählen Server-Probes gegen das anti-amplification limit. Reicht das Budget für weitere Daten nicht aus, darf der Server PTO erst aktivieren, wenn ein neues Client-Datagramm das Budget vergrößert. Der Client kann dennoch sondieren müssen, um den Server freizugeben. Das ist eine Budget- und Zustandsaussage, kein Beweis für Paket- oder ACK-Verlust. PTO allein beweist auch nicht, dass Überlastung die Ursache war, dass der Empfänger Anwendungsdaten verarbeitet hat, dass ein Dienst geantwortet hat oder dass ein Geschäftsvorgang abgeschlossen wurde.