5. Estimating the Round-Trip Time (Stima del tempo di andata e ritorno)

Ad alto livello, un endpoint misura il tempo trascorso dall'invio di un pacchetto alla sua conferma come campione RTT (RTT Sample). L'endpoint utilizza i campioni RTT e i ritardi dell'host riportati dal peer (Host Delays, vedere la Sezione 13.2 di [QUIC-TRANSPORT]) per generare una descrizione statistica dell'RTT del percorso di rete. Un endpoint calcola i seguenti tre valori per ogni percorso: il valore minimo in un periodo di tempo (min_rtt), una media mobile ponderata esponenzialmente (Exponentially Weighted Moving Average, smoothed_rtt), e la deviazione media (Mean Deviation, denominata "variazione" nel resto di questo documento) nei campioni RTT osservati (rttvar).

5.1. Generating RTT Samples (Generazione di campioni RTT)

Un endpoint genera un campione RTT alla ricezione di un frame ACK che soddisfa le seguenti due condizioni:

• il numero di pacchetto più grande riconosciuto (Largest Acknowledged Packet Number) è appena riconosciuto, e

• almeno uno dei pacchetti appena riconosciuti era che richiedeva riconoscimento (Ack-Eliciting).

Il campione RTT, latest_rtt, è generato come il tempo trascorso dall'invio del pacchetto più grande riconosciuto:

latest_rtt = ack_time - send_time_of_largest_acked

Un campione RTT è generato utilizzando solo il pacchetto più grande riconosciuto nel frame ACK ricevuto. Questo perché un peer riporta i ritardi di riconoscimento (Acknowledgment Delays) solo per il pacchetto più grande riconosciuto in un frame ACK. Sebbene il ritardo di riconoscimento riportato non sia utilizzato dalla misurazione del campione RTT, è utilizzato per regolare il campione RTT nei calcoli successivi di smoothed_rtt e rttvar (Sezione 5.3).

Per evitare di generare più campioni RTT per un singolo pacchetto, un frame ACK non dovrebbe (SHOULD NOT) essere utilizzato per aggiornare le stime RTT se non riconosce nuovamente il pacchetto più grande riconosciuto.

Un campione RTT non deve (MUST NOT) essere generato alla ricezione di un frame ACK che non riconosce nuovamente almeno un pacchetto che richiede riconoscimento. Un peer di solito non invia un frame ACK quando vengono ricevuti solo pacchetti che non richiedono riconoscimento. Pertanto, un frame ACK che contiene riconoscimenti solo per pacchetti che non richiedono riconoscimento potrebbe includere un valore ACK Delay arbitrariamente grande. Ignorare tali frame ACK evita complicazioni nei calcoli successivi di smoothed_rtt e rttvar.

Un mittente potrebbe generare più campioni RTT per RTT quando vengono ricevuti più frame ACK entro un RTT. Come suggerito in [RFC6298], ciò potrebbe risultare in una storia inadeguata in smoothed_rtt e rttvar. Garantire che le stime RTT mantengano una storia sufficiente è una questione di ricerca aperta.

5.2. Estimating min_rtt (Stima di min_rtt)

min_rtt è la stima del mittente dell'RTT minimo osservato per un dato percorso di rete in un periodo di tempo. In questo documento, min_rtt è utilizzato dal rilevamento della perdita per rifiutare campioni RTT implausibilmente piccoli.

min_rtt deve (MUST) essere impostato su latest_rtt al primo campione RTT. min_rtt deve (MUST) essere impostato sul minore tra min_rtt e latest_rtt (Sezione 5.1) per tutti gli altri campioni.

Un endpoint utilizza solo i tempi osservati localmente nel calcolo di min_rtt e non si aggiusta per i ritardi di riconoscimento riportati dal peer. Facendo ciò, l'endpoint può impostare un limite inferiore per smoothed_rtt basato interamente su ciò che osserva (vedere Sezione 5.3) e limita la potenziale sottostima dovuta a ritardi erroneamente riportati dal peer.

L'RTT per un percorso di rete può cambiare nel tempo. Se l'RTT effettivo di un percorso diminuisce, il min_rtt si adatterà immediatamente al primo campione basso. Se l'RTT effettivo del percorso aumenta, tuttavia, il min_rtt non si adatterà ad esso, consentendo che futuri campioni RTT che sono più piccoli del nuovo RTT siano inclusi in smoothed_rtt.

Gli endpoint dovrebbero (SHOULD) impostare il min_rtt sul campione RTT più recente dopo che è stata stabilita una congestione persistente. Ciò evita di dichiarare ripetutamente la congestione persistente quando l'RTT aumenta. Ciò consente anche a una connessione di reimpostare la sua stima di min_rtt e smoothed_rtt dopo un evento di rete dirompente; vedere Sezione 5.3.

Gli endpoint possono (MAY) ristabilire il min_rtt in altri momenti della connessione, ad esempio quando il volume di traffico è basso e viene ricevuto un riconoscimento con un ritardo di riconoscimento basso. Le implementazioni non dovrebbero (SHOULD NOT) aggiornare il valore min_rtt troppo spesso poiché l'RTT minimo effettivo del percorso non è frequentemente osservabile.

