5. Estimating the Round-Trip Time (Estimation du temps aller-retour)

À un niveau élevé, un point de terminaison mesure le temps écoulé entre l'envoi d'un paquet et sa confirmation comme échantillon RTT (RTT Sample). Le point de terminaison utilise les échantillons RTT et les délais d'hôte rapportés par le pair (Host Delays, voir la section 13.2 de [QUIC-TRANSPORT]) pour générer une description statistique du RTT du chemin réseau. Un point de terminaison calcule les trois valeurs suivantes pour chaque chemin : la valeur minimale sur une période de temps (min_rtt), une moyenne mobile pondérée exponentiellement (Exponentially Weighted Moving Average, smoothed_rtt), et la déviation moyenne (Mean Deviation, appelée « variation » dans le reste de ce document) dans les échantillons RTT observés (rttvar).

5.1. Generating RTT Samples (Génération d'échantillons RTT)

Un point de terminaison génère un échantillon RTT lors de la réception d'une trame ACK qui remplit les deux conditions suivantes :

• le plus grand numéro de paquet accusé réception (Largest Acknowledged Packet Number) est nouvellement accusé réception, et

• au moins un des paquets nouvellement accusés réception était provoquant un accusé de réception (Ack-Eliciting).

L'échantillon RTT, latest_rtt, est généré comme le temps écoulé depuis l'envoi du plus grand paquet accusé réception :

latest_rtt = ack_time - send_time_of_largest_acked

Un échantillon RTT est généré en utilisant uniquement le plus grand paquet accusé réception dans la trame ACK reçue. Ceci est dû au fait qu'un pair rapporte les délais d'accusé de réception (Acknowledgment Delays) uniquement pour le plus grand paquet accusé réception dans une trame ACK. Bien que le délai d'accusé de réception rapporté ne soit pas utilisé par la mesure d'échantillon RTT, il est utilisé pour ajuster l'échantillon RTT dans les calculs ultérieurs de smoothed_rtt et rttvar (Section 5.3).

Pour éviter de générer plusieurs échantillons RTT pour un seul paquet, une trame ACK ne devrait pas (SHOULD NOT) être utilisée pour mettre à jour les estimations RTT si elle n'accuse pas réception nouvellement du plus grand paquet accusé réception.

Un échantillon RTT ne doit pas (MUST NOT) être généré lors de la réception d'une trame ACK qui n'accuse pas réception nouvellement d'au moins un paquet provoquant un accusé de réception. Un pair n'envoie généralement pas de trame ACK lorsque seuls des paquets ne provoquant pas d'accusé de réception sont reçus. Par conséquent, une trame ACK qui contient des accusés de réception uniquement pour des paquets ne provoquant pas d'accusé de réception pourrait inclure une valeur ACK Delay arbitrairement grande. Ignorer de telles trames ACK évite les complications dans les calculs ultérieurs de smoothed_rtt et rttvar.

Un expéditeur peut générer plusieurs échantillons RTT par RTT lorsque plusieurs trames ACK sont reçues dans un RTT. Comme suggéré dans [RFC6298], cela pourrait entraîner un historique insuffisant dans smoothed_rtt et rttvar. S'assurer que les estimations RTT conservent un historique suffisant est une question de recherche ouverte.

5.2. Estimating min_rtt (Estimation de min_rtt)

min_rtt est l'estimation par l'expéditeur du RTT minimum observé pour un chemin réseau donné sur une période de temps. Dans ce document, min_rtt est utilisé par la détection de perte pour rejeter les échantillons RTT invraisemblablement petits.

min_rtt doit (MUST) être défini sur latest_rtt lors du premier échantillon RTT. min_rtt doit (MUST) être défini sur le plus petit de min_rtt et latest_rtt (Section 5.1) pour tous les autres échantillons.

Un point de terminaison utilise uniquement les temps observés localement pour calculer le min_rtt et ne s'ajuste pas pour les délais d'accusé de réception rapportés par le pair. Ce faisant, le point de terminaison peut définir une limite inférieure pour le smoothed_rtt basée entièrement sur ce qu'il observe (voir Section 5.3) et limite la sous-estimation potentielle due à des délais erronément rapportés par le pair.

Le RTT pour un chemin réseau peut changer au fil du temps. Si le RTT réel d'un chemin diminue, le min_rtt s'adaptera immédiatement au premier échantillon faible. Si le RTT réel du chemin augmente cependant, le min_rtt ne s'y adaptera pas, permettant aux futurs échantillons RTT qui sont plus petits que le nouveau RTT d'être inclus dans smoothed_rtt.

Les points de terminaison devraient (SHOULD) définir le min_rtt sur l'échantillon RTT le plus récent après l'établissement d'une congestion persistante. Cela évite de déclarer à plusieurs reprises une congestion persistante lorsque le RTT augmente. Cela permet également à une connexion de réinitialiser son estimation de min_rtt et smoothed_rtt après un événement réseau perturbateur ; voir Section 5.3.

Les points de terminaison peuvent (MAY) rétablir le min_rtt à d'autres moments de la connexion, par exemple lorsque le volume de trafic est faible et qu'un accusé de réception est reçu avec un délai d'accusé de réception faible. Les implémentations ne devraient pas (SHOULD NOT) actualiser la valeur min_rtt trop souvent car le RTT minimum réel du chemin n'est pas fréquemment observable.

5.3. Estimating smoothed_rtt and rttvar (Estimation de smoothed_rtt et rttvar)

smoothed_rtt est une moyenne mobile pondérée exponentiellement des échantillons RTT d'un point de terminaison, et rttvar estime la variation dans les échantillons RTT en utilisant une variation moyenne.

Le calcul de smoothed_rtt utilise des échantillons RTT après les avoir ajustés pour les délais d'accusé de réception. Ces délais sont décodés à partir du champ ACK Delay des trames ACK comme décrit dans la Section 19.3 de [QUIC-TRANSPORT].

Le pair peut rapporter des délais d'accusé de réception supérieurs au max_ack_delay du pair pendant la négociation (Section 13.2.1 de [QUIC-TRANSPORT]). Pour tenir compte de cela, le point de terminaison devrait (SHOULD) ignorer max_ack_delay jusqu'à ce que la négociation soit confirmée, comme défini dans la Section 4.1.2 de [QUIC-TLS]. Lorsqu'ils se produisent, ces grands délais d'accusé de réception sont susceptibles d'être non répétitifs et limités à la négociation. Le point de terminaison peut donc les utiliser sans les limiter au max_ack_delay, évitant une inflation inutile de l'estimation RTT.

Notez qu'un grand délai d'accusé de réception peut entraîner un smoothed_rtt considérablement gonflé s'il y a une erreur soit dans le rapport du délai d'accusé de réception du pair, soit dans l'estimation min_rtt du point de terminaison. Par conséquent, avant la confirmation de la négociation, un point de terminaison peut (MAY) ignorer les échantillons RTT si l'ajustement de l'échantillon RTT pour le délai d'accusé de réception fait que l'échantillon soit inférieur au min_rtt.

Après la confirmation de la négociation, tous les délais d'accusé de réception rapportés par le pair qui sont supérieurs au max_ack_delay du pair sont attribués à des délais involontaires mais potentiellement répétitifs, tels que la latence du planificateur au niveau du pair ou la perte d'accusés de réception précédents. Les délais excessifs pourraient également être dus à un récepteur non conforme. Par conséquent, ces délais supplémentaires sont considérés comme faisant effectivement partie du délai de chemin et incorporés dans l'estimation RTT.

Par conséquent, lors de l'ajustement d'un échantillon RTT en utilisant les délais d'accusé de réception rapportés par le pair, un point de terminaison :

• peut (MAY) ignorer le délai d'accusé de réception pour les paquets Initial, car ces accusés de réception ne sont pas retardés par le pair (Section 13.2.1 de [QUIC-TRANSPORT]) ;

• devrait (SHOULD) ignorer le max_ack_delay du pair jusqu'à ce que la négociation soit confirmée ;

• doit (MUST) utiliser le plus petit du délai d'accusé de réception et du max_ack_delay du pair après la confirmation de la négociation ; et

• ne doit pas (MUST NOT) soustraire le délai d'accusé de réception de l'échantillon RTT si la valeur résultante est plus petite que le min_rtt. Cela limite la sous-estimation du smoothed_rtt due à un pair rapportant de manière erronée.

De plus, un point de terminaison peut reporter le traitement des accusés de réception lorsque les clés de déchiffrement correspondantes ne sont pas immédiatement disponibles. Par exemple, un client peut recevoir un accusé de réception pour un paquet 0-RTT qu'il ne peut pas déchiffrer car les clés de protection des paquets 1-RTT ne lui sont pas encore disponibles. Dans de tels cas, un point de terminaison devrait (SHOULD) soustraire de tels délais locaux de son échantillon RTT jusqu'à ce que la négociation soit confirmée.

Similaire à [RFC6298], smoothed_rtt et rttvar sont calculés comme suit.

Un point de terminaison initialise l'estimateur RTT lors de l'établissement de la connexion et lorsque l'estimateur est réinitialisé lors de la migration de connexion ; voir Section 9.4 de [QUIC-TRANSPORT]. Avant que des échantillons RTT ne soient disponibles pour un nouveau chemin ou lorsque l'estimateur est réinitialisé, l'estimateur est initialisé en utilisant le RTT initial ; voir Section 6.2.2.

smoothed_rtt et rttvar sont initialisés comme suit, où kInitialRtt contient la valeur RTT initiale :

smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2

Les échantillons RTT pour le chemin réseau sont enregistrés dans latest_rtt ; voir Section 5.1. Lors du premier échantillon RTT après l'initialisation, l'estimateur est réinitialisé en utilisant cet échantillon. Cela garantit que l'estimateur ne conserve aucun historique d'échantillons passés. Les paquets envoyés sur d'autres chemins ne contribuent pas d'échantillons RTT au chemin actuel, comme décrit dans la Section 9.4 de [QUIC-TRANSPORT].

Lors du premier échantillon RTT après l'initialisation, smoothed_rtt et rttvar sont définis comme suit :

smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2

Pour les échantillons RTT ultérieurs, smoothed_rtt et rttvar évoluent comme suit :

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

---