要約

  • Multipath TCP はアプリケーションに一つの信頼できる順序付きバイト列を提供しながら、一つ以上の通常の TCP サブフローで運べるようにする。
  • MP_CAPABLE が接続を交渉し、MP_JOIN が追加サブフローを認証し、接続全体のデータ番号によって障害後に別経路で同じデータを再送できる。
  • インターフェースが二つあっても耐障害性の証明にはならない。経路は同じボトルネックを共有し得るうえ、中間装置がオプションを落とし、端点の方針が二本目を常用・予備・不使用のどれにするかを決める。

Wi-Fi が消えても、接続まで消す必要はない

アクセスの切り替えは、IP アドレスの変化に見える。一つが使えなくなり、別の一つが使えるようになる。しかしアプリケーションにとって重要なのはアドレスではない。相手との間ですでに積み上げた状態と、順序どおりに届くバイト列である。

RFC 8684 は接続と経路を分けている。一つの MPTCP 接続は一つのアプリケーションソケットに対応するが、その内部には複数のサブフローを持てる。各サブフローは自分の経路上では TCP として動く。接続層がその上で信頼性と順序を維持するため、一つのサブフローが終わっても、接続全体を終わらせる必要はない。

ただし可能性と保証は違う。両端が MPTCP を交渉し、少なくとも一つの使えるサブフローが残るか新設され、接続状態も維持されなければならない。規格は継続の仕組みを作るが、電波の届き方や物理経路の独立性、代替経路の品質まで保証しない。

経路を増やす前に参加を認める

最初のサブフローでは MP_CAPABLE を交換する。双方が MPTCP に対応していることを示し、この接続に使う鍵材料をやり取りする。相手が未対応か、途中の装置が必要なオプションを通さない場合は、通常の TCP に戻れる。

別アドレスが見つかっただけでは、追加サブフローは接続に入れない。新しいハンドシェイクに MP_JOIN を載せ、トークンで参加先を示し、ノンスと当初の鍵から作る HMAC で同じ端点同士だと確認する。それでもローカル方針は参加を拒否できる。二本目の経路は、まず認証と許可の対象である。

ADD_ADDR は新しいアドレスを知らせ、REMOVE_ADDR は撤回する。アドレス ID により、NAT がヘッダーを書き換えても信号を扱いやすい。しかし広告されたアドレスは候補にすぎず、到達性、独立性、料金、性能を証明しない。

ここに制御境界がある。ネットワークは到達性を提供し、実際の経路を左右する。端点は MPTCP の成立、サブフローの参加、利用方針を決める。従来型アプリケーションには普通のソケットしか見えず、経路や費用の選択が下層で進むこともある。

サブフローの上に接続全体の帳簿を置く

各サブフローは通常の TCP シーケンス番号を持つ。MPTCP は別に、接続全体を通す 64 ビットの Data Sequence Number を設ける。DSS がサブフロー上のバイト範囲を接続全体の空間に対応づけ、接続単位の受信進行も知らせる。

この二重構造が復旧を可能にする。一つのサブフローで届かなかった接続上のバイトを、別のサブフローに新しい対応づけをして再送できる。受信側アプリケーションは一つの信頼できる順序付きバイト列を受け取り続け、独立した二接続を統合しなくてよい。

一方、順序は制約にもなる。遅い経路に残った欠落が、速い経路ですでに届いた後続データの引き渡しを待たせることがある。パケットスケジューラー、別経路への再送、輻輳制御が、複数経路を能力にするか遅延にするかを決める。RFC 8041 が運用上の論点として扱う理由である。

予備回線にも値段と故障域がある

RFC 8684 ではサブフローを通常用または予備用にでき、MP_PRIO で優先度の変更を求められる。小さなフラグだが、背後には経済判断がある。セルラー回線は接続を救っても従量課金かもしれない。衛星は届いても遅い。二つの固定回線が同じ管路や上流に集まることもある。

RFC 6182 は、複数のアドレス対が必ずしも互いに独立した経路を作らないと明記する。目標はスループットと耐障害性を高め、TCP のサービスモデルを守り、共有ボトルネックで他の利用者を不当に圧迫しないことだ。特定ネットワークでの達成を示す測定値ではない。

したがって確認すべきはインターフェース数ではなく、交渉済み接続である。実際に成立したサブフロー、通常用と予備用の区別、異なる故障域、接続単位の ACK の進み方、他経路へ再送されたバイトを記録する必要がある。

フォールバックも観測すべき結果

中間装置は TCP オプションを削除し、アドレスやポートを書き換え、MPTCP と両立しない形でデータを変更することがある。RFC 8684 は安全な対処を定める。最初のサブフローなら通常の TCP に戻り、壊れた追加サブフローならリセットして外し、運用中に正しい対応情報を失った経路は故障として閉じる。

そのため、アプリケーションが動いているだけでは multipath の存在を証明できない。別サブフローで接続が生き残ったのか、MPTCP が最初から成立せず通常 TCP が動いただけなのかは、全く違う。接続を一経路より大きくしたなら、監視も一経路より広くしなければならない。

情報源