エグゼクティブサマリー

  • Olivier Bonaventure は、UCLouvain の教授であり工学研究所の学部長として、インターネットルーティング、トランスポートプロトコル、動作コード、オープン教育、商用展開を結びつけてきました。
  • 彼は Multipath TCP の主要な学術アーキテクトであり RFC 共著者ですが、そのアーキテクチャ、輻輳制御、セキュリティ、実装は、研究者とエンジニアの重なり合うグループから生まれました。
  • UCLouvain は、MPTCP を仕様から Linux コードへ、そして後に Apple、通信事業者、Tessares、アップストリームの Linux コミュニティが使用した展開実証へと移行させるのに貢献しました。
  • Bonaventure の持続的な貢献は、プロトコル展開の方法論にあります。すなわち、有用なインターフェースを維持し、動作システムで前提をテストし、失敗を修正し、持続可能な組織にメンテナンスを引き継ぐことです。

1 つの接続がネットワーク障害をどのように生き延びるか

スマートフォンは、Wi-Fi 接続が途絶えても、モバイル通信圏内にとどまることができます。ブロードバンド加入者は、低速な固定回線と利用可能なセルラー回線を同時に持つ場合があります。サーバーは、たとえ一つの経路が輻輳したり障害を起こしたりしても、複数のデータセンター経路を通じて同じ宛先に到達できます。従来の伝送制御プロトコル（Transmission Control Protocol、TCP）では、通常、1 組のアドレスとポートによって接続を識別します。その経路が失われると、たとえ別の経路が利用可能であっても、アプリケーションはセッションを失う可能性があります。

Multipath TCP（一般に MPTCP と略される）は、その矛盾を解消するために設計されました。MPTCP は、既存のアプリケーションが期待する信頼性の高い順序付きバイトストリームを維持しつつ、エンドポイントが複数の TCP サブフローをその下に作成できるようにします。これらの経路は、接続を存続させ、帯域を結合し、あるいはローカルポリシーに従ってトラフィックを移動させることができます。困難だったのは、2 つの経路の方が 1 つより良いという観察そのものではありませんでした。課題は、すべてのアプリケーション、サーバー、ファイアウォール、ネットワークアドレス変換器、ロードバランサーを一度に交換することなく、複数の経路を 1 つのアプリケーションサービスのように振る舞わせることでした。それゆえ、MPTCP は、プロトコル設計の問題であると同時に、展開の問題でもありました。

Olivier Bonaventure の経歴は、そのプロセスを理解する方法を提供します。彼は MPTCP を単独で発明したわけでも、すべての実装を書いたわけでも、それを展開した企業を支配したわけでもありません。彼は、共同設計されたプロトコルが、標準化作業からソフトウェア、計測、通信事業者製品、長期保守へと移行するパイプラインの構築を支援しました。

MPTCP は、単独の発明者ではなく、ネットワークによって構築された

単純化した説明では、Bonaventure を MPTCP の発明者とし、学術的なアイデアから商業利用へ一直線に結び付けるかもしれません。しかし、標準化と実装の記録はそのような話を支持しません。MPTCP は、UCLouvain、ユニバーシティ・カレッジ・ロンドン、ブカレスト工科大学、Cisco、Apple、インターネット技術標準化委員会（IETF）、そして後に Linux コミュニティの研究者やエンジニアから生まれました。

作業はいくつかの技術層に分かれていました。アーキテクチャを開発した参加者もいれば、ワイヤプロトコル、輻輳制御アルゴリズム、セキュリティ機構、アプリケーションインターフェースを設計した参加者もいます。カーネル開発者はそれらの文書を動作コードに翻訳しました。デバイス企業や通信事業者はその後、経路ポリシー、製品設計、サポートに関して独自の判断を下しました。

Bonaventure の貢献は、時間軸に沿って最もよく理解できます。彼は、実験的仕様書や標準化過程の仕様書、運用経験に関する作業、UCLouvain での研究と実装環境、チュートリアル、オープン教育資料、そして Tessares を通じた商業化ルートに登場しています。彼は、プロトコル設計、実装、計測、標準化の改訂、展開、制度的承継といった、しばしば分離されたままの各段階を結びつけるのに貢献しました。

これは、単独発明者の肩書よりもはるかに重要な役割です。プロトコルが、1 人の人物が優雅なアイデアを持ったからといって、インフラになることはめったにありません。それらがインフラとなるのは、複数の組織が、元の研究グループに恒久的に依存することなく、実装、テスト、運用、改訂、そして最終的には保守を行えるようになったときです。

展開可能性を軸に形成されたキャリア

Bonaventure は 1992 年にリエージュ大学で計算機科学の工学学位を取得しました。その後、アンドレ・ダンティーヌのネットワーキング研究グループでリサーチエンジニアとして働きながら博士号を取得しました。1999 年の博士論文では、非同期転送モード（ATM）が、最低保証帯域幅を提供しながら TCP/IP の下で動作する方法を検討しました。

このテーマは 1990 年代の大きな論争に属するものでした。ATM は設計された仮想回線とサービスクラスを提供したのに対し、インターネットスタックはパケット、エンドポイント制御、段階的採用を中心に発展していました。技術的な問題は、単に ATM が IP トラフィックを伝送できるかどうかではなく、既存のアプリケーション、プロトコル、運用慣行を捨てることなく、新しいネットワーク機能を導入できるかどうかでした。

この問いは Bonaventure のキャリアを通じて繰り返し現れます。MPTCP もまた、既存のアプリケーションインターフェースの下に新しい機能を配置します。ソフトウェア開発者に馴染みの TCP バイトストリームを置き換えるよう求めるのではなく、トランスポート層が利用可能な経路をどのように使うかを変更するのです。そのメカニズムは博士研究とは異なりますが、統合の問題は認識できるものです。

