4. Relevant Differences between QUIC and TCP (Differenze rilevanti tra QUIC e TCP)
I lettori familiari con il rilevamento della perdita e il controllo della congestione di TCP troveranno qui algoritmi che sono paralleli a quelli TCP ben noti. Tuttavia, le differenze di protocollo tra QUIC e TCP contribuiscono alle differenze algoritmiche. Queste differenze di protocollo sono brevemente descritte di seguito.
4.1. Separate Packet Number Spaces (Spazi di numeri di pacchetto separati)
QUIC utilizza spazi di numeri di pacchetto (Packet Number Spaces) separati per ogni livello di crittografia (Encryption Level), tranne che 0-RTT e tutte le generazioni di chiavi 1-RTT utilizzano lo stesso spazio di numeri di pacchetto. Gli spazi di numeri di pacchetto separati garantiscono che il riconoscimento dei pacchetti inviati con un livello di crittografia non causerà la ritrasmissione errata (Spurious Retransmission) dei pacchetti inviati con un livello di crittografia diverso. Il controllo della congestione e la misurazione del tempo di andata e ritorno (RTT) sono unificati tra gli spazi di numeri di pacchetto.
4.2. Monotonically Increasing Packet Numbers (Numeri di pacchetto crescenti monotonicamente)
TCP confonde l'ordine di trasmissione al mittente con l'ordine di consegna al destinatario, risultando nel problema di ambiguità di ritrasmissione (Retransmission Ambiguity Problem) [RETRANSMISSION]. QUIC separa l'ordine di trasmissione dall'ordine di consegna: i numeri di pacchetto indicano l'ordine di trasmissione, e l'ordine di consegna è determinato dagli offset di flusso (Stream Offsets) nei frame STREAM.
Il numero di pacchetto di QUIC è strettamente crescente all'interno di uno spazio di numeri di pacchetto e codifica direttamente l'ordine di trasmissione. Un numero di pacchetto più alto significa che il pacchetto è stato inviato più tardi, e un numero di pacchetto più basso significa che il pacchetto è stato inviato prima. Quando un pacchetto contenente frame che richiedono riconoscimento viene rilevato come perso, QUIC include i frame necessari in un nuovo pacchetto con un nuovo numero di pacchetto, eliminando l'ambiguità su quale pacchetto viene riconosciuto quando si riceve un ACK. Di conseguenza, possono essere effettuate misurazioni RTT più accurate, le ritrasmissioni errate vengono rilevate banalmente, e meccanismi come Fast Retransmit possono essere applicati universalmente, basandosi solo sul numero di pacchetto.
Questo punto di progettazione semplifica significativamente i meccanismi di rilevamento della perdita per QUIC. La maggior parte dei meccanismi TCP tenta implicitamente di dedurre l'ordine di trasmissione basandosi sui numeri di sequenza TCP -- un compito non banale, specialmente quando i timestamp TCP non sono disponibili.
4.3. Clearer Loss Epoch (Epoca di perdita più chiara)
QUIC inizia un'epoca di perdita (Loss Epoch) quando un pacchetto viene perso. L'epoca di perdita termina quando viene riconosciuto un pacchetto inviato dopo l'inizio dell'epoca. TCP attende che il gap nello spazio dei numeri di sequenza venga riempito, e quindi se un segmento viene perso più volte di seguito, l'epoca di perdita potrebbe non terminare per diversi viaggi di andata e ritorno. Poiché entrambi dovrebbero ridurre le loro finestre di congestione solo una volta per epoca, QUIC lo farà una volta per ogni viaggio di andata e ritorno che sperimenta perdita, mentre TCP potrebbe farlo solo una volta attraverso più viaggi di andata e ritorno.
4.4. No Reneging (Nessuna rinuncia)
I frame ACK di QUIC contengono informazioni simili a quelle nei riconoscimenti selettivi TCP (SACKs) [RFC2018]. Tuttavia, QUIC non permette che un riconoscimento di pacchetto venga rinunciato (Reneging), semplificando notevolmente le implementazioni su entrambi i lati e riducendo la pressione di memoria sul mittente.
4.5. More ACK Ranges (Più intervalli ACK)
QUIC supporta molti intervalli ACK, al contrario dei tre intervalli SACK di TCP. In ambienti ad alta perdita, ciò accelera il recupero, riduce le ritrasmissioni errate e garantisce il progresso senza fare affidamento sui timeout.
4.6. Explicit Correction for Delayed Acknowledgments (Correzione esplicita per riconoscimenti ritardati)
Gli endpoint QUIC misurano il ritardo sostenuto tra quando un pacchetto viene ricevuto e quando viene inviato il corrispondente riconoscimento, permettendo a un peer di mantenere una stima RTT più accurata; vedere la Sezione 13.2 di [QUIC-TRANSPORT].
4.7. Probe Timeout Replaces RTO and TLP (Probe Timeout sostituisce RTO e TLP)
QUIC utilizza un probe timeout (PTO; vedere la Sezione 6.2), con un timer basato sul calcolo del retransmission timeout (RTO) di TCP; vedere [RFC6298]. Il PTO di QUIC include il ritardo di riconoscimento massimo atteso del peer invece di utilizzare un timeout minimo fisso.
Similmente all'algoritmo di rilevamento della perdita RACK-TLP per TCP [RFC8985], QUIC non riduce la finestra di congestione quando il PTO scade, poiché una singola perdita di pacchetto alla fine non indica una congestione persistente (Persistent Congestion). Invece, QUIC riduce la finestra di congestione quando viene dichiarata una congestione persistente; vedere la Sezione 7.6. In questo modo, QUIC evita riduzioni non necessarie della finestra di congestione, eliminando la necessità di meccanismi correttivi come Forward RTO-Recovery (F-RTO) [RFC5682]. Poiché QUIC non riduce la finestra di congestione alla scadenza di un PTO, un mittente QUIC non è limitato dall'invio di più pacchetti in volo dopo una scadenza di PTO se ha ancora finestra di congestione disponibile. Ciò si verifica quando un mittente è limitato dall'applicazione (Application Limited) e il timer PTO scade. Questo è più aggressivo del meccanismo RTO di TCP quando limitato dall'applicazione, ma identico quando non è limitato dall'applicazione.
QUIC permette ai pacchetti probe di superare temporaneamente la finestra di congestione ogni volta che il timer scade.
4.8. The Minimum Congestion Window Is Two Packets (La finestra di congestione minima è di due pacchetti)
TCP utilizza una finestra di congestione minima di un pacchetto. Tuttavia, la perdita di quel singolo pacchetto significa che il mittente deve attendere un PTO per recuperare (Sezione 6.2), che può essere molto più lungo di un RTT. L'invio di un singolo pacchetto che richiede riconoscimento aumenta anche le probabilità di incorrere in una latenza aggiuntiva quando un destinatario ritarda il suo riconoscimento.
QUIC raccomanda quindi che la finestra di congestione minima sia di due pacchetti. Sebbene ciò aumenti il carico di rete, è considerato sicuro poiché il mittente ridurrà comunque la sua velocità di invio esponenzialmente sotto congestione persistente (Sezione 6.2).
4.9. Handshake Packets Are Not Special (I pacchetti handshake non sono speciali)
TCP tratta la perdita di un pacchetto SYN o SYN-ACK come congestione persistente e riduce la finestra di congestione a un pacchetto; vedere [RFC5681]. QUIC tratta la perdita di un pacchetto contenente dati handshake allo stesso modo delle altre perdite.