Linux向けMultipath TCP（2022年）

 (mptcp.dev)
1 ポイント 投稿者 GN⁺ 2024-04-21 | 1件のコメント | WhatsAppで共有
  • MPTCP は RFC 8684 ベースの TCP 拡張で、1つの接続が複数のネットワークインターフェースを同時に使うことで、帯域幅・遅延・障害対応を改善する
  • 複数の経路を並列に使う構造のため、帯域幅の集約、低遅延経路の優先、経路障害時の別経路への再注入が可能
  • Linux では IPPROTO_MPTCP でソケットを作成し、通常の TCP 接続である subflow を構成する。相手側や中間機器が対応していない場合は、単一経路 TCP に自動でフォールバックする
  • 経路管理には、Linux v5.19 時点でカーネル内蔵方式と mptcpd のようなユーザー空間デーモン方式があり、Linux v6.8 時点のパケットスケジューラは net.mptcp sysctl で制御されるものが1つだけある
  • Linux v6.10 時点の機能には、socket() 対応、TCP へのフォールバック、カーネル/ユーザー空間の経路管理、TCP ソケットオプション、MIB・ss 診断・tracepoint デバッグ機能まで含まれる

MPTCPが変えるTCP接続方式

  • Multipath TCP（MPTCP） は標準 TCP の拡張で、RFC 8684 で定義されている
  • 1つの MPTCP 接続は、複数のインターフェースを同時に使用して TCP パケットを送受信できる
  • 複数インターフェースの 帯域幅を集約したり、遅延時間が最も低いインターフェースを優先したりできる
  • ある経路が切断された場合、トラフィックを別の経路へ滑らかに再注入して フェイルオーバー を行う
  • 通常の TCP が一度に1つの経路を使うのに対し、MPTCP は 5G や Wi‑Fi など複数の経路を subflow として同時に利用できる

代表的なユースケース

  • 切れ目のないハンドオーバー

    • 既存の接続を維持したまま、ある経路から別の経路へ切り替えられる
    • Apple は 2013年から、主にこの理由でスマートフォンに Multipath TCP を使用している

  • 最適なネットワーク選択

    • 遅延時間、損失、コスト、帯域幅などの条件に応じて、利用可能な経路の中から「最良」の経路を選ぶ

  • ネットワーク集約

    • 複数の経路を同時に使ってスループットを高められる
    • 固定網とモバイルネットワークを組み合わせ、ファイルをより高速に転送する方式が例として挙げられる

Linuxで接続が確立される仕組み

  • Linux 専用の IPPROTO_MPTCP プロトコルで新しいソケットを作成すると、subflow または path が作成される
  • subflow は、1つのインターフェースを通じてデータを転送する通常の TCP 接続である
  • その後、ホスト間のネゴシエーションを経て追加の subflow を作成できる
  • 基盤となる TCP subflow の TCP option フィールドには、相手ホストが MPTCP の使用を検出できるよう新しいフィールドが追加される
    • このフィールドには、相手に MPTCP の使用を知らせる MP_CAPABLE オプションなどが入る
  • 相手ホストや途中の middlebox が MPTCP に対応していない場合、返される SYN+ACK パケットの TCP option フィールドには MPTCP オプションがない
    • この場合、接続は通常の TCP へ フォールバック し、単一経路で継続される

Path ManagerとPacket Scheduler

  • MPTCP は内部的に Path Manager と Packet Scheduler が、subflow の作成、アドレス通知、送信経路選択を分担して処理する

  • Path Manager

    • Path Manager は subflow の作成から削除までを管理し、アドレス通知も担当する
    • 一般にクライアント側が subflow を開始し、サーバー側は ADD_ADDR と REMOVE_ADDR オプションで追加アドレスを通知する
    • Linux v5.19 時点では、net.mptcp.pm_type sysctl knob で2種類の path manager を制御する
      • type 0: カーネル内蔵方式で、すべての接続に同じルールを適用する。ip mptcp に関連する
      • type 1: ユーザー空間方式で、mptcpd のようなデーモンが制御し、接続ごとに異なるルールを適用できる

  • Packet Scheduler

    • Packet Scheduler は、次のデータパケットを送るときに使用する subflow を選択する
    • 利用可能な帯域幅を最大化したり、遅延時間がより低い経路だけを選んだり、設定に応じた別のポリシーを適用したりできる
    • Linux v6.8 時点ではパケットスケジューラは1つだけで、net.mptcp の sysctl knob で制御される