1992 年から 1997 年まで、Bonaventure はリエージュでリサーチエンジニアとして勤務しました。公開記録からは当時のすべての職務を再構築できませんが、その順序から、従来の大学教員としてのキャリアの前に実装とネットワーク実験があったことが分かります。彼のその後のグループは、論文とコード、チュートリアル、計測を組み合わせ続けました。1997 年から 1998 年までアルカテル・ベルに在籍しました。レビューした資料では正確な職位や特定の製品を確定できないため、この期間を飾り立てるべきではありません。それでも、一時的に通信企業の内部に身を置くことで、互換性、製品ライフサイクル、カスタマーサポートが実験室のプロトタイプとは異なる制約を課すことを経験しました。

Bonaventure は 1998 年に FUNDP（現在のナミュール大学）で助教授となり、2002 年に UCLouvain に移り、2006 年に教授、2011 年に正教授となりました。調査時点では、UCLouvain は彼を正教授兼ルーヴァン工学院長としていました。

UCLouvain での長い期間は、短期の研究プロジェクトではめったに得られないものを提供しました。継続性です。MPTCP は、大学院生の研究者、カーネル開発、実験、IETF 参加、通信事業者との関係、そして何年ものメンテナンスを必要としました。大学がプロトコルを所有していたわけではなく、Bonaventure がすべてのコンポーネントを書いたわけでもありませんが、研究グループは、これらの活動が相互に強化し合う制度的基盤を作り上げました。

ルーティング研究が移行設計を教えた

MPTCP が彼の最も目立つ関わりとなる以前、Bonaventure はルーティング、トラフィックエンジニアリング、コンバージェンスに取り組んでいました。これらのテーマは、ネットワークがトラフィックを運び続けながら変化しなければならないという根本的な運用問題に直面します。事業者は、ルーターが分散状態を保持し、隣接システムが独自の更新スケジュールに従っている間に、トポロジー、ポリシー、リンクウェイトを調整しなければならない場合があります。数学的に正しい宛先状態だけでは十分ではありません。移行は、ネットワークが落ち着く前にループ、パケットロス、一時的な輻輳を引き起こす可能性があります。

Bonaventure は、Open Shortest Path First（OSPF）ネットワークにおける無停止トポロジー再構成に関する研究の共著者であり、この研究は 2007 年の INFOCOM 最優秀論文賞を受賞しました。この研究は、再構成を単一の計算としてではなく、順序付けられた運用プロセスとして扱いました。つまり、フォワーディングの中断を減らしながら、どのようにネットワークを 1 つの有効な状態から別の有効な状態へ移行させるかを問うたのです。

MPTCP は、トランスポート層で同じ習慣を適用しています。1 つのアプリケーション接続は、サブフローが現れたり消えたり、異なるパフォーマンスを示したりしながらも継続しなければなりません。メカニズムは、エンドポイントが安定した経路セットで開始および終了することを前提とするのではなく、移行を考慮しなければなりません。彼の Border Gateway Protocol ピアリングリンク障害からのより迅速な復旧に関する研究は、さらに保守的な境界に取り組みました。ドメイン間ルーティングは、技術的状態と商業的ポリシー、セキュリティ上の前提を組み合わせています。どの事業者も、すべてのピアに同時にアップグレードを強制することはできません。

その後の xBGP と安全な BGP トランスポートに関する研究は、この探究を継続しました。目標は、クリーンブレークによってドメイン間ルーティングを置き換えることではなく、馴染みのある運用構造の中に制御された拡張ポイントやより強力なトランスポートを導入することでした。したがって MPTCP は、「設置済み基盤を交渉でなかったことにせずに、インフラをどのように変化させることができるか」という、より広範なキャリア上の問いの一つの顕著な例でした。

MPTCP はアプリケーションを保ちつつ、トランスポートを根本的に変更した

従来の TCP はアプリケーションに信頼性のある順序付けられたストリームを提供し、接続を一対のエンドポイントアドレスとポートに結びつけていました。このモデルは、ホストが通常 1 つの支配的なネットワークインターフェースに依存し、アドレスの変更がネットワークアイデンティティの変更を意味していた時代には効果的でした。モバイルデバイス、マルチホームサーバー、データセンターファブリックはその限界を露呈しました。アプリケーションは複数の独立した接続を開くことができましたが、その場合、経路選択、順序付け、失敗を自ら管理しなければなりませんでした。1 つの経路に紐付けられたセッションは、その経路が失敗すれば依然として消滅する可能性がありました。

MPTCP は、通常のソケット抽象化を維持しながら、トランスポート層に複数のアドレスとサブフローの知識を与えました。既存のアプリケーションは、エンドポイントがその下で複数の経路を使っていても、あたかも 1 つの接続であるかのように見え続けることができました。このメカニズムは 3 つの異なる結果をもたらし得ます。回復力は、1 つの経路が失敗したときにも論理接続を生かし続けます。集約は、複数の経路にデータを送ることによって利用可能なスループットを増やします。モビリティとポリシーは、無線状態、コスト、バッテリー使用、事業者ルール、アプリケーションニーズに応じて経路を追加または削除します。

これらの目標は常に一致するとは限りません。携帯電話は、継続的に使うとエネルギーやデータ許容量を消費するため、セルラーサービスをバックアップとして保持するかもしれません。ハイブリッドアクセスゲートウェイは、固定回線と LTE を同時に使うかもしれません。データセンターホストは、複数の類似した経路にトラフィックを分散させるかもしれません。MPTCP はメカニズムを提供しますが、経路マネージャー、スケジューラ、輻輳制御、エンドポイントポリシーがユーザーが受け取るサービスを決定します。

既存のインターネットとの互換性が中心的な制約となりました。ファイアウォール、ネットワークアドレス変換器、ロードバランサー、侵入検知システム、TCP オプティマイザは、通常の TCP に関する前提を蓄積してきました。それらは未知のオプションを削除したり、パケットを書き換えたり、接続内のすべてのバイトが 1 つの経路をたどることを期待したりする可能性があります。

