要約

  • RFC 2357は信頼性マルチキャストの方式を定めた文書ではない。提案を実験として残す場合と、標準トラックで支持できる場合を分ける審査基準だった。
  • 一つのフローが世界規模の木を通り、無人端末の間で最後の受信者まで続き、ACK、NACK、状態通知や修復送信を爆発させ得ることが問題だった。
  • 仕様、実装、シミュレーション、試験、運用観測、RFCの地位は別々の証拠である。いずれも単独ではインターネット全体の安全を証明しない。

配布の節約は、応答の節約ではなかった

1998年の信頼性マルチキャストには分かりやすい用途があった。共同作業空間、ソフトウェア配布、大容量データ転送では、同じ内容を受信者ごとにユニキャストするより、分岐点で複製する方が合理的だった。

RFC 2357が数えたのは逆向きの流れである。

受信者が欠落を報告し、進捗を確認し、修復を求めれば、グループの大きさが制御トラフィックの大きさに変わる。一台の要求が広いグループへの再送を起こす設計なら、送信側で節約したコピー数以上の負荷を共有網に戻し得る。

文書はAllison Mankin、Allyn Romanow、Scott Bradner、Vern PaxsonとTSV Area Directorateによってまとめられ、1998年6月にInformationalとして公開された。インターネット標準ではなく、パケット形式も指定していない。対象は、Transport Areaの責任者が信頼性マルチキャストのInternet-DraftをRFCとして扱う際の手順だった。

懸念は四つ重なっていた。単一フローが大規模な世界的マルチキャスト木へ広がる。ファイル転送の受信者は無人のコンピューターで、人間が品質悪化を見て離脱するとは限らない。全受信者への完了まで続く処理には自然な時間上限がない。さらにACK、NACK、状態通知が複雑な帰還パターンを作る。

RFC 2357は「輻輳災害」や崩壊の可能性を述べた。それは特定の過去方式が実際に崩壊を起こしたという記録ではない。広い利用を促す地位を与える前に、危険を限定できる証拠を求める理由だった。

信頼性という語は、異なる契約を包んでいた

用途ごとに完了の意味が違った。全順序を必要とするものも、不要なものもある。送信者は一つとは限らない。データは単一の源にも複製源にも置かれる。小さな固定グループと、何万にも増える動的グループでは設計条件が異なる。対話用途は遅延を嫌い、ファイル配布は完全性を優先しやすい。時刻を守るため一部欠落を許す用途もある。

したがって一つの万能インターフェースを選べば済む話ではなかった。共通化すべきなのは、他者が被る可能性のある部分である。輻輳をどう検知し、負荷をどう下げ、帰還をどこで抑え、障害をどの範囲に閉じ込めるかは共有条件になる。順序や部分完了の選択は、共存を壊さない限り用途側に残せる。

この切り分けはLu HengのMinimum Initial Specificationと一致する。共通層は検証可能な相互運用条件を最小限に持つべきで、将来のあらゆる製品判断を一つの中央仕様に入れる必要はない。ただしローカルな完了目標を、他のトラフィックから資源を奪う権限に変えてはならない。

公開することと、標準として支持することを分けた

標準トラックを求める提案が基準を満たさなければ、Area Directorは支持を拒めた。それだけで標準トラック公開を止められた。一方、ExperimentalやInformationalの場合は、基準に適合しない旨のIESG注記を付けて公開するという道が残った。

これは研究の禁止ではない。未成熟な仕組みを記録し、実装し、反証可能にしながら、公開記録を成熟した共通規則と誤認させないための区別だった。技術基準を満たした提案でさえ、既定の地位はExperimentalとされた。

RFC 2357は、運用経験の少なかった動的ルーティング方式に実装と分析を要求したRFC 1264を先例として挙げた。機能が同じだからではない。失敗の費用が提案者の外まで届く仕組みでは、紙上の整合性より強い証拠が必要になるからである。

RFC 2026が定めたStandards Track、Experimental、Informationalの区別は、ここで安全性に関する具体的な意味を持った。RFCになったことは記録の存在を示すが、導入も、普遍的な安全も示さない。

審査は「故障がどこで止まるか」を問うた

候補には、主張に見合う分析、シミュレーションまたは試験が必要だった。グループと送信者が増えた場合、経路やメンバーが変わった場合、制御メッセージが失われた場合を説明しなければならない。輻輳の検出、送信量の削減、他トラフィックとの共存、障害の封じ込めも審査対象だった。

RFC 2001は、損失を受けて負荷を下げる当時のTCP輻輳制御の参照だった。ただしRFC 2357は、マルチキャストがTCPをそのまま模倣せよとは述べていない。問われたのは共存である。ある用途の「必ず終える」という目的が、競合フローの進行可能性を奪わないか。

安全性も付録ではなかった。再送要求は欠落の証拠になり得る一方、偽造や操作の入口にもなる。要求数が仕組み上制限されない場合、文書は強い暗号署名を求め、別の防御を採るなら非常に重い立証責任を課した。

署名だけでは足りない。署名は鍵との対応を示せても、現在のメンバー資格、要求できる範囲、適切な頻度、全体再送の妥当性までは証明しない。RFC 2357の本質は、これらを一つの「認証済み」に畳まないことにある。

文書はRFC 1301とRFC 1458について、輻輳への影響が十分理解される前に公開されたとして廃止方向を勧告した。両文書が実際の崩壊を起こしたと立証したわけではない。RFC番号が永続的な安全証明ではなく、後の知見で評価を変え得ることを示した。

試験結果には、試験条件を付けたままにする

Running-Code Primacyで証拠層を分けると明快になる。仕様は期待動作を定義する。実装は一つのコードの挙動を見せる。シミュレーションはモデルの中で答える。試験はトポロジー、負荷、受信者数、障害条件、計測方法に束縛される。運用はさらに版差と運用方針を持ち込む。

一台の受信完了は全員の完了ではない。小規模試験は世界規模の証明ではない。署名付きNACKは全体再送の権限ではない。Experimental RFCは利用統計ではない。標準トラックの文書も、普及や無故障を自動的には示さない。

審査者の権限にも境界がある。IETF公開物にどの主張を付けるかは決められるが、将来のネットワークを中央から動かすことはできない。実装、導入、許可、監視、撤去はそれぞれの実施主体に残る。

RFC 2357の歴史的価値は、方式を選ばなかった点にある。効率の裏側にある負担を提出資料へ戻し、共通の地位を求める者に、その負担が他者へ漏れないことを説明させた。

出典と限界

公開情報と審査条件はRFC 2357の記録およびRFC 2357本文による。公開地位の枠組みはRFC 2026、審査の先例はRFC 1264、当時のTCP参照はRFC 2001である。廃止方向が勧告された文書はRFC 1301とRFC 1458。証拠層の整理にはLu HengのRunning-Code Primacy、Minimum Initial Specification、Reality Layersを用いた。これらは現在の導入率、旧RFCが起こした特定障害、後続方式の普遍的安全性を証明しない。