Linux v6.10時点の機能

  • Linux v6.10 時点で MPTCP は次の機能を提供する
    • socket() システムコールでの IPPROTO_MPTCP プロトコル対応
    • 相手側や middlebox が MPTCP に対応していない場合の、MPTCP から TCP への フォールバック
    • カーネル内蔵またはユーザー空間 path manager を使う経路管理
    • TCP ソケットで一般的に使われるソケットオプション
    • MIB カウンター、ss コマンドが使用する diag 対応、tracepoint を含むデバッグ機能
  • 詳細な変更点は ChangeLog で確認できる

コミュニケーションと関連プロジェクト

カーネル開発リソース

関連記事

1件のコメント

 
GN⁺ 2024-04-21
Hacker News のコメント

  • MPTCP は2013年にはすでに聞いたことがあった
    当時のモバイルアプリがネットワークの切り替えにあまり強くなかったことを考えると、UX 改善の幅が大きく、すぐ採用されると思っていた
    ところがこの10年でほとんど traction を得られず、今になってようやくカーネルオプションが出てくるのはかなり憂鬱。その間にみんな HTTP 呼び出しを複数のリトライハンドラで包むようになり、モバイル OS はネットワーク接続性を抽象化しすぎて、TCP というより zeromq を使っている感覚に近くなった

    • 革新のエネルギーの多くが QUIC に移ったように思う。TCP では新しい変種をうまく作っても、中間機器が勝手に壊してしまう可能性があるため
      例は https://blog.apnic.net/2021/12/08/efficient-multipath-transp... を参照
    • 好きになりたかったし、Apple も iOS に入れたが、実際のサーバーで対応するのが難しすぎた
      FreeBSD にロードバランサーなしでデプロイしたときは最新パッチがなく、仮にあったとしても、プライベートネットワークの IP を代替経路として広告しないようにするには相当な作業が必要だった
      Linux でロードバランサーの背後にいる場合は、ストリームを正しい場所に送るのが複雑すぎ、ロードバランサー側もそれをやろうとしなかった
      2つのストリームを一緒に処理するのは 高スループット経路 に大きな複雑さを入れることになりリスクが大きく、変更するには再起動も必要
      そこまでやってもメリットは主に iOS ユーザーにしか及ばず、そのユーザーたちはそもそもより良いネットワークを使っている傾向がある
    • 2000年に登場した SCTP も注目に値する。これもいまだにほとんど採用されていない
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • 配送ロボットを作っていたとき、セルラーモデム2台で即時フェイルオーバーをしたくて MPTCP に期待していた
      結局、開発時間を節約するために PepLink の SpeedFusion を使ったが、ライセンス費用は高かった。今後、2つのセルラーネットワークと 50ms 未満のフェイルオーバーのための無料の解決策が出てくることを望む
      マルチパス UDP + OpenVPN も、おそらく実用的な解決策になり得る
    • むしろ、これが受けるに値しない注目を集めているのが憂鬱。TCP は現代の環境で半分程度のユースケースにだけ雑に合うハックを1つずつ足して組み合わせを選ばせるのではなく、SCTP に置き換えられるべき

  • IPv4 アドレス空間が 32ビット しかないことと、TCP が接続タプルに送信元/宛先 IP アドレスを使うことのどちらがより悲しいのか分からない
    タイムマシンがあれば Cerf と Kahn のもとに戻って、両方とも変えさせたい

    • TCP をどう変えたいという意味なのか気になる
      両側の IP アドレスとポート、つまり4つのフィールドで接続を追跡しなければならない構造のことを言っているのか？
    • 彼らはすでに ソースルーティング を与えてくれていて、それが望むものの半分であり、オプションとして正しく仕様化されていると言いそう

  • MPTCP を使っているプロジェクト、たとえば OpenWrt 派生プロジェクト へのリンクがないのが残念
    GSOC で2年間学生をメンタリングし、OpenWrt に MPTCP をパッチしたことがある
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • このプロジェクトは興味深いかもしれない: https://github.com/Ysurac/openmptcprouter
      最近、完全な光回線は引けないが 5G で 150〜400Mbps は出る物件を買った。5G 回線を2つ使い、MPTCP で VPS までトラフィックをトンネリングして回線を束ねる案を考えている
    • 最近 Home Assistant HAOS カーネル で有効化された
      https://github.com/home-assistant/operating-system/pull/3248
    • OpenWrt での一例はこれ
      http://www.openmptcprouter.com/
    • OpenWrt ルーターが MPTCP をサポートするとどんな利点があるのか気になる
      Web サーバーとモバイル機器でサポートされることが最も重要そう

  • 透過的な代替経路があるなら、なぜアプリケーション側の明示的な選択が必要なのか分からない
    カーネルがすべての TCP 接続に対して透過的に処理したほうが、経路集約やリンク優先度のような グローバルな判断 をよりうまくできるのではないかと思う

    • Linux TCP/ネットワーキングサブシステムのメンテナーたちが事実上強制した条件だと理解している。初期の upstream 議論[1]を見ると、これが基本ルールになっていた
      upstream 前の古いマルチパス TCP 実装は、アプリケーションに対して完全に透過的であることを意図しており、プロトコルの目的にはそちらのほうが合っていると思う
      もちろん多くの場合、MPTCP はアプリケーションから指示を受けたほうが良くなる可能性はあるが、たとえば LTE 接続にサブフローを作って自動フェイルオーバーには備えつつ、そのサブフローではデータを送らないという標準的なシステムのアプローチだけでも、95% のケースでは十分だったはず
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • これを使うということは、1つの TCP 接続について両端点それぞれに 複数の IP が結び付く可能性があるということ。多くの場合、アプリケーションの明示的なサポートや認識が必要になる
    • 複数の IP が同じ TCP 接続上で通信することを許すと、新たな セキュリティホール が生まれる可能性がある
      たとえば接続時点でクライアント IP をホワイトリストと照合し、その後は変わらないと仮定しているアプリケーションが考えられる

  • 私にとってMPTCPの唯一の実用的な用途は、モバイルネットワークとWi-Fiを併用して速度を上げること。iOSもWeChatもこれをサポートしている。
    ただしモバイルネットワークは従量課金なので、いつもオフにしている。だから個人的にはMPTCPは役に立たない。

    • この問題を扱ったことがある。社内では駐車場バグと呼んでいた。
      Wi-Fiの電波はまだ見えているが、ちゃんと接続できない状況のこと。MPTCPがあればセルラーにフェイルオーバーする。

  • Linuxネットワークスタックとドライバのサポート・デバッグ・修正を仕事にしているが、これほど採用が少ないのは驚き。
    SCTPのように通常のTCPを置き換えようとしたものと同じく、MPTCPも一部のアプリケーション開発者が使い続けるニッチ技術にとどまり、世の中の他の人々からは忘れられているように見える。

    • Apple SiriがMPTCPを使っているので、デバイス数を考えると、必ずしもニッチとだけは言いにくい。

  • MPTCPとQUICの構造的な違いを説明し、著者らが提案したMPQUICプロトコルも紹介している資料を見つけた。
    QUICは1本のUDPフロー上でアプリケーションストリームを多重化し、MPTCPは1本のストリームを複数のTCPサブフローに分割する。MPQUICは両者の特徴を組み合わせ、複数のUDPサブフロー上でアプリケーションストリームを多重化する。
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    これらのプロトコルが本番環境でどう比較されるのか、今はそこが気になる。両方使ったことがある人はいる？

    • MPQUICはまだIETFで議論中。前回のIETF会合でもさらに多くの変更が議論され、残念ながらそのため採用が遅れている。
      https://lwn.net/Articles/964377/
      両者は同じ目標を達成しようとしている。技術的には非常に似た動作を作れる。MPTCPはLinuxカーネルに実装されており、QUICはユーザー空間側にある。

  • Appleもサポートしており、Siriで使っている。
    https://developer.apple.com/documentation/foundation/urlsess...

    • 他のアプリでもかなり簡単に使える。標準機能に入っている。
      2011年に自分たちのVoIPアプリがかなり堅牢に動くのを見て驚いた :D

  • 中間機器のどれか1つでも対応していなければ、返ってくるSYN+ACKパケットのTCPオプションフィールドにMPTCPオプションがないというのは、かなり制限が大きいように聞こえる。
    中間機器に求められることは、MPTCPオプションをそのまま転送することだけなのか？

    • 仕様を確定する前に、MPTCPを有効にしても接続性が壊れないか多くのテストを行った。
      正しく通過するか、安全に単一経路TCPへフォールバックするようにした。
      一般に、中間機器が未知のオプションを変更せず通過させ、自分が見ているTCPシーケンス空間が連続していなければならないと強制しないのであれば、MPTCPはその機器を通過して動作できる。
      興味があれば関連論文が2本ある。
      [1] https://www.usenix.org/conference/nsdi12/technical-sessions/...
      [2] https://www.researchgate.net/publication/229002024_Is_it_sti...

  • セキュリティやプライバシー設定で役に立つ可能性がある。
    たとえば中国のGreat Firewallを考えると、トラフィックを複数のアップリンクチャネルに分割できる場合、ファイアウォールがそれを再構成して執行するのは難しくなるのではないか？

    • 未知のトラフィックなら、単に遮断するか、厳しく速度制限をかければよい。