そのため MPTCP は、TCP オプションと普通に見えるサブフローを使用しました。機能ネゴシエーションが失敗した場合、接続は従来の TCP として継続できます。これにより段階的な展開が可能になりましたが、オプション空間が制限され、ハンドシェイクが複雑になり、可観測性の問題も生じました。つまり、意図したマルチパスサービスが黙って消えてしまっていても、アプリケーションは動作し続ける可能性があるのです。

標準化の記録は単独発明者説を否定する

MPTCP のアーキテクチャと標準化文書では、集団的な著者性が目に見えています。アーキテクチャガイドラインを定めた RFC 6182 は、Alan Ford、Costin Raiciu、Mark Handley、Sébastien Barré、Janardhan Iyengar によって書かれました。実験的 MPTCP バージョン 0 仕様である RFC 6824 は、Ford、Raiciu、Handley、Bonaventure によって書かれました。後の標準化トラック仕様である RFC 8684 には、Christoph Paasch が加わりました。

他のコンポーネントには異なる主著者がいました。結合輻輳制御に関する RFC 6356 は Raiciu、Handley、Damon Wischik が、アプリケーションインターフェースの考慮事項は Michael Scharf と Ford が文書化し、Marcelo Bagnulo と後の貢献者がセキュリティ分析に参加しました。

この分担は偶然ではありませんでした。アーキテクチャは、アプリケーション透過性、回復力、リソースプーリング、段階的展開といった目標を記述しました。ワイヤ仕様は、オプション、鍵、サブフロー、シーケンスマッピング、失敗動作を定義しました。輻輳制御は、1 つの論理接続が複数の TCP サブフローを使う際の公平性に取り組みました。セキュリティ作業は、トークン、サブフローアタッチメント、攻撃者モデルを検討しました。実装はその後、これらの文書をカーネル状態とローカルな操作ポリシーに変換しました。

健全なアーキテクチャは健全なハンドシェイクを保証しません。公平な輻輳制御アルゴリズムでも、遅延が大きく異なる経路では性能が悪い場合があります。実装は RFC に従っていても、診断が難しい場合があります。Bonaventure の影響力は、これらの層が交わるところで最も強く、つまり実装と展開のエビデンスを用いて標準化プロセスを改善する点にありました。

RFC 6824 は 2013 年 1 月に実験的仕様として公開されました。MPTCP バージョン 0 を定義し、TCP オプション種別 30 を使用しました。「実験的」はカジュアルを意味しませんでした。深く展開されたプロトコルへの大規模な拡張は、安定したインフラとして扱われる前に、実際のソフトウェアとネットワークからのエビデンスを必要とすることを認識したものです。そのエビデンスは、研究用カーネル、ミドルボックステスト、データセンター実験、Apple の展開、通信事業者システムから得られました。コミュニティは、文書レビューだけでは発見できないハンドシェイク、セキュリティ、経路管理、運用上の問題を発見しました。

Bonaventure、Paasch、Gregory Detal が執筆した RFC 8041 は、その運用経験を標準化記録に取り入れました。データセンター、Wi-Fi とセルラーリンク、プロキシ、ミドルボックス干渉、輻輳制御、スケジューリング、キャプティブポータル、負荷分散サーバーファームをカバーしました。この文書は、展開された振る舞いを、プロトコルを変更し得るエビデンスとして扱いました。これは重要な制度的ステップです。仕様は、単に最初に公開されたからといって権威を持ち続けるわけではありません。稼働コードが前提に繰り返し反する場合、標準は存在するネットワークを考慮しなければなりません。

RFC 8684 は 2020 年 3 月に公開され、RFC 6824 を廃止して MPTCP バージョン 1 を標準化トラックに移行しました。MP_CAPABLE交換を改訂し、実装を通じて学んだ振る舞いを明確化しました。バージョン 1 はバージョン 0 とワイヤ互換性がありません。この断絶は移行作業を生み出しましたが、すべての実験的選択肢を保存すれば、それ自体のコストを伴ったでしょう。MPTCP の発展は、運用上のエビデンスが以前の設計を擁護しがたくするとき、明示的なバージョン境界が必要になり得ることを示しています。

1 つの接続、複数の普通の TCP サブフロー

アプリケーションにとって、MPTCP 接続は依然として 1 つの信頼できるバイトストリームとして見えます。その下では、各サブフローは独自のシーケンス番号、輻輳ウィンドウ、再送信、往復時間、失敗状態を持つ普通の TCP 接続です。MPTCP 層はそれらを調整し、アプリケーションに 1 つの順序付けられた接続を提示します。

最初のサブフローは通常の TCP の 3 ウェイハンドシェイクにMP_CAPABLEオプションを加えて開始されます。これは、両方のエンドポイントが MPTCP を理解することを示し、接続を識別・認証するために使われる鍵素材を交換します。どちらかのエンドポイントまたは介在するデバイスがこのオプションをサポートしない場合、セッションは通常の TCP として続行できます。

MPTCP 接続が確立されると、エンドポイントはMP_JOINを使って別のサブフローを作成できます。この加入交換は、接続を識別するトークンと、接続鍵から導出された HMAC ベースの機構を運びます。これにより、完全な鍵を開示することなく、かつ任意のアタッチメントを容易にすることなく、別の経路が参加できるようになります。プロトコルは、追加のサブフローをいつ作成すべきかを決定しません。その責任は経路マネージャーと展開ポリシーにあります。携帯電話は Wi-Fi が劣化したときにのみセルラーサービスを追加するかもしれません。ハイブリッドアクセスゲートウェイは、固定経路とモバイル経路をすぐに有効化するかもしれません。データセンターホストは複数のアドレスと経路を発見するかもしれません。

