QNAP開発・ネットワークエンジニアリングチーム各位
Googleの**BBR（Bottleneck Bandwidth and Round-trip propagation time）**をQTS/QuTS heroのデフォルトのTCP輻輳制御アルゴリズムとして実装すること、もしくは最低限「Network & Virtual Switch」GUIにユーザー選択可能なトグルの追加をご検討いただけますよう、正式に要望いたします。
現状、QTSはTCP CUBICをデフォルトとしています。しかしCUBICは歴史的には標準であったものの、LFN（Long Fat Network）や高遅延WAN/VPNのような現代的なネットワーク環境では損失ベースの性質ゆえに著しく性能が低下します。
私のインフラ環境・ユースケース：
-
NAS: QNAP TS-473A（16GB RAM、QTS 5.2.9）
-
ルーティング: 両端でMikroTik RB5009ルーターを利用
-
トポロジー: サイト間WireGuard VPNを1Gbps FTTH回線（国際ISPノード、主にTIM/O2経由、中程度の遅延と時折ごくわずかなパケットロス）で接続
-
ワークロード: WireGuardトンネル越しの高ビットレートメディアストリーミング（Plex Direct Play）や大容量ファイル転送
CUBICの課題: 標準通信時、WireGuardトンネルのスループットが約39Mbpsに大幅に制限されていました。広範なiperf3テストで、国際トランジットノード上の軽微で避けられないパケットロスをCUBICが過敏に検知し、輻輳ウィンドウを急激に半減して帯域を著しく押さえ込み、不要な再送が多発し、高ビットレートのストリーミングがトランスコーディングなしでは不可能となっていました（Ryzen V1500BはiGPUを持たないため、すべてCPUで処理されます）。
解決策および実証結果（BBR）： 問題切り分けのため、SSH経由でカーネルパラメータを手動で変更し、sysctl -w net.core.default_qdisc=fq sysctl -w net.ipv4.tcp_congestion_control=bbr を設定しました（永続化のためにはカスタムスクリプトをcrontabに登録する必要がありました。QTSはリブート時にsysctl.confを初期化してしまうためです）。
この切り替えによる効果は即座かつ劇的でした。損失ベースアルゴリズムから遅延ベースアルゴリズムに切り替えたことで：
-
スループットが10倍に向上： 同一のWireGuardトンネル上で約39Mbps→約380/400Mbpsまで向上しました。
-
安定性： パケット配送が非常に滑らかになり、4K Direct Playメディアのバッファリングが解消されました。
要望: 既に主要なLinuxディストリビューション、Windows 11、クラウドプロバイダーでは、現実のインターネットトポロジーに優れた適応性を持つBBRへと移行しています。QTSも基本は堅牢なLinuxシステムであり、カーネルには既にbbrモジュールが実装されています。
つきましては、下記をご検討ください：
-
TCP輻輳制御のデフォルトをCUBICからネイティブにBBRへ移行すること。
-
あるいは、Network & Virtual Switchインターフェース内にCUBIC/BBRを選択可能とするシンプルなプルダウンを設け、CLIやcrontabを介した非推奨なワークアラウンド（ファームウェア更新で上書きされる危険性あり）をユーザーが回避できるようにしていただくこと。
お忙しい中、優れたハードウェア開発を続けてくださり、ありがとうございます。本件のアーキテクチャ的改善について、フィードバックをお待ちしております。