MP-TCP（マルチパス TCP）の原理

MP-TCP が解く問題：経路を束ねて切らさず使い切る

スマートフォンは Wi-Fi とセルラーという2つの経路を同時に持ちます。通常の TCP は1本の経路（送信元 IP・宛先 IP・ポートの組）に縛られ、Wi-Fi が切れれば接続も切れます。MP-TCP（Multipath TCP、RFC 8684）は、1つの論理コネクションを複数の経路に分散させ、片方が落ちても接続を維持し、両方を足し合わせて帯域を増やす ことを狙います。鍵は、上位のアプリケーションには「ふつうのソケット」に見せたまま、内部で複数経路を多重化する点です。土台となる TCP の性質は TCPとUDPの違い を前提とします。

サブフローの構造とコネクション確立

MP-TCP の論理コネクションは、複数の サブフロー（subflow） から成ります。各サブフローはそれ自体が完結した通常の TCP コネクションで、独自の3ウェイハンドシェイク・独自のシーケンス番号・独自の輻輳ウィンドウを持ちます。これらを「同じ MP-TCP コネクションの一部」として束ねるのが、TCP オプションに埋め込まれた制御情報です。

最初のサブフローは SYN に MP_CAPABLE オプションを載せて開きます。このとき両端は乱数の 鍵（key） を交換し、その鍵から導出した トークン（token） が以後そのコネクションを識別します。2本目以降のサブフロー（別の IP やインターフェース経由）は SYN に MP_JOIN オプションを載せ、相手のトークンを示して「このコネクションへ合流する」と宣言します。

二層のシーケンス空間：なぜ分けるのか

MP-TCP の核心は シーケンス番号の二層構造 です。サブフローごとに独自の TCP シーケンス番号（subflow sequence number）が回り、その上に全サブフロー共通の データシーケンス番号（DSN: Data Sequence Number） が載ります。送信側はアプリのバイトストリームに DSN を振り、それを各サブフローへ割り当てて送出します。受信側は DSN を見てサブフローをまたいだ全体の順序を復元します。

アプリのバイトストリーム（DSN 空間）
  ... 1000 1001 1002 1003 1004 1005 ...
        │    │    │    │    │    │
   ┌────┴────┴────┐  ┌─┴────┴────┴─┐
   ▼   subflow A   ▼  ▼  subflow B  ▼
 seqA: 5000 5001 5002  seqB: 8000 8001 8002
   （A 独自の TCP seq）   （B 独自の TCP seq）

両者を対応づけるのが DSS（Data Sequence Signal） オプションで、各セグメントについて「このサブフロー seq から始まる範囲が、DSN 空間のどこに対応するか」のマッピングを運びます。なぜわざわざ二層にするのか。理由は2つあります。第一に、サブフローは独立に再送・順序制御を行えるため、各経路をふつうの TCP として 動かせる（ミドルボックスから見て普通の TCP に見える）。第二に、ある経路が遅い・切れたとき、その DSN 範囲を 別のサブフローへ再注入（reinjection） して全体としての配送を止めないためです。順序保証とフロー制御の基礎は TCPの受信ウィンドウとフロー制御 と同じ枠組みですが、MP-TCP では受信ウィンドウが コネクション全体で1つ（DSN 空間に対して共有）である点が異なります。

結合輻輳制御：公平性をどう担保するか

各サブフローが独立に CUBIC のような輻輳制御を回すと、MP-TCP は1本のボトルネックを共有する他フローに対して 経路数ぶん不公平に帯域を奪って しまいます。これを防ぐのが 結合輻輳制御（coupled congestion control） です。代表的な LIA（Linked Increases Algorithm、RFC 6356）は、各サブフローのウィンドウ増加量を全サブフローのウィンドウを見て調整し、3つの目標を同時に満たします。

LIA は増加（Increase）だけを結合し、減少は各サブフローが従来どおりロス時に半減します。ACK 1つあたりのウィンドウ増加量を、概念的には次のように決めます。

# サブフロー r の増加量（ACK ごと、概念式）
#   w_r       : サブフロー r の輻輳ウィンドウ
#   rtt_r     : サブフロー r の RTT
#   合計や max は全サブフローにわたって取る
increase_r = min( alpha / w_total ,  1 / w_r )

#   alpha は「全体で単一 TCP 1本ぶん」になるよう動的に調整される係数
#   alpha = w_total * max(w_i / rtt_i^2) / (sum(w_i / rtt_i))^2

ポイントは min の左項です。混雑した（ロスが多くウィンドウが伸びない）経路では w_r が小さく単独なら積極的に増やしたくなりますが、alpha / w_total で全体ウィンドウに抑え込まれ、増加が控えめになります。逆に空いている経路では 1/w_r 側が選ばれにくくならない範囲でトラフィックが寄り、自然に 混雑の少ない経路へ負荷が移動 します。後継には RTT 不均衡に強い OLIA や、遅延を見る BALIA があります。単一経路の輻輳制御の系譜は TCP輻輳制御の系譜 を参照してください。

ミドルボックス互換性：なぜ TCP オプションに載せるのか

インターネット上には NAT・ファイアウォール・プロキシなどの ミドルボックス が無数にあり、知らない新プロトコルやシーケンス番号の書き換えを行うものがあります。MP-TCP は新しい IP プロトコル番号を作らず、すべての制御情報を既存 TCP セグメントの TCP オプション領域に埋め込む ことで、各サブフローを「ごく普通の TCP」に偽装します。これが互換性設計の中核です。

具体的な防御がいくつもあります。シーケンス番号を書き換えるミドルボックスがいても、サブフロー seq は普通の TCP として処理され、全体順序は別空間の DSN が保つので壊れません。ペイロードを分割・結合するミドルボックスに備え、DSS には データレベルのチェックサム を持たせ、マッピングの破壊を検知できます。万一、合流が許されない・オプションが剥がされる経路では、MP_JOIN の認証（鍵から導く HMAC）が失敗するか DSS が機能しないため、安全に通常 TCP へフォールバック します。

まとめ：束ねるための三つの発明

MP-TCP は「複数経路を1コネクションに束ねる」という一見単純な要求を、三つの設計で成立させています。サブフロー＋トークン で経路を論理的に1本へまとめ、二層シーケンス（DSN） で経路をまたいだ順序と冗長な再注入を可能にし、結合輻輳制御 で既存 TCP に対する公平性を保つ。そしてそれらをすべて TCP オプションに収めることで、書き換え好きなミドルボックスがあふれる現実のインターネットでも、アプリを一切変えずに動く——ここに MP-TCP の工学的な巧みさがあります。