MPTCP はアドレスを通知・撤回し、経路をバックアップとしてマークできます。これらの機能はネットワークアドレス変換、プライバシー、サーバーファーム設計と相互作用します。ローカルアドレスがすべてのリモート経路から到達可能とは限らず、すべてのインターフェースを通知すると事業者が非公開にしたいトポロジーを露出する可能性があります。したがって経路管理は重要なポリシー境界となりました。初期の実装ではそのロジックの多くをカーネルに置いていました。後にアップストリーム Linux は netlink とユーザー空間制御を追加し、特権ソフトウェアがデバイスや事業者の要件に従ってサブフローを追加・削除できるようにしました。

トランスポートはまた、2 つのシーケンス空間を維持しなければなりません。各サブフローは通常の TCP シーケンス番号を持ち、論理接続はデータシーケンス番号空間を使用します。データシーケンスシグナルは、サブフローからのバイトを接続全体のストリームにマッピングし、その上位層でデータを確認応答します。

したがって、最初に Wi-Fi で送信されたバイトは、アプリケーションが見る順序を変えることなく、セルラー経由で再送信できます。受信側は、損失と遅延を区別し、異なる遅延の経路を通って到着するデータを並べ替え、1 つの遅い経路が過剰なバッファリングを引き起こさないようにしなければなりません。スケジューラは、新しいデータと再送信をどこに送るかを選択します。最低往復時間スケジューラは類似経路での遅延を減らすことができますが、より遅い容量を未使用のままにする可能性があります。冗長スケジューラは、回復力のために同じデータを複数の経路に送信できますが、帯域をより多く消費します。バックアップスケジューラは、Wi-Fi が失敗するまでセルラーサービスを温存できます。

これらの決定はサービスに依存します。音声アシスタントは継続性と短い中断を重視します。バルク転送は結合スループットを重視するかもしれません。地方のハイブリッドアクセス製品は、利用可能なすべての固定・モバイル容量を使おうとするかもしれません。スケジューラは、一般的なプロトコルメカニズムが特定の製品ポリシーになる場所です。輻輳制御は別の制約を作り出します。各サブフローが完全に独立した TCP 接続として振る舞うなら、1 つの MPTCP セッションが共通ボトルネックの不公平なシェアを取る可能性があります。結合輻輳制御は、リソースをプールしつつ、過度の攻撃性を避け、トラフィックをより輻輳していない経路に移動させるように設計されました。

ネットワークトポロジーは部分的に隠されたままかもしれません。明らかに別々の 2 つの経路がボトルネック、無線リソース、プロバイダーリンクを共有する可能性があります。どの輻輳制御アルゴリズムもすべての商業的・物理的依存関係を推測することはできないため、事業者には依然として計測とローカルポリシーが必要です。

接続のクローズも階層化されています。TCP のFINは、MPTCP 接続が他の場所で継続している間に 1 つのサブフローを閉じることができます。接続レベルのDATA_FINは信頼性のあるストリームを閉じます。リセットと高速クローズ機構は突然の失敗を処理します。Linux は最初のアップストリームマージ後もリセット、アカウンティング、ソケットオプション、診断動作を追加し続け、実装の完成度が 1 回のリリースではなく数年かけて現れたことを示しました。

既存のインターネットがプロトコルを形作った

MPTCP エンドポイントは中立なパイプを通じて通信するわけではありません。ネットワークアドレス変換器はアドレスとポートを書き換えます。ファイアウォールはハンドシェイク状態を検査します。ロードバランサーはフローを分散します。TCP オプティマイザはセグメンテーションやペイロードを変更し、監視システムは 1 つの経路上でストリーム全体を観測することを期待するかもしれません。これらのデバイスは、未知の TCP オプションを通過させたり、除去したり、変更したり、拒否したりする可能性があります。クリーンな実験室エンドポイント間でのみ機能するプロトコルは、公衆インターネットではほとんど価値がありません。

2012 年の NSDI 論文「How Hard Can It Be?」は、この問題を研究の中心に据えました。Costin Raiciu、Christoph Paasch、Sébastien Barré、Alan Ford、Michio Honda、Fabien Duchêne、Olivier Bonaventure、Mark Handley は、ミドルボックスの振る舞い、不均等経路、並べ替え、バッファ圧力、現実的なサーバーと OS の制約を検討しました。

このタイトルは、図からシステムへの移行を捉えています。データを経路に分割して再構成することは、高レベルでは単純に見えます。展開されたインターネットは、それを互換性、シーケンスマッピング、スケジューリング、失敗を含む問題に変えます。この論文は、他の研究者が使用できる稼働コードとエビデンスを提供したため、USENIX NSDI Community Award を受賞しました。

フォールバックはその展開可能性に不可欠でした。MP_CAPABLEが除去またはブロックされた場合、接続は通常の TCP として続行できます。ユーザーはサービスを維持しやすくなりますが、事業者は回復力や集約が失われたことを知らないかもしれません。したがって、本番システムには、ネゴシエーション成功、フォールバック理由、サブフロー作成、経路失敗、スケジューリングに関するカウンターが必要です。停止がないことは MPTCP がアクティブであることを証明しません。プロバイダーは、その主張が依存するメカニズムを観測せずに、信頼できるマルチパスサービスをサポートすることはできません。

MPTCP はまた、サブフローのアタッチメントを認証します。鍵を交換し、トークンを導出し、別の経路が接続に参加する際に HMAC ベースのチェックを使用します。セキュリティ分析では、トークン推測、サービス拒否、アドレス通知、サブフローハイジャック、経路上または経路外の攻撃者が検討されてきました。これはアプリケーションの機密性を提供しません。Transport Layer Security または別のアプリケーションセキュリティ層が、コンテンツを保護する責任を負います。MPTCP の認証はマルチパス接続の構造を保護するものであり、その上の暗号化を置き換えるものではありません。

稼働コードが研究をインフラに変えた

