QUIC ist im schnellen Internet nicht schnell genug

• QUIC gilt als Protokoll, das die Performance von Webanwendungen grundlegend verbessern soll, doch die Leistung bleibt hinter den Erwartungen zurück
• Diese Arbeit analysiert die Performance von QUIC in Hochgeschwindigkeitsnetzwerken systematisch

Abstract

• Im schnellen Internet zeigt der Stack aus UDP+QUIC+HTTP/3 im Vergleich zu TCP+TLS+HTTP/2 einen um bis zu 45,2 % geringeren Datendurchsatz
• Die Performance-Lücke zwischen QUIC und HTTP/2 wird größer, je höher die verfügbare Grundbandbreite ist
• Dieses Problem wurde bei leichtgewichtigen Datenübertragungs-Clients und in gängigen Webbrowsern (Chrome, Edge, Firefox, Opera), auf verschiedenen Hosts (Desktop, Mobilgeräte) und in unterschiedlichen Netzwerken (kabelgebundenes Breitband, Mobilfunk) beobachtet
• Betroffen sind nicht nur Dateiübertragungen, sondern auch verschiedene Anwendungen wie Video-Streaming (bis zu 9,8 % geringere Video-Bitrate) und Web-Browsing
• Durch strenge Paket-Trace-Analysen sowie Profiling im Kernel- und User-Space wurden die grundlegenden Ursachen identifiziert
• Insbesondere ist der Verarbeitungs-Overhead auf Empfängerseite durch eine übermäßige Zahl von Datenpaketen und QUIC-ACKs im User-Space hoch
• Es werden konkrete Empfehlungen vorgestellt, um die beobachteten Performance-Probleme abzumildern

Grundursachen des Performance-Abfalls

• Übermäßiger Overhead bei der Paketverarbeitung auf Empfängerseite auf Kernel-Ebene
  • QUIC verwendet kein UDP GRO (Generic Receive Offload) und muss daher im Vergleich zu TCP deutlich mehr Pakete verarbeiten
  • Das zeigt sich daran, dass die Funktion netif_receive_skb bei QUIC wesentlich häufiger aufgerufen wird
• Auch im User-Space entsteht bei QUIC übermäßiger Overhead bei der Paketverarbeitung
  • Die Verarbeitung der vielen vom Kernel übergebenen Pakete verursacht erheblichen Overhead
  • Auch die Erzeugung von QUIC-ACKs im User-Space trägt dazu bei

Vorschläge zur Minderung des Performance-Abfalls

• Einführung von UDP GRO auf Empfängerseite
  • Verringert die Zahl der im UDP-Stack zu verarbeitenden Pakete und reduziert so den Overhead im Kernel und im User-Space
  • Allerdings ist die Bereitstellung von UDP GRO in unterschiedlichen Client-Umgebungen möglicherweise nicht einfach
• Offloading-Lösungen wie GSO/GRO besser auf QUIC abstimmen
  • Unterstützung dafür, auch UDP-Paketfolgen mit unterschiedlichen Größen offloaden zu können
  • Geeignete Pacing-Einstellungen zu GSO hinzufügen, um Netzüberlastung zu vermeiden
• Optimierung der QUIC-Logik auf Empfängerseite
  • Das Senden von QUIC-ACKs verzögern, um den Overhead bei der Antworterzeugung zu reduzieren
  • Mit recvmmsg mehrere UDP-Pakete auf einmal lesen, um die Performance zu verbessern
• Verwendung von Multi-Thread-Downloads
  • Bei großen Dateien kann die Empfangsleistung durch Multi-Thread-Downloads unter Nutzung mehrerer CPU-Kerne verbessert werden
  • Allerdings müssen Fairness-Probleme berücksichtigt werden

[GN⁺]

Hacker-News-Kommentar

• Die syscall-Schnittstelle ist komplex, und die grundlegende API ist für Pakete normaler Größe (ca. 1500 Byte) zu langsam
  • GSO hilft, aber die API ist komplex und hatte bis vor Kurzem noch viele Bugs
• Durch Spectre-Abmilderungen sind syscalls teurer geworden
  • BSD-Sockets-/POSIX-APIs müssen ersetzt werden
  • uring ist komplex, aber es wird eine API auf mittlerer Ebene benötigt
• Die systemseitigen UDP-Puffer sind standardmäßig zu klein
  • Nur Experten nutzen sie, und diese passen die Einstellungen an
• Der UDP-Stack lässt sich optimieren
  • GSO zeigt das, aber GSO selbst ist teuer und komplex
• Einige derzeit verfügbare Optimierungen funktionieren nur im kleinen bis mittleren Maßstab
  • Zum Beispiel das Binden von Verbindungen, um Pfad-Lookups zu vermeiden
• Die Implementierung von GSO kann die Performance deutlich verbessern
  • Wahrscheinlich müsste die Plattformseite die Puffergrößen erhöhen
• Zu Beginn von QUIC war der UDP-Stack weniger optimiert als der TCP-Stack
  • Optimierungen wie UDP Generic Receive Offload sind nötig
• Auch HTTP/2 wirkt, als sei es überhastet veröffentlicht worden
  • Chrome hat die Unterstützung für Server Push entfernt
  • Es braucht mehr Nachdenken
• QUIC und HTTP/2 zeigen bei geringer Netzwerkbandbreite eine ähnliche Performance
  • Bei Bandbreiten über 500 Mbps fällt die QUIC-Performance ab
  • Das ist vor allem in lokalen Netzwerken ein Problem
• Google neigt dazu, die Verarbeitungslast auf die Nutzer abzuwälzen
  • Zum Beispiel wurde der AV1-Videocodec ausgeliefert, obwohl Verbraucher keine HW-Decodierung hatten
• Das Forschungspapier ist auf arXiv verfügbar
  • https://arxiv.org/pdf/2310.09423
• Erwähnung eines Pings mit einer RTT von 0,23 ms
  • Auch bei hoher Latenz ist QUIC am besten
• RFC9000 zu lesen ist schwierig und komplex
  • Die übergeordnete Idee von QUIC ist einfach, aber die Spezifikation verlangt viele Sonderfallbehandlungen
• Kostenlose PDF-Datei der Studie verfügbar
  • https://arxiv.org/pdf/2310.09423
• Das Verschieben des Verbindungsprotokolls in den User Space ist möglicherweise kein guter Plan