5.3. Estimating smoothed_rtt and rttvar (Stima di smoothed_rtt e rttvar)

smoothed_rtt è una media mobile ponderata esponenzialmente dei campioni RTT di un endpoint, e rttvar stima la variazione nei campioni RTT utilizzando una variazione media.

Il calcolo di smoothed_rtt utilizza campioni RTT dopo averli regolati per i ritardi di riconoscimento. Questi ritardi sono decodificati dal campo ACK Delay dei frame ACK come descritto nella Sezione 19.3 di [QUIC-TRANSPORT].

Il peer potrebbe riportare ritardi di riconoscimento che sono maggiori del max_ack_delay del peer durante l'handshake (Sezione 13.2.1 di [QUIC-TRANSPORT]). Per tenere conto di ciò, l'endpoint dovrebbe (SHOULD) ignorare max_ack_delay fino a quando l'handshake è confermato, come definito nella Sezione 4.1.2 di [QUIC-TLS]. Quando si verificano, questi grandi ritardi di riconoscimento sono probabilmente non ripetitivi e limitati all'handshake. L'endpoint può quindi utilizzarli senza limitarli a max_ack_delay, evitando un'inflazione non necessaria della stima RTT.

Si noti che un grande ritardo di riconoscimento può risultare in un smoothed_rtt sostanzialmente gonfiato se c'è un errore sia nella segnalazione del ritardo di riconoscimento del peer sia nella stima min_rtt dell'endpoint. Pertanto, prima della conferma dell'handshake, un endpoint può (MAY) ignorare i campioni RTT se la regolazione del campione RTT per il ritardo di riconoscimento fa sì che il campione sia inferiore a min_rtt.

Dopo la conferma dell'handshake, tutti i ritardi di riconoscimento riportati dal peer che sono maggiori del max_ack_delay del peer sono attribuiti a ritardi non intenzionali ma potenzialmente ripetitivi, come la latenza dello scheduler presso il peer o la perdita di riconoscimenti precedenti. I ritardi eccessivi potrebbero anche essere dovuti a un ricevitore non conforme. Pertanto, questi ritardi extra sono considerati effettivamente parte del ritardo di percorso e incorporati nella stima RTT.

Pertanto, quando si regola un campione RTT utilizzando i ritardi di riconoscimento riportati dal peer, un endpoint:

• può (MAY) ignorare il ritardo di riconoscimento per i pacchetti Initial, poiché questi riconoscimenti non sono ritardati dal peer (Sezione 13.2.1 di [QUIC-TRANSPORT]);

• dovrebbe (SHOULD) ignorare il max_ack_delay del peer fino a quando l'handshake è confermato;

• deve (MUST) utilizzare il minore tra il ritardo di riconoscimento e il max_ack_delay del peer dopo la conferma dell'handshake; e

• non deve (MUST NOT) sottrarre il ritardo di riconoscimento dal campione RTT se il valore risultante è inferiore a min_rtt. Ciò limita la sottostima di smoothed_rtt dovuta a un peer che riporta erroneamente.

Inoltre, un endpoint potrebbe posticipare l'elaborazione dei riconoscimenti quando le chiavi di decrittazione corrispondenti non sono immediatamente disponibili. Ad esempio, un client potrebbe ricevere un riconoscimento per un pacchetto 0-RTT che non può decrittare perché le chiavi di protezione dei pacchetti 1-RTT non sono ancora disponibili. In tali casi, un endpoint dovrebbe (SHOULD) sottrarre tali ritardi locali dal suo campione RTT fino a quando l'handshake è confermato.

Similmente a [RFC6298], smoothed_rtt e rttvar sono calcolati come segue.

Un endpoint inizializza lo stimatore RTT durante la creazione della connessione e quando lo stimatore viene reimpostato durante la migrazione della connessione; vedere Sezione 9.4 di [QUIC-TRANSPORT]. Prima che siano disponibili campioni RTT per un nuovo percorso o quando lo stimatore viene reimpostato, lo stimatore viene inizializzato utilizzando l'RTT iniziale; vedere Sezione 6.2.2.

smoothed_rtt e rttvar sono inizializzati come segue, dove kInitialRtt contiene il valore RTT iniziale:

smoothed_rtt = kInitialRtt
rttvar = kInitialRtt / 2

I campioni RTT per il percorso di rete sono registrati in latest_rtt; vedere Sezione 5.1. Al primo campione RTT dopo l'inizializzazione, lo stimatore viene reimpostato utilizzando quel campione. Ciò garantisce che lo stimatore non mantenga alcuna storia di campioni passati. I pacchetti inviati su altri percorsi non contribuiscono ai campioni RTT per il percorso corrente, come descritto nella Sezione 9.4 di [QUIC-TRANSPORT].

Al primo campione RTT dopo l'inizializzazione, smoothed_rtt e rttvar sono impostati come segue:

smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2

Sui campioni RTT successivi, smoothed_rtt e rttvar evolvono come segue:

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

---