UCLouvain の歴史的なプロジェクト説明では、2009 年頃に Sébastien Barré が、部分的に以前の shim6 関連の作業を基に、主要な Linux MPTCP 実装系統を開始したとされています。Christoph Paasch、Gregory Detal、Fabien Duchêne、その他多くの人々がそのツリーを拡張しました。それは実験、チュートリアル、初期の展開を支えました。

Bonaventure の役割は、研究リーダー、プロトコル共同設計者、指導教員、共著者、時折のコード貢献者というものでした。これは、彼が主要なカーネルプログラマでなくとも実質的なものです。研究リーダーは、人材を集め、問いを定め、協力を確保し、コードを共有実験プラットフォームとして利用可能にすることで、インフラを構築できます。

2019 年の ACM SIGCOMM Networking Systems Award は、Linux MPTCP 実装を評価し、Paasch、Barré、Detal を主要開発者としつつ、より広範な貢献者コミュニティを認めました。彼らの認知度が重要なのは、このプロジェクトが複数の種類の専門知識に依存していたからです。制度構築はエンジニアリングの功績を置き換えるものではなく、エンジニアが持続的な仕事を生み出せる条件を作り出します。

UCLouvain ツリーは、メインライン Linux よりも速く、スケジューラ、経路マネージャー、ソケットオプション、実験を追加できました。その柔軟性は研究者や初期採用者にとって有用でした。また、メンテナンスの負担も生み出しました。ユーザーはパッチを運び、カーネルの変更に追随し、セキュリティ修正を統合し、標準的なディストリビューションのライフサイクルの外で動作をサポートしなければなりませんでした。

研究用フォークはメカニズムが機能することを証明できます。保守されるサブシステムは、レビュー、互換性、テスト、サポートに関して異なる期待に応えなければなりません。アップストリームへの統合は、より大きなリポジトリにコードをコピーするだけのことではありません。それは別の組織に責任を移転することであり、多くの場合、そのコミュニティが持続できるものに合わせてインターフェースを再設計する必要があります。

初期の MPTCP サポートは、2020 年 3 月に Linux 5.6 のメインラインに加わりました。最初のマージは、接続確立、プロトコルオプション、名前空間の制御、セルフテストを提供しました。これはまだ複数のサブフローを同時に作成・使用するものではなかったため、Linux 5.6 を完全なマルチパス実装と表現するのはマイルストーンを誇張することになります。

限定的な最初のマージは、アップストリームガバナンスを反映していました。小さなステップはレビューリスクを減らし、完全なマルチパス操作に取り組む前に、サブシステムがテストとインターフェースを確立することを可能にしました。このリリースは、カーネルが「MPTCP をサポートする」という記述に条件が必要な理由も示しました。バージョン、経路管理、スケジューラの動作、診断機能が、そのサポートの意味を決定づけます。

その後の作業で、netlink 経路マネージャー、複数のサブフローの同時使用、接続レベルの順不同処理、ユーザー空間制御が追加されました。Matthieu Baerts、Paolo Abeni、Mat Martineau、その他のアップストリーム貢献者がこのフェーズの中心となりました。Tessares のエンジニアも参加しましたが、サブシステムは単に UCLouvain ツリーをそのまま移動したのではありません。この進行は制度化を実際に示しています。プロトコルネゴシエーションが最初に来ました。ポリシーインターフェースと実際のマルチパス使用がそれに続きました。リセット処理、診断、セルフテストは発展し続けました。メインライン Linux が共通のメンテナンス層となり、デバイスメーカーや事業者は経路ポリシーに対するローカルな制御を保持しました。

現在の Linux の記録では、MPTCP メンテナとして Matthieu Baerts と Mat Martineau が挙げられています。Bonaventure は現在の Linux MPTCP メンテナではありません。歴史的影響力が現在のマージ権限やセキュリティ責任を生み出すわけではありません。この承継は彼の影響力の主張を強化します。プロトコルは、元の学術的リーダーがすべてのパッチを受け入れたり、すべてのリグレッションを診断したりする必要なしに継続できるとき、インフラとなります。残る問いは、後のコミュニティがサブシステムを維持するのに十分なメンテナ、テスト、資金を持っているかどうかです。

展開は製品ポリシーと事業者の経済性に依存した

Apple は MPTCP を目に見える消費者インフラに変えました。そのサポート資料では、iPhone や iPad が Wi-Fi を主接続として、セルラーサービスをバックアップとして使用できると説明しています。Siri が最もよく知られた例です。Wi-Fi が利用不可または応答しなくなった場合、アプリケーションはまったく新しい論理セッションを作成せずに、セルラー経由で継続できます。

ネットワーク管理者には、TCP オプション 30 を許可し、そのオプションが通過できない場合は通常の TCP フォールバックを期待するよう助言されました。この展開は、MPTCP が消費者規模で回復力を提供できることを示しました。それはすべての iOS アプリケーションが Wi-Fi とセルラーの帯域を結合したことを意味するわけではありません。Apple は自社の実装を書き、サーバーサイドを運用し、製品ポリシーを選択しました。Bonaventure は上流の研究と標準化作業に影響を与えましたが、Apple の内部ネットワークスタックを書いたわけではありません。

UCLouvain の研究者は後に Apple のハンドオーバー動作を調査し、iOS 11 でより広範なアプリケーションアクセスを報告しました。移行は文字通り瞬間的ではなく、エンドポイントポリシーが依然として結果に影響しました。接続は経路変更を生き延びながらも、遅延、並べ替え、スループット低下を経験する可能性があります。

物理ネットワークは抽象化の背後に消え去るわけではありません。モバイルの継続性は依然として無線状態、ネットワークアドレス変換、サーバーサポート、経路検証、アプリケーションタイミングに依存します。データセンターは別の目的でマルチパスを使います。サーバー間に複数の物理的または等コスト経路が存在する可能性があります。MPTCP はその多様性をトランスポート層で露出させ、アプリケーションが別々のソケットを管理する必要なしに、利用効率と回復力を改善できる可能性があります。

