5. Estimating the Round-Trip Time (Schätzung der Rundlaufzeit)

Auf hoher Ebene misst ein Endpunkt die Zeit von der Paketübertragung bis zur Bestätigung als RTT-Sample (RTT Sample). Der Endpunkt verwendet RTT-Samples und vom Peer gemeldete Host-Verzögerungen (Host Delays, siehe Abschnitt 13.2 von [QUIC-TRANSPORT]), um eine statistische Beschreibung der RTT des Netzwerkpfads zu generieren. Ein Endpunkt berechnet die folgenden drei Werte für jeden Pfad: den Minimalwert über einen Zeitraum (min_rtt), einen exponentiell gewichteten gleitenden Durchschnitt (Exponentially Weighted Moving Average, smoothed_rtt) und die mittlere Abweichung (Mean Deviation, im Rest dieses Dokuments als „Variation" bezeichnet) in den beobachteten RTT-Samples (rttvar).

5.1. Generating RTT Samples (Generierung von RTT-Samples)

Ein Endpunkt generiert ein RTT-Sample beim Empfang eines ACK-Frames, der die folgenden zwei Bedingungen erfüllt:

• die größte bestätigte Paketnummer (Largest Acknowledged Packet Number) ist neu bestätigt, und

• mindestens eines der neu bestätigten Pakete war bestätigungsauslösend (Ack-Eliciting).

Das RTT-Sample, latest_rtt, wird als die seit dem Senden des größten bestätigten Pakets verstrichene Zeit generiert:

latest_rtt = ack_time - send_time_of_largest_acked

Ein RTT-Sample wird nur unter Verwendung des größten bestätigten Pakets im empfangenen ACK-Frame generiert. Dies liegt daran, dass ein Peer Bestätigungsverzögerungen (Acknowledgment Delays) nur für das größte bestätigte Paket in einem ACK-Frame meldet. Obwohl die gemeldete Bestätigungsverzögerung nicht für die RTT-Sample-Messung verwendet wird, wird sie verwendet, um das RTT-Sample in nachfolgenden Berechnungen von smoothed_rtt und rttvar anzupassen (Abschnitt 5.3).

Um zu vermeiden, dass mehrere RTT-Samples für ein einzelnes Paket generiert werden, sollte (SHOULD NOT) ein ACK-Frame nicht zur Aktualisierung von RTT-Schätzungen verwendet werden, wenn er das größte bestätigte Paket nicht neu bestätigt.

Ein RTT-Sample darf nicht (MUST NOT) beim Empfang eines ACK-Frames generiert werden, der nicht mindestens ein bestätigungsauslösendes Paket neu bestätigt. Ein Peer sendet normalerweise keinen ACK-Frame, wenn nur nicht-bestätigungsauslösende Pakete empfangen werden. Daher könnte ein ACK-Frame, der nur Bestätigungen für nicht-bestätigungsauslösende Pakete enthält, einen beliebig großen ACK Delay-Wert enthalten. Das Ignorieren solcher ACK-Frames vermeidet Komplikationen bei nachfolgenden smoothed_rtt- und rttvar-Berechnungen.

Ein Sender könnte mehrere RTT-Samples pro RTT generieren, wenn mehrere ACK-Frames innerhalb einer RTT empfangen werden. Wie in [RFC6298] vorgeschlagen, könnte dies zu unzureichender Historie in smoothed_rtt und rttvar führen. Sicherzustellen, dass RTT-Schätzungen ausreichende Historie behalten, ist eine offene Forschungsfrage.

5.2. Estimating min_rtt (Schätzung von min_rtt)

min_rtt ist die Schätzung des Senders für die minimale RTT, die für einen gegebenen Netzwerkpfad über einen Zeitraum beobachtet wurde. In diesem Dokument wird min_rtt von der Verlusterkennung verwendet, um unplausibel kleine RTT-Samples abzulehnen.

min_rtt muss (MUST) beim ersten RTT-Sample auf latest_rtt gesetzt werden. min_rtt muss (MUST) bei allen anderen Samples auf den kleineren Wert von min_rtt und latest_rtt (Abschnitt 5.1) gesetzt werden.

Ein Endpunkt verwendet nur lokal beobachtete Zeiten bei der Berechnung der min_rtt und passt sich nicht an die vom Peer gemeldeten Bestätigungsverzögerungen an. Dies ermöglicht es dem Endpunkt, eine untere Grenze für die smoothed_rtt basierend ausschließlich auf seinen Beobachtungen festzulegen (siehe Abschnitt 5.3) und begrenzt potenzielle Unterschätzungen aufgrund fehlerhaft gemeldeter Verzögerungen durch den Peer.

Die RTT für einen Netzwerkpfad kann sich im Laufe der Zeit ändern. Wenn die tatsächliche RTT eines Pfads abnimmt, passt sich die min_rtt sofort beim ersten niedrigen Sample an. Wenn die tatsächliche RTT des Pfads jedoch zunimmt, passt sich die min_rtt nicht daran an, wodurch zukünftige RTT-Samples, die kleiner als die neue RTT sind, in smoothed_rtt aufgenommen werden können.

Endpunkte sollten (SHOULD) die min_rtt nach Feststellung persistenter Überlast auf das neueste RTT-Sample setzen. Dies vermeidet die wiederholte Feststellung persistenter Überlast, wenn die RTT zunimmt. Dies ermöglicht es einer Verbindung auch, ihre Schätzung von min_rtt und smoothed_rtt nach einem störenden Netzwerkereignis zurückzusetzen; siehe Abschnitt 5.3.

Endpunkte können (MAY) die min_rtt zu anderen Zeitpunkten in der Verbindung neu festlegen, beispielsweise wenn das Verkehrsaufkommen gering ist und eine Bestätigung mit einer niedrigen Bestätigungsverzögerung empfangen wird. Implementierungen sollten (SHOULD NOT) den min_rtt-Wert nicht zu oft aktualisieren, da die tatsächliche minimale RTT des Pfads nicht häufig beobachtbar ist.

5.3. Estimating smoothed_rtt and rttvar (Schätzung von smoothed_rtt und rttvar)

smoothed_rtt ist ein exponentiell gewichteter gleitender Durchschnitt der RTT-Samples eines Endpunkts, und rttvar schätzt die Variation in den RTT-Samples unter Verwendung einer mittleren Variation.

Die Berechnung von smoothed_rtt verwendet RTT-Samples, nachdem sie für Bestätigungsverzögerungen angepasst wurden. Diese Verzögerungen werden aus dem ACK Delay-Feld von ACK-Frames dekodiert, wie in Abschnitt 19.3 von [QUIC-TRANSPORT] beschrieben.

Der Peer könnte während des Handshakes Bestätigungsverzögerungen melden, die größer sind als das max_ack_delay des Peers (Abschnitt 13.2.1 von [QUIC-TRANSPORT]). Um dies zu berücksichtigen, sollte (SHOULD) der Endpunkt max_ack_delay ignorieren, bis der Handshake bestätigt ist, wie in Abschnitt 4.1.2 von [QUIC-TLS] definiert. Wenn sie auftreten, sind diese großen Bestätigungsverzögerungen wahrscheinlich nicht wiederholend und auf den Handshake beschränkt. Der Endpunkt kann sie daher verwenden, ohne sie auf max_ack_delay zu begrenzen, wodurch eine unnötige Inflation der RTT-Schätzung vermieden wird.

Beachten Sie, dass eine große Bestätigungsverzögerung zu einer erheblich aufgeblähten smoothed_rtt führen kann, wenn entweder in der Meldung der Bestätigungsverzögerung des Peers oder in der min_rtt-Schätzung des Endpunkts ein Fehler vorliegt. Daher kann (MAY) ein Endpunkt vor der Handshake-Bestätigung RTT-Samples ignorieren, wenn die Anpassung des RTT-Samples für die Bestätigungsverzögerung dazu führt, dass das Sample kleiner als die min_rtt ist.

Nach der Bestätigung des Handshakes werden alle vom Peer gemeldeten Bestätigungsverzögerungen, die größer als das max_ack_delay des Peers sind, unbeabsichtigten, aber möglicherweise wiederholenden Verzögerungen zugeschrieben, wie z.B. Scheduler-Latenz beim Peer oder Verlust früherer Bestätigungen. Übermäßige Verzögerungen könnten auch auf einen nicht konformen Empfänger zurückzuführen sein. Daher werden diese zusätzlichen Verzögerungen effektiv als Teil der Pfadverzögerung betrachtet und in die RTT-Schätzung einbezogen.

Daher gilt beim Anpassen eines RTT-Samples unter Verwendung von vom Peer gemeldeten Bestätigungsverzögerungen für einen Endpunkt:

• Er kann (MAY) die Bestätigungsverzögerung für Initial-Pakete ignorieren, da diese Bestätigungen vom Peer nicht verzögert werden (Abschnitt 13.2.1 von [QUIC-TRANSPORT]);

• Er sollte (SHOULD) das max_ack_delay des Peers ignorieren, bis der Handshake bestätigt ist;

• Er muss (MUST) den kleineren Wert der Bestätigungsverzögerung und des max_ack_delay des Peers nach der Handshake-Bestätigung verwenden; und

• Er darf nicht (MUST NOT) die Bestätigungsverzögerung vom RTT-Sample subtrahieren, wenn der resultierende Wert kleiner als die min_rtt ist. Dies begrenzt die Unterschätzung der smoothed_rtt aufgrund eines falsch meldenden Peers.

Zusätzlich könnte ein Endpunkt die Verarbeitung von Bestätigungen verschieben, wenn die entsprechenden Entschlüsselungsschlüssel nicht sofort verfügbar sind. Beispielsweise könnte ein Client eine Bestätigung für ein 0-RTT-Paket erhalten, das er nicht entschlüsseln kann, weil 1-RTT-Paketschutzschlüssel noch nicht verfügbar sind. In solchen Fällen sollte (SHOULD) ein Endpunkt solche lokalen Verzögerungen von seinem RTT-Sample subtrahieren, bis der Handshake bestätigt ist.

Ähnlich wie in [RFC6298] werden smoothed_rtt und rttvar wie folgt berechnet.

Ein Endpunkt initialisiert den RTT-Schätzer während der Verbindungsherstellung und wenn der Schätzer während der Verbindungsmigration zurückgesetzt wird; siehe Abschnitt 9.4 von [QUIC-TRANSPORT]. Bevor RTT-Samples für einen neuen Pfad verfügbar sind oder wenn der Schätzer zurückgesetzt wird, wird der Schätzer mit der initialen RTT initialisiert; siehe Abschnitt 6.2.2.

smoothed_rtt und rttvar werden wie folgt initialisiert, wobei kInitialRtt den initialen RTT-Wert enthält:

smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2

RTT-Samples für den Netzwerkpfad werden in latest_rtt aufgezeichnet; siehe Abschnitt 5.1. Beim ersten RTT-Sample nach der Initialisierung wird der Schätzer mit diesem Sample zurückgesetzt. Dies stellt sicher, dass der Schätzer keine Historie früherer Samples beibehält. Pakete, die auf anderen Pfaden gesendet werden, tragen nicht zu RTT-Samples für den aktuellen Pfad bei, wie in Abschnitt 9.4 von [QUIC-TRANSPORT] beschrieben.

Beim ersten RTT-Sample nach der Initialisierung werden smoothed_rtt und rttvar wie folgt gesetzt:

smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2

Bei nachfolgenden RTT-Samples entwickeln sich smoothed_rtt und rttvar wie folgt:

ack_delay = decoded acknowledgment delay from ACK frame
if (handshake confirmed):
  ack_delay = min(ack_delay, max_ack_delay)
adjusted_rtt = latest_rtt
if (latest_rtt >= min_rtt + ack_delay):
  adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample

---