An das QNAP-Entwicklungs- und Netzwerkengineering-Team,
ich möchte hiermit offiziell darum bitten, Googles BBR (Bottleneck Bandwidth and Round-trip propagation time) als Standard-Algorithmus zur TCP-Staukontrolle in QTS/QuTS hero zu implementieren – oder zumindest die Einführung einer anwählbaren Option im „Network & Virtual Switch“-GUI.
Aktuell verwendet QTS standardmäßig TCP CUBIC. Obwohl CUBIC historisch als Standard galt, liefert es in modernen LFNs (Long Fat Networks) und High-Latency-WAN/VPN-Szenarien aufgrund seines verlustbasierten Ansatzes äußerst schlechte Ergebnisse.
Meine Infrastruktur & Anwendungsfall:
-
NAS: QNAP TS-473A (16 GB RAM, QTS 5.2.9)
-
Routing: MikroTik RB5009 Router auf beiden Seiten
-
Topologie: Site-to-Site WireGuard VPN über eine 1 Gbps FTTH-Leitung (Routing über internationale ISP-Knotenpunkte, vor allem TIM/O2, mit moderater Latenz und gelegentlichen, minimalen Paketverlusten)
-
Workload: Hochbitratiges Medienstreaming (Plex Direct Play) und große Dateiübertragungen über den WireGuard-Tunnel.
Das Problem mit CUBIC: Im normalen Betrieb war der Durchsatz des WireGuard-Tunnels drastisch auf ca. 39 Mbps begrenzt. Umfangreiche iperf3-Tests zeigten, dass CUBIC aufgrund geringem, aber unvermeidbaren Paketverlusts entlang der internationalen Transitknoten das Congestion Window aggressiv halbierte. Der verlustbasierte Algorithmus würgte die verfügbare Bandbreite ab, was zu tausenden unnötigen Retransmits führte und hochbitratiges Streaming ohne Transkodierung unmöglich machte (was der Ryzen V1500B mangels iGPU komplett per CPU stemmen muss).
Die Lösung & empirische Ergebnisse (BBR): Um das Problem einzugrenzen, habe ich die Kernel-Parameter manuell per SSH angepasst:
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
(Um diese Änderung persistent zu machen, musste ich ein eigenes Skript per crontab starten, da QTS die sysctl.conf beim Neustart überschreibt).
Die Resultate waren unmittelbar und beeindruckend. Durch den Wechsel von einem verlust- zu einem latenzbasierten Algorithmus:
-
Steigerte sich der Durchsatz um das 10-fache: von ca. 39 Mbps auf ca. 380/400 Mbps über denselben verschlüsselten WireGuard-Tunnel.
-
Stabilität: Die Paketübertragung wurde vollständig geglättet, Pufferungen bei 4K-Direct-Play entfielen komplett.
Die Bitte: Moderne Linux-Distributionen, Windows 11 und große Cloud-Anbieter setzen bereits auf BBR, da es reale Internet-Topologien wesentlich besser abdeckt. QTS ist im Kern ein leistungsfähiges Linux-System, und der Kernel unterstützt das bbr-Modul bereits.
Ich bitte das Entwicklerteam daher:
-
Die native Migration vom TCP-Staukontroll-Standard CUBIC auf BBR vorzunehmen.
-
Alternativ zumindest eine einfache Dropdown-Option im Network & Virtual Switch-Interface bereitzustellen, um fortgeschrittenen Nutzern den Wechsel zwischen CUBIC und BBR ohne CLI- oder crontab-Workarounds zu ermöglichen, die möglicherweise durch Firmware-Updates überschrieben werden.
Herzlichen Dank für Ihre Zeit und die stetige Weiterentwicklung großartiger Hardware. Ich freue mich auf Feedback zu dieser architektonischen Verbesserung.