環境は携帯電話とは異なります。データセンター経路は名目上のコストが類似している場合がありますが、隠れたボトルネックを共有している可能性があります。サブフローが多すぎると不公平を生んだり、スイッチテーブルに負荷をかけたりする可能性があります。スケジューリングと輻輳制御はファブリック設計に適合しなければなりません。同じ MPTCP メカニズムが異なるサービスをサポートするのは、共通プロトコルがすべてのローカルな決定を規定しないからです。

ほとんどの公衆インターネットサーバーは MPTCP を有効化しなかったため、プロキシやトランスポートコンバータの使用が促されました。事業者は、顧客デバイスまたはゲートウェイと事業者管理のアンカー間で MPTCP を実行し、その後通常の TCP で公衆サーバーに続けることができました。これにより、すべてのウェブサイトを変更せずに展開できましたが、また、ステートフルな仲介者をサービス内に置くことになりました。プロキシはトランスポート状態を終端し、トラフィックを集中させ、運用上の依存関係となります。

Bonaventure と共同研究者が編集または共著した RFC 8803 は、TCP 拡張の展開を支援することを意図したゼロラウンドトリップトランスポートコンバータを定義しました。この設計は、普遍的なエンドツーエンドサポートを待つよりも仲介者の方が現実的かもしれないことを受け入れました。

アンカーの所有権、場所、障害ドメインはその後、製品の一部となりました。中央プロキシは管理を簡素化する一方で、障害の爆発範囲を拡大する可能性があります。分散アンカーは経路長を減らしますが、状態、ソフトウェアインスタンス、運用オブジェクトを増やします。容量計画は、固定およびモバイルトラフィック、接続状態、コンバータによって処理されるフェイルオーバー動作をカバーしなければなりません。

モバイルデバイスは別の制約を加えます。経路には金銭的およびエネルギーのコストが伴います。セルラー無線をアクティブに保つことはバッテリー電力を消費し、従量制ネットワーク上のトラフィックはユーザーまたは事業者にコストをかけます。Wi-Fi は高速だが不安定で、セルラーは信頼できるが高価かもしれません。これは、Apple の文書化された使用が恒久的な集約ではなくバックアップを強調した理由を説明するのに役立ちます。プロトコルはトラフィックを複数のネットワークにわたって運ぶことができますが、ユーザーが支払う意欲や許容できるバッテリーのトレードオフを決定することはできません。

Tessares が MPTCP を商業の境界を越えて運んだ

ハイブリッドアクセスは、DSL などの固定回線と LTE などのモバイル接続を組み合わせました。固定回線は安定した基盤を提供し、セルラー容量は速度や継続性を追加できます。このモデルは、長い銅線ループを光ファイバーで置き換えるのに時間がかかるか、多大な資本を必要とする地域で特に魅力的でした。典型的な展開では、MPTCP 対応ソフトウェアを顧客ゲートウェイと事業者管理の集約ポイントに配置しました。事業者は両方のアクセスネットワークを管理し、スケジューラを選択し、カスタマーサポートを定義できました。

このサービスはすべてのアプリケーションを高速化するわけではありませんでした。主に TCP トラフィック、ゲートウェイ統合、プロキシ容量、VPN、UDP、その他のプロトコルの扱いに依存しました。したがって、商用製品は RFC 以上のものでした。ソフトウェア、顧客宅内機器、無線リソース、監視、運用サポートが含まれていました。

投資家発表によると、Tessares は 2015 年 3 月に Olivier Bonaventure、Gregory Detal、Sébastien Barré、Denis Périquet、Sopartec によって設立された UCLouvain のスピンオフです。このグループは、学術および標準化の作業、実装経験、ビジネスリーダーシップ、大学の技術移転を組み合わせました。

仕様がゲートウェイ、統合、販売、サポート、そして展開されたシステムに対する責任なしに通信事業者製品になることはできませんでした。したがって、Bonaventure は共同創業者と記述されるべきであり、自動的に同社の現在の最高経営責任者、支配株主、日常的な運営者とはされません。公開された事業者発表では Denis Périquet が最高経営責任者と特定され、創業者の所有権や現在の経営責任は提供された記録では未公開のままです。

Proximus が最初の名前のある事業者のエビデンスを提供しました。これは、DSL と 4G/LTE を組み合わせたフラーヌ＝レ＝ザンヴァンでの 9 か月間のパイロットを説明し、地方の顧客を対象としていました。同社は高い満足度と、一部の参加者で最大 20 Mbps の速度向上を報告し、このシステムが実際のユーザーによる広範なテストと全国展開の可能性に適格であると述べました。これらは参加事業者による主張であり、独立したパフォーマンス監査ではありませんでした。それでも、このパイロットは実験室のベンチマーク以上のものを証明しました。Proximus は顧客環境にシステムを設置し、2 つのアクセスネットワークを調整し、結果として得られるサービスがサポート可能かどうかをテストしました。

2018 年の発表では、Proximus、VIVES II、SRIW が参加する 300 万ユーロの資金調達ラウンドが報告されました。それによると、Proximus、KPN、Telia が顧客であり、ベルギー、オランダ、リトアニアの約 15,000 世帯が Tessares テクノロジーの恩恵を受けています。2021 年の発表では、欧州イノベーション会議基金と Sagemcom が主導し、既存投資家が参加する 350 万ユーロのラウンドが報告されました。これらの数字は、その時点での資金調達と顧客関係を裏付けています。現在の収益、収益性、評価額、顧客維持率、現在の導入基数については提供していません。

BT は 2022 年に中小企業向けに Hybrid Speed Boost を発表し、この製品が Tessares の MPTCP テクノロジーを使用していると述べました。同社は銅線ブロードバンドと EE の 4G ネットワークの組み合わせを説明し、平均ダウンロード改善を報告しました。サポート文書はまた、制限を異例なほど明確にしました。このブーストは TCP ウェブトラフィックに適用され、典型的な UDP ゲーミングトラフィックを加速しませんでした。VPN の動作も利益を制限する可能性がありました。2 つのアクセスリンクは、すべてのパケットに対して 1 つの普遍的なパイプにはなりませんでした。

