Zusammenfassung

  • ACK Delay meldet die absichtliche Wartezeit zwischen dem Empfang des größten bestätigten Pakets und dem Senden des ACK.
  • latest_rtt wird zunächst aus der lokalen Beobachtung gebildet, bevor ACK Delay berücksichtigt wird.
  • Die Auswertung braucht ack_delay_exponent, Handshake-Phase, max_ack_delay und die Untergrenze min_rtt.

Ein Telemetriesystem kann die Zeit vom Senden bis zum Eintreffen des ACK messen, ACK Delay dekodieren, den Wert abziehen und den Rest als Netzwerklatenz veröffentlichen. Das ist eine elegante Darstellung, aber keine belastbare Aussage. ACK Delay ist eine Meldung des Empfängers über eine absichtlich eingeführte Wartezeit, die er kontrolliert. Es ist weder eine direkte Messung der Ausbreitung, der Netzwerkwarteschlangen oder der Einwegverzögerung noch ein vollständiger Bericht über die Zeit auf dem entfernten Host.

Der Geltungsbereich ist eng. Gemeint ist die Zeit zwischen dem Empfang des Pakets mit der höchsten bestätigten Paketnummer und dem Versand des ACK. Der Wert gilt nicht für jedes Paket in den ACK ranges. Verzögerungen außerhalb der Kontrolle des Endpunkts, etwa Wartezeit im Betriebssystem vor der QUIC-Verarbeitung, gehören nicht automatisch dazu. Eine Verzögerung wegen fehlender Entschlüsselungsschlüssel kann nach den Protokollregeln einbezogen werden; dadurch wird ACK Delay aber weder zu einem allgemeinen Host-Timer noch zu einem Anwendungs-Timer.

Der Sender bildet latest_rtt zuerst aus dem lokalen Sendezeitpunkt des größten neu bestätigten, ACK-auslösenden Pakets und dem lokalen Eintreffen des ACK. Der rohe Sample enthält damit das gesamte beobachtete Bestätigungsintervall. ACK Delay wird erst später für smoothed_rtt und rttvar verwendet. Der codierte Wert ist ohne ack_delay_exponent und die passenden Transportparameter nicht sinnvoll. Der Standardexponent ist 3; max_ack_delay wird in Millisekunden angegeben und hat standardmäßig 25 ms. Solche Standardwerte ersetzen jedoch nicht den ausgehandelten Zusammenhang.

min_rtt wird ausschließlich aus lokalen Beobachtungen berechnet und nicht wegen eines vom Peer gemeldeten ACK Delay verringert. Sie bildet eine Untergrenze gegen eine zu starke Absenkung durch einen fehlerhaften Bericht, ist aber keine Messung der reinen Netzwerk- oder Einwegverzögerung. Nach der Handshake-Bestätigung verwendet der Sender den kleineren Wert aus dekodiertem ACK Delay und max_ack_delay des Peers. Außerdem darf der korrigierte Sample nicht unter min_rtt fallen. Vor der Bestätigung wird max_ack_delay nicht als Obergrenze verwendet; unter anderem kann die Schlüsselverfügbarkeit längere frühe Wartezeiten erklären.

Ein überhöhter Wert hat keine eindeutig nachgewiesene Ursache. Nach der Bestätigung behandelt der Algorithmus den Anteil oberhalb von max_ack_delay effektiv als Pfadverzögerung. Die Beobachtung unterscheidet jedoch nicht zwischen Peer-Scheduler, Verlust früherer ACKs und einem nicht regelkonformen Empfänger. Die Authentizität des geschützten Pakets beweist nicht die Richtigkeit des Berichts. Ebenso beweist der Wert weder Anwendungsverarbeitung, Dienstantwort, dauerhafte Fertigstellung noch einen Geschäftserfolg.

Die betriebliche Aufzeichnung sollte getrennte Tatsachen bewahren: Verbindungs- und Pfadidentität, Paketnummernraum, größtes neu bestätigtes Paket und Sendezeit, ACK-Ankunft und -Verarbeitung, rohes latest_rtt, rohes und dekodiertes ACK Delay, ack_delay_exponent, max_ack_delay des Peers, Handshake-Zustand, min_rtt, angewandte Ober- und Untergrenze, korrigierten Sample, smoothed_rtt, rttvar und PTO. ACK ranges, Schlüsselverfügbarkeit, lokale Verarbeitung, Hinweise auf verlorene ACKs und Anwendungstiming gehören ebenfalls getrennt gespeichert.