Linux向け Multipath TCP（2022年）

 (mptcp.dev)
1 ポイント 投稿者 GN⁺ 2024-04-21 | 1件のコメント | WhatsAppで共有

Multipath TCP の概要

  • Multipath TCP（MPTCP）は標準 TCP の拡張版で、RFC 8684 に記載されている
  • デバイスが同時に複数のインターフェースを使用し、単一の MPTCP 接続を通じて TCP パケットを送受信できるようにする
  • MPTCP は複数インターフェースの帯域幅を集約したり、最も遅延の短いインターフェースを優先したりできる
  • また、1 つの経路がダウンしてもフェイルオーバーが可能で、トラフィックは別の経路へシームレスに再投入される

MPTCP のユースケース

  • MPTCP を使って複数の経路を並列または同時に利用できるようになることで、TCP と比べて新たなユースケースが生まれる:
    • Seamless handovers: 接続を維持したまま、ある経路から別の経路へ切り替える。Apple はこの理由で 2013 年から主にスマートフォンで MPTCP を使用している。
    • Best network selection: 遅延、損失、コスト、帯域幅などの条件に応じて「最適な」経路を使用する。
    • Network aggregation: より高いスループットのために複数の経路を同時に使う。例: ファイルをより速く送るために固定回線とモバイルネットワークを組み合わせる。

MPTCP の概念

  • IPPROTO_MPTCP プロトコル（Linux 専用）で新しいソケットを作成すると、1 つのインターフェースを通じてデータを送るために使用される通常の TCP 接続からなるサブフロー（または経路）が作られる
  • 追加のサブフローは後でホスト間でネゴシエートできる
  • リモートホストが MPTCP の使用を検出できるよう、基本 TCP サブフローの TCP オプションフィールドに新しいフィールドが追加されている
  • このフィールドには、相手ホストが MPTCP をサポートしている場合に使用するよう知らせる MP_CAPABLE オプションなどが含まれる
  • リモートホストまたは途中のミドルボックスが MPTCP をサポートしていない場合、返された SYN+ACK パケットの TCP オプションフィールドには MPTCP オプションが含まれない
  • この場合、接続は通常の TCP に「ダウングレード」され、単一経路で継続される

このような動作は、Path Manager と Packet Scheduler という 2 つの内部コンポーネントによって可能になっている。

Path Manager

  • Path Manager はサブフローの作成から削除までを担当し、アドレス通知も担当する
  • 一般にクライアント側でサブフローを開始し、サーバー側で ADD_ADDR および REMOVE_ADDR オプションを通じて追加アドレスを通知する
  • Linux v5.19 時点では、net.mptcp.pm_type sysctl ノブで制御される 2 つの Path Manager がある:
    • in-kernel（タイプ 0）: すべての接続に同じルールを適用（ip mptcp を参照）
    • userspace（タイプ 1）: ユーザー空間デーモン（例: mptcpd）によって制御され、各接続に異なるルールを適用できる

Packet Scheduler

  • Packet Scheduler は、利用可能なサブフローの中から次のデータパケット送信に使うサブフローを選択する役割を持つ
  • 利用可能な帯域幅の活用を最大化したり、最も遅延の短い経路だけを選んだり、設定に応じて別のポリシーを決定できる
  • Linux v6.8 時点では、net.mptcp の sysctl ノブで制御される単一の Packet Scheduler しかない

MPTCP の主な特徴（Linux v6.10 時点）

  • socket() システムコールでの IPPROTO_MPTCP プロトコル対応
  • ピアまたはミドルボックスが MPTCP をサポートしない場合、MPTCP から TCP へフォールバック
  • カーネル内部またはユーザー空間の経路マネージャーを用いた経路管理
  • TCP ソケットで一般に使われるソケットオプション
  • MIB カウンター、diag サポート（ss コマンドで使用）、トレースポイントを含むデバッグ機能

GN⁺の意見

  • MPTCP は、端末が複数のネットワークに接続されている場合に非常に有用な技術である。5G-Wi-Fi ハンドオーバーや異種ネットワーク集約などに効果的に活用できる。
  • ただし、MPTCP をサポートするサーバーとクライアントの双方に実装が必要であり、中間ネットワークでも MPTCP への対応が求められるという制約がある。普及までには時間がかかりそうだ。
  • Google の QUIC プロトコルも類似のマルチパス機能を提供しており、QUIC のほうがよりシンプルで UDP ベースのため、より速く普及する可能性がある。MPTCP と QUIC の競争が予想される。
  • カーネル依存の Linux 向け MPTCP 実装とは異なり、Apple は独自にユーザー空間で MPTCP を実装し、iOS と macOS に搭載している。Google も同様のアプローチを取る可能性がありそうだ。
  • MPTCP の経路制御やスケジューリングポリシーをアプリケーション要件に最適化するには、アプリケーションと MPTCP の間で API を通じた情報交換が必要だと思われる。これに対する標準化された方法はまだないとみられる。

関連記事

1件のコメント

 
GN⁺ 2024-04-21
Hacker Newsの意見
  • 2013年にMPTCPのことを初めて聞いたとき、モバイルアプリはネットワーク変更への対応力が弱かったので、ユーザー体験の改善に大いに役立つだろうと思ったが、10年経ってもほとんど注目されていないのは非常に残念だ
  • IPv4の32ビットアドレス空間と、TCPが接続タプルに送信元/宛先IPアドレスを使うことのどちらがより悲しいのかわからない。タイムマシンがあれば過去に戻ってこの2つを変えたい
  • MPTCPの実用的な使い道は、モバイル回線とWi‑Fiネットワークを同時に使って速度を上げることだが、モバイルデータ料金プランのせいで個人的には常に無効にしており、役に立たない
  • OpenWrt派生プロジェクトなど、MPTCPを使っているプロジェクトへのリンクがないのは残念だ。2年間、GSOCでOpenWrtにMPTCPサポートをパッチする学生のメンターを務めた
  • 透過的なフォールバックがあるなら、なぜアプリケーションの明示的なオプトインが必要なのか疑問だ。カーネルがすべてのTCP接続を透過的に処理し、経路集約/リンク優先度についてグローバルな決定を下すのが最も理にかなっているように思える
  • Linuxネットワークスタックとドライバのサポート/デバッグ/修正の仕事をしているが、MPTCPの採用率の低さには驚かされる。SCTPのように既存のTCPを置き換えようとしたものはすべて、少数の開発者にしか使われず、残りの世界からは忘れられる運命にあるようだ
  • MPTCPとQUICのアーキテクチャの違い、そして著者らが提案したMPQUICプロトコルを説明する論文を見つけた。QUICは単一のUDPフロー上でアプリケーションストリームを多重化し、MPTCPは単一ストリームを複数のTCPサブフローに分割する。MPQUICは複数のUDPサブフロー上でアプリケーションストリームを多重化することで、この2つの機能を組み合わせている
  • AppleもMPTCPをサポートしており、Siriで使用している
  • 途中のミドルボックスがMPTCPオプションをサポートしていない場合、SYN+ACKパケットにMPTCPオプションが含まれないという点はかなり制約が大きく見える。ミドルボックスに求められる唯一の要件は、MPTCPオプションをそのまま通過させることなのだろうか？
  • MPTCPはセキュリティ/プライバシー設定に役立つ可能性がある。たとえば複数のアップリンクチャネルにトラフィックを分割すれば、中国政府のファイアウォールが遮断のためにトラフィックを再結合するのが難しくなる