4. Relevant Differences between QUIC and TCP (Différences pertinentes entre QUIC et TCP)
Les lecteurs familiers avec la détection de perte et le contrôle de congestion de TCP trouveront ici des algorithmes qui sont parallèles à des algorithmes TCP bien connus. Cependant, les différences de protocole entre QUIC et TCP contribuent aux différences algorithmiques. Ces différences de protocole sont brièvement décrites ci-dessous.
4.1. Separate Packet Number Spaces (Espaces de numéros de paquets séparés)
QUIC utilise des espaces de numéros de paquets (Packet Number Spaces) séparés pour chaque niveau de chiffrement (Encryption Level), à l'exception du 0-RTT et de toutes les générations de clés 1-RTT qui utilisent le même espace de numéros de paquets. Les espaces de numéros de paquets séparés garantissent que l'accusé de réception des paquets envoyés avec un niveau de chiffrement ne provoquera pas de retransmission erronée (Spurious Retransmission) des paquets envoyés avec un niveau de chiffrement différent. Le contrôle de congestion et la mesure du temps aller-retour (RTT) sont unifiés à travers les espaces de numéros de paquets.
4.2. Monotonically Increasing Packet Numbers (Numéros de paquets croissants de manière monotone)
TCP confond l'ordre de transmission à l'expéditeur avec l'ordre de livraison au destinataire, ce qui entraîne le problème d'ambiguïté de retransmission (Retransmission Ambiguity Problem) [RETRANSMISSION]. QUIC sépare l'ordre de transmission de l'ordre de livraison : les numéros de paquets indiquent l'ordre de transmission, et l'ordre de livraison est déterminé par les décalages de flux (Stream Offsets) dans les trames STREAM.
Le numéro de paquet de QUIC est strictement croissant dans un espace de numéros de paquets et encode directement l'ordre de transmission. Un numéro de paquet plus élevé signifie que le paquet a été envoyé plus tard, et un numéro de paquet plus faible signifie que le paquet a été envoyé plus tôt. Lorsqu'un paquet contenant des trames provoquant un accusé de réception est détecté comme perdu, QUIC inclut les trames nécessaires dans un nouveau paquet avec un nouveau numéro de paquet, éliminant l'ambiguïté sur quel paquet est accusé réception lorsqu'un ACK est reçu. Par conséquent, des mesures RTT plus précises peuvent être effectuées, les retransmissions erronées sont trivialement détectées, et des mécanismes tels que la retransmission rapide (Fast Retransmit) peuvent être appliqués universellement, uniquement sur la base du numéro de paquet.
Ce point de conception simplifie considérablement les mécanismes de détection de perte pour QUIC. La plupart des mécanismes TCP tentent implicitement de déduire l'ordre de transmission en fonction des numéros de séquence TCP -- une tâche non triviale, en particulier lorsque les horodatages TCP ne sont pas disponibles.
4.3. Clearer Loss Epoch (Époque de perte plus claire)
QUIC démarre une époque de perte (Loss Epoch) lorsqu'un paquet est perdu. L'époque de perte se termine lorsqu'un paquet envoyé après le début de l'époque est accusé réception. TCP attend que l'écart dans l'espace de numéros de séquence soit comblé, et donc si un segment est perdu plusieurs fois de suite, l'époque de perte peut ne pas se terminer pendant plusieurs allers-retours. Étant donné que les deux doivent réduire leurs fenêtres de congestion une seule fois par époque, QUIC le fera une fois pour chaque aller-retour qui connaît une perte, tandis que TCP peut ne le faire qu'une seule fois sur plusieurs allers-retours.
4.4. No Reneging (Pas de renégation)
Les trames ACK de QUIC contiennent des informations similaires à celles des accusés de réception sélectifs TCP (SACKs) [RFC2018]. Cependant, QUIC ne permet pas qu'un accusé de réception de paquet soit renégocié (Reneging), ce qui simplifie grandement les implémentations des deux côtés et réduit la pression mémoire sur l'expéditeur.
4.5. More ACK Ranges (Plus de plages ACK)
QUIC prend en charge de nombreuses plages ACK, contrairement aux trois plages SACK de TCP. Dans les environnements à perte élevée, cela accélère la récupération, réduit les retransmissions erronées et assure une progression sans dépendre des délais d'attente.
4.6. Explicit Correction for Delayed Acknowledgments (Correction explicite pour les accusés de réception retardés)
Les points de terminaison QUIC mesurent le délai encouru entre le moment où un paquet est reçu et le moment où l'accusé de réception correspondant est envoyé, permettant à un pair de maintenir une estimation RTT plus précise ; voir la section 13.2 de [QUIC-TRANSPORT].
4.7. Probe Timeout Replaces RTO and TLP (Le délai de sonde remplace RTO et TLP)
QUIC utilise un délai de sonde (PTO, Probe Timeout ; voir la section 6.2), avec une minuterie basée sur le calcul du délai de retransmission (RTO, Retransmission Timeout) de TCP ; voir [RFC6298]. Le PTO de QUIC inclut le délai d'accusé de réception maximal attendu du pair au lieu d'utiliser un délai d'attente minimal fixe.
Similaire à l'algorithme de détection de perte RACK-TLP pour TCP [RFC8985], QUIC ne réduit pas la fenêtre de congestion lorsque le PTO expire, car une seule perte de paquet à la fin n'indique pas une congestion persistante (Persistent Congestion). Au lieu de cela, QUIC réduit la fenêtre de congestion lorsqu'une congestion persistante est déclarée ; voir la section 7.6. Ce faisant, QUIC évite les réductions inutiles de la fenêtre de congestion, éliminant le besoin de mécanismes correctifs tels que Forward RTO-Recovery (F-RTO) [RFC5682]. Étant donné que QUIC ne réduit pas la fenêtre de congestion lors d'une expiration de PTO, un expéditeur QUIC n'est pas limité dans l'envoi de plus de paquets en vol après une expiration de PTO s'il dispose encore d'une fenêtre de congestion disponible. Cela se produit lorsqu'un expéditeur est limité par l'application (Application Limited) et que la minuterie PTO expire. C'est plus agressif que le mécanisme RTO de TCP lorsqu'il est limité par l'application, mais identique lorsqu'il ne l'est pas.
QUIC permet aux paquets de sonde de dépasser temporairement la fenêtre de congestion chaque fois que la minuterie expire.
4.8. The Minimum Congestion Window Is Two Packets (La fenêtre de congestion minimale est de deux paquets)
TCP utilise une fenêtre de congestion minimale d'un paquet. Cependant, la perte de ce paquet unique signifie que l'expéditeur doit attendre un PTO pour récupérer (section 6.2), ce qui peut être beaucoup plus long qu'un RTT. L'envoi d'un seul paquet provoquant un accusé de réception augmente également les chances d'encourir une latence supplémentaire lorsqu'un destinataire retarde son accusé de réception.
QUIC recommande donc que la fenêtre de congestion minimale soit de deux paquets. Bien que cela augmente la charge réseau, cela est considéré comme sûr car l'expéditeur réduira toujours son taux d'envoi de manière exponentielle en cas de congestion persistante (section 6.2).
4.9. Handshake Packets Are Not Special (Les paquets de handshake ne sont pas spéciaux)
TCP traite la perte d'un paquet SYN ou SYN-ACK comme une congestion persistante et réduit la fenêtre de congestion à un paquet ; voir [RFC5681]. QUIC traite la perte d'un paquet contenant des données de handshake de la même manière que les autres pertes.