Wavenet と Digital Wallonia の公開資料は後に、Wavenet が 2024 年以降 Tessares のハイブリッドアクセスソリューションを保守またはサポートしており、ヨーロッパの大手通信事業者が使用する MPTCP システムをサービスしていると述べました。Tessares は調査時点で活動中のベルギーの法人としてリストされていました。

このエビデンスは、保守とサポートの移行を裏付けています。Wavenet が Tessares を買収したこと、すべての知的財産が移動したこと、Tessares が取引を停止したことを立証するものではありません。インフラはしばしば公開された立ち上げサイクルよりも長生きするため、この区別は重要です。導入済みのシステムは、スタートアップの可視性が低下してもエンジニアを必要とし続けます。

ハイブリッドアクセスはまた、光ファイバーの恒久的な代替品というよりも経済的な橋渡しでした。銅線の性能が低く、モバイル容量が利用可能で、光ファイバー建設に時間がかかる場合に最も説得力がありました。モバイル周波数とバックホールには依然としてコストがかかり、ゲートウェイは設置・サポートされなければなりませんでした。より多くの場所に光ファイバーが到達するにつれて、DSL と LTE を組み合わせる必要性は弱まる可能性がありました。Tessares は、物理的なアクセスネットワークが再構築される前に、ソフトウェアと事業者管理のアンカーがどのようにサービスを改善できるかを示しました。アクセス投資の長期的な経済性を排除したわけではありません。

その手法は MPTCP を超えて続いた

Bonaventure の教育に関する仕事は、同じアプローチを 1 つのプロトコルを超えて広げました。彼は『Computer Networking: Principles, Protocols and Practice』を執筆し、2011 年に初版を発表し、その後改訂されました。この書籍はオープンライセンスで提供され、教育者や学生が検査、改変、再配布できるようにしました。彼の公開記録には、2012 年の Saylor Foundation によるオープンテキストブックのための賞も記されています。この書籍は、ネットワーキングを、理想化された層のセットとしてではなく、プロトコル、コード、実際の振る舞いを通じて読者が検証できるものとして扱いました。オープンな出版はまた、システムが変化するにつれて資料が変化することを可能にしました。

Bonaventure は 2010 年から 2016 年まで ACM SIGCOMM の教育ディレクターを務め、後に編集や学術リーダーシップの職に就きました。彼のグループは実装資料、チュートリアル、仮想環境、実験を公開しました。2020 年の SIGCOMM チュートリアルは、マルチパストランスポートに関する実践的な作業を継続しました。

再現性はプロトコル生産の一部でした。学生やエンジニアはコードを実行し、パケットを検査し、クリーンなモデルとミドルボックスに制約された経路の振る舞いを比較できました。その環境で訓練された人々は、後に Apple、Tessares、アップストリーム Linux、その他のネットワーキング組織に専門知識をもたらしました。

彼のその後の研究は、1 つのマルチパスプロトコルからよりプログラマブルなトランスポートシステムへと移行しました。QUIC は UDP 上で動作し、トランスポート動作の多くをユーザー空間で実装し、暗号化を TLS を通じて統合しています。これは、MPTCP の TCP オプション戦略とは異なる、硬直化したカーネルやミドルボックスの前提を回避する経路を提供します。

Bonaventure と共同研究者は、プラグイン可能な QUIC、Multipath QUIC、関連するトランスポート変換の研究に取り組みました。これは MPTCP を放棄したことを意味しません。それは問いを拡大したのです。すなわち、相互運用性とセキュリティを維持しながら、トランスポートの振る舞いはどのようにすればより速く進化できるのか。ユーザー空間での展開は更新サイクルを短縮できますが、輻輳、ネットワークポリシー、実装リスクを取り除くわけではありません。同じ規律が引き続き必要です。前提を公開し、テストし、保守経路を設計することです。

拡張可能な Linux トランスポートスタックと eBPF 対応の経路認識 TCP に関する研究は、将来のすべてのメカニズムのために固定されたカーネルインターフェースを追加することなく、トランスポートの振る舞いをどのように変更できるかを探求しました。制約付き実行環境とローカルにインストールされたロジックは、共通層が安全性と相互運用性の境界を定義する一方で、実験をサポートできます。

プログラマビリティは独自のリスクを生み出します。異なるローカルアルゴリズムは比較が困難な振る舞いを生む可能性があり、拡張メカニズムは新たなセキュリティ局面を作り出す可能性があります。将来の決定は、共有システムが依然として検証、可観測性、安全でないコードを除去する方法を提供する場合にのみ局所化できます。

xBGP プロジェクトは同様の考え方をルーティングに適用しました。eBPF と検証済みインターフェースを通じて BGP 実装を拡張するためのベンダーニュートラルなメカニズムを提案し、FRRouting や BIRD などのオープンルーティングスタックとの連携を含みました。他の研究では、馴染みのある TCP 指向の運用モデルを維持しながら、BGP のための安全なトランスポートを検討しました。

これらのプロジェクトは研究およびドラフト段階の作業であり、普遍的な展開のエビデンスではありません。その関連性は、提案された変化への道筋にあります。事業者は、ベンダーや標準化プロセスが機能を追加するのを何年も待つことができます。制約付き拡張層は、実装が検証可能で相互運用可能であり続けるならば、その遅延を短縮できる可能性があります。

最近の UCLouvain の出版物はまた、適応的な IPv4/IPv6 アドレスファミリー選択、スイッチドホーミング、Flexicast QUIC もカバーしています。Flexicast は、暗号化されたトランスポート上でマルチキャスト効率とユニキャストフォールバックを組み合わせようとするもので、スイッチドホーミングは、ポリシーとパフォーマンスに従ってシステムがアクセス経路の間でどのように変更するかを検討します。

