要約

  • 無限マッピングで通常の TCP にフォールバックした接続は、その寿命の途中で MPTCP に戻れない。単にサブフローが一つしかない状態とは異なる。
  • MPTCP を再び使うには別の接続が必要になるが、新しい接続の成功や、アプリケーション処理を安全にやり直せることまでは保証されない。

障害対応の終了条件を「データが流れていること」に置くと、見落とす状態がある。MPTCP では通信を止めずに済んだ代わりに、その接続で複数の経路を使う能力が失われる場合がある。周囲のネットワークが回復しても、既存の接続は元に戻らない。

これは一般的な性能低下の話ではない。RFC 8684 の第 3.7 節が定める、無限マッピングを使った通常の TCP へのフォールバックである。この処理の後、同じ接続の途中で MPTCP に復帰してはならない。規則が対象とするのは接続であり、端末全体や利用者のアカウントが恒久的に MPTCP を使えなくなるわけではない。

運用上は、通信を継続させる判断と、複数経路を使う能力を回復させる判断が分離する。前者はすでに成功しているかもしれない。後者には別の接続が必要になり、それをいつ作るかは、進行中の仕事を理解しているアプリケーション側の問題でもある。

送信済みデータをいつ手放せるか

MPTCP のサブフローは、それぞれ TCP のシーケンス番号を持つ。接続全体には別のデータシーケンス番号がある。DSS は両者の対応を伝え、受信側が個別のサブフローに届いたデータを、一つの順序付きバイトストリームへ位置付けるために使われる。

受信確認も一種類ではない。通常の MPTCP では、送信側が保持しているデータを解放するには、接続レベルの確認に加え、そのデータを送ったすべてのサブフローでの確認が必要になる。あるサブフローから TCP の ACK が来ただけでは足りない。受信側が TCP セグメントを確認した後、接続レベルの処理を待たせていたデータをメモリー不足などで捨てる可能性があるためだ。

無限マッピングは、接続の残りに適用されるマッピングを、予約されたデータ長ゼロという値で示す。フォールバック後、送信側はサブフローの ACK だけで送信バッファーを解放し、受信側は MPTCP の Data ACK の送信をやめることが推奨される。以後の通信は通常の TCP として扱われる。

したがって、単にスケジューラーが一本の経路を選んでいるのではない。保持すべきデータを判断する規則そのものが変わる。RFC 8684 の第 3.3 節と第 3.7 節が示すのは、この転送上の境界である。いずれの ACK も、アプリケーションの業務処理が完了した証明にはならない。

サブフローを捨てる場合と、MPTCP を離れる場合

経路上の機器が TCP オプションを取り除いたり、ペイロードを変更したりすると、サブフローと接続全体のシーケンスの対応が壊れることがある。交渉によって有効になったチェックサムは関連する異常の検出に役立つ。ただし、暗号学的な認証ではなく、異常を起こした主体の悪意を立証するものでもない。

複数のサブフローがある場合、チェックサムの失敗に対して問題のあるサブフローを閉じ、別のサブフローでデータを再送できる。失敗したマッピングのデータは接続レベルで確認されない。この処理なら、残りのサブフローによって MPTCP を続けられる可能性がある。すべてのチェックサム異常が接続全体の TCP 化を意味するわけではない。

サブフローが一つの場合にも条件がある。先に閉じずに無限マッピングへ移るには、まだ確認されていない転送中のデータが連続していると分かっていなければならない。サブフロー数が一つであることだけでは、この条件を満たさない。正常に閉じなかった別のサブフローからの再送が混在している場合もある。

MP_FAIL は、失敗したマッピングの開始位置をデータシーケンス番号で示す。該当するフォールバックの交換では、逆方向も通常の TCP に戻る。未確認データが連続していない場合には、リセット後に別のサブフローを作り、直ちに無限マッピングを適用する処理も記述されている。しかし、この新しいサブフローは古い接続の一部である。MPTCP の能力を取り戻すための別接続ではない。

最初の接続交渉でオプションが失われる場合と、すでに使われているマッピングが壊れる場合も区別する必要がある。問題のサブフローを閉じるべき状況もあり、どのような損傷でも無条件に救済できる切り替えではない。チェックサムを交渉していなければ、ペイロード変更をこの目的で検出するために別の層の信号が必要になる。

「一本」の接続をひとまとめにしない

MPTCP のままサブフローが一つになっている接続には、将来サブフローを増やせる余地がある。一方、無限マッピングの後は一つのサブフローしか送信できず、ほかは終了し、同じ接続で MPTCP に復帰することは禁じられる。監視画面の件数が同じでも、許される次の状態は違う。

その違いをアプリケーションから観測できるかどうかにも、実装の確認が要る。RFC 6897は抽象的な API を論じ、接続前に MPTCP の使用を要求し、接続後に対応状況や確立済みサブフローのアドレスを照会する設計を示す。そこで使われるシンボル名が、現在の特定の OS にそのまま実装され、フォールバック後の状態を確実に通知するとは言えない。

同文書は、サブフローの一覧が時間とともに古くなる点も指摘する。従来型のアドレス照会は、最初のサブフローがすでに使われていなくても、そのアドレス情報を返す。ログに見慣れた相手のアドレスがあるからといって、現在の経路が確認できたことにはならない。高度なコールバックは付録で今後の検討として挙げられており、基本 API の保証ではない。

仕様の位置付けも重要だ。RFC 8684 の記録は、2020 年 3 月の Proposed Standard として旧版を置き換えたことを示す。検証済みの正誤情報は TCP Fast Open の例における早過ぎるデータ確認を修正しているが、第 3.7 節の復帰禁止は変更していない。RFC 6897 の記録は 2013 年 3 月の Informational 文書であり、正誤情報の照会では該当項目がなかった。これは設計文書からの分析であって、稼働中の機器群を測定した報告ではない。

次の接続にも成功の保証はない

同じ接続に戻れない以上、MPTCP を再び使うには別の接続が必要になる。これは規則から導かれる必要条件であり、次回の交渉が成功するという予測ではない。問題を起こした経路上の条件が残っていれば、同じ結果になる可能性がある。

残っている転送が短ければ、そのまま完了させてから接続を更新する判断もある。長時間続くセッションなら、アプリケーションの区切りに合わせた更新を検討する余地がある。しかし、古いソケットを閉じて新しいソケットを開くことは、結果が不明な要求を安全に繰り返せる証明にはならない。

Lu Heng の代理問題に関する議論は、決定権と結果の負担を対応させて考える視点を与える。BTW の目的についての文章は、主張の宣伝ではなく構造の記述を重視する。ここで記述すべきなのは、フォールバックが守った通信と、その後に残した能力回復の判断の両方である。