4. Relevant Differences between QUIC and TCP (Relevante Unterschiede zwischen QUIC und TCP)
Leser, die mit der Verlusterkennung und Überlastkontrolle von TCP vertraut sind, werden hier Algorithmen finden, die bekannten TCP-Algorithmen ähneln. Die Protokollunterschiede zwischen QUIC und TCP tragen jedoch zu algorithmischen Unterschieden bei. Diese Protokollunterschiede werden im Folgenden kurz beschrieben.
4.1. Separate Packet Number Spaces (Separate Paketnummernräume)
QUIC verwendet separate Paketnummernräume (Packet Number Spaces) für jedes Verschlüsselungsniveau (Encryption Level), mit Ausnahme von 0-RTT und allen Generationen von 1-RTT-Schlüsseln, die denselben Paketnummernraum verwenden. Separate Paketnummernräume stellen sicher, dass die Bestätigung von Paketen, die mit einem Verschlüsselungsniveau gesendet wurden, keine falsche Neuübertragung (Spurious Retransmission) von Paketen verursacht, die mit einem anderen Verschlüsselungsniveau gesendet wurden. Die Überlastkontrolle und Rundlaufzeitmessung (RTT) sind über Paketnummernräume hinweg vereinheitlicht.
4.2. Monotonically Increasing Packet Numbers (Monoton steigende Paketnummern)
TCP vermischt die Übertragungsreihenfolge beim Sender mit der Zustellungsreihenfolge beim Empfänger, was zum Neuübertragungsambiguitätsproblem (Retransmission Ambiguity Problem) [RETRANSMISSION] führt. QUIC trennt die Übertragungsreihenfolge von der Zustellungsreihenfolge: Paketnummern geben die Übertragungsreihenfolge an, und die Zustellungsreihenfolge wird durch die Stream-Offsets (Stream Offsets) in STREAM-Frames bestimmt.
Die Paketnummer von QUIC ist innerhalb eines Paketnummernraums streng steigend und kodiert direkt die Übertragungsreihenfolge. Eine höhere Paketnummer bedeutet, dass das Paket später gesendet wurde, und eine niedrigere Paketnummer bedeutet, dass das Paket früher gesendet wurde. Wenn ein Paket, das bestätigungsauslösende Frames enthält, als verloren erkannt wird, fügt QUIC die erforderlichen Frames in ein neues Paket mit einer neuen Paketnummer ein, wodurch die Mehrdeutigkeit darüber beseitigt wird, welches Paket bestätigt wird, wenn ein ACK empfangen wird. Folglich können genauere RTT-Messungen durchgeführt werden, falsche Neuübertragungen werden trivial erkannt, und Mechanismen wie Fast Retransmit können universell angewendet werden, nur basierend auf der Paketnummer.
Dieser Designpunkt vereinfacht die Verlusterkennungsmechanismen für QUIC erheblich. Die meisten TCP-Mechanismen versuchen implizit, die Übertragungsreihenfolge basierend auf TCP-Sequenznummern abzuleiten -- eine nicht triviale Aufgabe, insbesondere wenn TCP-Zeitstempel nicht verfügbar sind.
4.3. Clearer Loss Epoch (Klarere Verlustepoche)
QUIC startet eine Verlustepoche (Loss Epoch), wenn ein Paket verloren geht. Die Verlustepoche endet, wenn ein nach Beginn der Epoche gesendetes Paket bestätigt wird. TCP wartet darauf, dass die Lücke im Sequenznummernraum gefüllt wird, und wenn ein Segment mehrmals hintereinander verloren geht, endet die Verlustepoche möglicherweise erst nach mehreren Rundläufen. Da beide ihr Überlastfenster nur einmal pro Epoche reduzieren sollten, wird QUIC dies einmal für jeden Rundlauf tun, der Verluste erfährt, während TCP dies möglicherweise nur einmal über mehrere Rundläufe hinweg tut.
4.4. No Reneging (Kein Widerruf)
QUIC-ACK-Frames enthalten Informationen ähnlich denen in TCP Selective Acknowledgments (SACKs) [RFC2018]. QUIC erlaubt jedoch nicht, dass eine Paketbestätigung widerrufen wird (Reneging), was die Implementierungen auf beiden Seiten erheblich vereinfacht und den Speicherdruck auf den Sender reduziert.
4.5. More ACK Ranges (Mehr ACK-Bereiche)
QUIC unterstützt viele ACK-Bereiche im Gegensatz zu den drei SACK-Bereichen von TCP. In Umgebungen mit hohen Verlusten beschleunigt dies die Wiederherstellung, reduziert falsche Neuübertragungen und gewährleistet Fortschritt ohne Abhängigkeit von Timeouts.
4.6. Explicit Correction for Delayed Acknowledgments (Explizite Korrektur für verzögerte Bestätigungen)
QUIC-Endpunkte messen die Verzögerung zwischen dem Empfang eines Pakets und dem Senden der entsprechenden Bestätigung, wodurch ein Peer eine genauere RTT-Schätzung aufrechterhalten kann; siehe Abschnitt 13.2 von [QUIC-TRANSPORT].
4.7. Probe Timeout Replaces RTO and TLP (Probe Timeout ersetzt RTO und TLP)
QUIC verwendet einen Probe Timeout (PTO; siehe Abschnitt 6.2) mit einem Timer, der auf der Berechnung des Retransmission Timeout (RTO) von TCP basiert; siehe [RFC6298]. QUICs PTO enthält die maximal erwartete Bestätigungsverzögerung des Peers anstelle eines festen minimalen Timeouts.
Ähnlich wie beim RACK-TLP-Verlusterkennungsalgorithmus für TCP [RFC8985] reduziert QUIC das Überlastfenster nicht, wenn der PTO abläuft, da ein einzelner Paketverlust am Ende keine persistente Überlast (Persistent Congestion) anzeigt. Stattdessen reduziert QUIC das Überlastfenster, wenn persistente Überlast festgestellt wird; siehe Abschnitt 7.6. Dadurch vermeidet QUIC unnötige Reduzierungen des Überlastfensters und macht Korrekturmechanismen wie Forward RTO-Recovery (F-RTO) [RFC5682] überflüssig. Da QUIC das Überlastfenster bei einem PTO-Ablauf nicht reduziert, ist ein QUIC-Sender nicht daran gehindert, nach einem PTO-Ablauf mehr Pakete im Flug zu senden, wenn noch verfügbares Überlastfenster vorhanden ist. Dies tritt auf, wenn ein Sender anwendungsbegrenzt (Application Limited) ist und der PTO-Timer abläuft. Dies ist aggressiver als TCPs RTO-Mechanismus bei Anwendungsbegrenzung, aber identisch, wenn keine Anwendungsbegrenzung vorliegt.
QUIC erlaubt es Probe-Paketen, das Überlastfenster vorübergehend zu überschreiten, wann immer der Timer abläuft.
4.8. The Minimum Congestion Window Is Two Packets (Das minimale Überlastfenster besteht aus zwei Paketen)
TCP verwendet ein minimales Überlastfenster von einem Paket. Der Verlust dieses einzelnen Pakets bedeutet jedoch, dass der Sender auf einen PTO warten muss, um sich zu erholen (Abschnitt 6.2), was viel länger als eine RTT sein kann. Das Senden eines einzelnen bestätigungsauslösenden Pakets erhöht auch die Wahrscheinlichkeit zusätzlicher Latenz, wenn ein Empfänger seine Bestätigung verzögert.
QUIC empfiehlt daher, dass das minimale Überlastfenster zwei Pakete beträgt. Obwohl dies die Netzwerklast erhöht, wird es als sicher angesehen, da der Sender seine Senderate bei persistenter Überlast weiterhin exponentiell reduziert (Abschnitt 6.2).
4.9. Handshake Packets Are Not Special (Handshake-Pakete sind nicht speziell)
TCP behandelt den Verlust eines SYN- oder SYN-ACK-Pakets als persistente Überlast und reduziert das Überlastfenster auf ein Paket; siehe [RFC5681]. QUIC behandelt den Verlust eines Pakets, das Handshake-Daten enthält, wie andere Verluste.