これらのプロジェクトは異なる研究段階にありました。それらは、2025 年と 2026 年の Bonaventure の仕事が単なる MPTCP の回顧的な擁護ではなかったことを示しています。経路、プロトコルサポート、権限が異なる当事者の間で分割されている場合に、ネットワーク能力をどのように展開できるかを引き続き検討しています。

ルーヴァン工学院長としての彼の役割は、その制度構築の実績を拡張するものです。この役職は日付に依存するものであり、すべての研究プロジェクトに対する権限を与えるものではありません。しかし、彼の影響力がますますプログラム、学部構造、他の研究者が活動する環境を通じて作用していることを示しています。

MPTCP の限界がその真の成果を定義する

MPTCP は通常の TCP に取って代わったわけではなく、展開は不均一なままでした。バージョン 0 とバージョン 1 はワイヤ上で互換性がありません。多くのサーバーがこのプロトコルを有効にしていません。ミドルボックスはフォールバックを強制する可能性があります。遅延が大きく異なる経路はバッファリングを増加させ、セルラーと Wi-Fi の同時使用はエネルギーや従量制データを消費する可能性があります。

プロキシは段階的採用を可能にしますが、接続状態を集中させます。ハイブリッドアクセス製品は選択されたトラフィックのみを加速するかもしれません。カーネルは MPTCP サポートを含んでいても、アプリケーションがそれを使用していない可能性があり、エンドポイントは相手側が別のバージョンを期待しているときに 1 つのバージョンをネゴシエートするかもしれません。独立した研究は、インターネット上の MPTCP 対応システムを測定しようと試みてきました。そのような測定は、オプション応答や大まかな傾向を明らかにできますが、偽陽性、ミドルボックス干渉、有用なアプリケーションサービスをサポートせずにプローブに応答するエンドポイントに対して脆弱です。

オプション応答はアクティブな本番展開と同じではありません。採用主張は、スキャンと、名前の付いた製品文書、実装バージョン、運用トラフィックのエビデンスを組み合わせるべきです。専用の IETF MPTCP ワーキンググループは、チャーターされた一式の文書を完了した後、2020 年 3 月に活動を終了しました。プロトコルガバナンスは終わっていません。エラッタ、相互運用性の質問、拡張作業、メンテナンスは、TCP Maintenance and Minor Extensions ワーキンググループに移行し、そのスコープには MPTCP が含まれています。

この移行は成熟の一部です。集中したグループは、アーキテクチャ、実験、標準化トラックの改訂を通じてプロトコルを導くことができます。常設のメンテナンス会場はその後、より広範な TCP システムとの相互作用を処理します。長期的な権威は、元のグループをいつまでも組み立て続けることに依存しなくなります。

バージョン断絶はまた、事業者に隠れた既存ベースについて警告します。デバイス、プロキシ、アプリケーション、組み込みシステムは、何年もの間、異なる世代のままである可能性があります。通常の TCP フォールバックはサービスを維持しながら、マルチパス動作の喪失を隠すことができます。したがって事業者は、MPTCP が有効であるという単なるフラグではなく、プロトコルバージョンとポリシーのインベントリを必要とします。各エンドポイントがどの世代をサポートしているか、プロキシがどのように影響を受けるか、フォールバックが顧客への約束を変更するかどうかを知らなければなりません。

公開記録にも限界があります。それは Bonaventure の学術的役割、RFC の著者、研究リーダーシップ、オープンテキストブック、Tessares の共同創業、現在の研究を裏付けています。信頼できる生年月日、個人資産、報酬、創業者の株式、Tessares の完全な資本テーブル、会社の現在の財務状況は確立されていません。また、Apple の実装に対する彼の個人的な貢献割合や、通信事業者の商業的成果に対する割合を定量化することもできません。これらのギャップは開かれたままであるべきです。チームの成果を 1 人の人物に帰属させることなくても、技術的および制度的記録は十分に実質的です。

彼のレガシーはパイプラインである

Bonaventure は MPTCP を単独で発明したわけではありません。彼はそのアーキテクチャ文書、輻輳制御 RFC、Apple の実装、現在のメインライン Linux サブシステムを書いたわけではありません。彼をエビデンスなしに Tessares の現在の最高経営責任者と描写すべきではありません。

彼の貢献は、それらの主張が示唆するよりも永続的です。彼は実験的仕様書と標準化トラック仕様書を共著し、重要なソフトウェアと展開研究を生み出したグループを率い、運用エビデンスを標準化プロセスにもたらすのを助け、プロトコルを通信製品に持ち込んだ会社を共同設立し、後のエンジニアを訓練するのに役立つ教育リソースを構築しました。そのパターンは、QUIC、eBPF 対応トランスポート、BGP 拡張メカニズムに関する彼の仕事で続きました。各プロジェクトは、新しいネットワークの振る舞いが、既存のアプリケーション、機器、インセンティブ、制度的境界をどのように生き延びられるかを問うていました。

BTW が Bonaventure を追跡するのは、彼のキャリアがプロトコルインフラが実際にどのように作られるかを示しているからです。RFC は 1 つの段階にすぎません。コードは相互運用しなければならず、失敗は測定されなければならず、事業者はそれを展開する商業的または運用上の理由を見つけなければならず、メンテナは元の研究者から責任を引き継がなければなりません。

MPTCP の中心的なメカニズムは、そのより広範な教訓の有用な表現です。1 つのアプリケーション接続は、どの経路がアクティブか、どれが予備であり、どれを放棄すべきかをローカル実装が決定する間、存続できます。Bonaventure は、そのアイデアが携帯電話、ブロードバンドサービス、Linux カーネルに入り込み、その後彼に依存せずに続くのに十分な周辺の連鎖を構築するのを助けました。