要約

  • RFC 3450 は、個々の欠落パケットを再送要求せず、十分な FEC 符号化シンボルを受け取った時点で各受信者が独立にオブジェクトを復元できるようにした。
  • 受信者から送信者への中核フィードバックを不要にしたため規模は得られたが、復元、完全性確認、完了報告、アプリ利用は別々の事実として残った。

点呼をしない信頼性

信頼性のあるマルチキャストが難しいのは、同じパケットを多人数へ送ることだけではない。損失のたびに要求が戻り、受信者が増えるたびに送信側の状態が増える設計では、規模そのものが破綻する。2002年12月の RFC 3450 は、LCT、複数レートの輻輳制御、前方誤り訂正を組み合わせて ALC を定義した。

想定された規模は、同時受信者が数百万人、オブジェクトが数百キロバイトから数百ギガバイトである。受信者は異なる時刻に参加し、自分の経路に応じてチャネルへ参加・離脱する。送信側は符号化シンボルを送り続け、受信側は復号可能な集合がそろえばオブジェクトを復元して離脱できた。

各欠落パケットの再送要求も、ALC 本体から送信者への受信報告も要らない。そのため送信側から見れば、受信者が一人でも百万人でも負荷や送出レートを変えずに済む。テキスト版、RFC Editor 記録、Datatracker、履歴、参照文献、後続の参照、正誤表は仕様の記録を示すが、実運用で何人に届いたかまでは証明しない。

同じパケット列は必要なかった

FEC は修復の単位を変えた。二つの受信者が別々のパケットを失っていても、各自が十分な有効シンボルを集めれば同じバイト列を復元できる。RFC 3452 は FEC ビルディングブロックを定め、RFC 3453 はコンパクトな無符号化方式とパリティ方式を説明した。

ただし自律復元には座標が要る。FEC Object Transmission Information が、どの方式とパラメータでシンボルを解釈するかを示す。一部はインバンド、一部はアウトオブバンドで渡せるが、RFC 3450 は取得手段を規定外に置いた。「十分」とは、シンボル数だけでなく、それらを読める正しい情報がそろうことだった。

参加前には Session Description も必須だった。輻輳制御方式、送信者アドレス、チャネル数とアドレス・ポート、TSI、複数オブジェクトの有無、拡張形式、認証情報などを含む。Web、告知プロトコル、メールなどで入手できたが、その配送経路は ALC の外側である。

識別子の効力はスコープ内だけ

送信元 IP アドレスと TSI の組がセッションを識別し、TOI はそのセッション内のオブジェクトを区別した。TOI は世界共通のコンテンツ ID ではない。同じオブジェクトが別セッションで別の TOI を持ち得る。

したがって、TSI と TOI のログは、あるパケットがどのプロトコル座標に属したかを示すにすぎない。オブジェクトの復元、完全性検査の合格、特定の法的受領者への到達、アプリによる使用は別途証明する必要がある。交通整理の番号を受領書へ読み替えてはならない。

終了フラグは証拠を閉じなかった

Close Session と Close Object は、送信終了が近いことを知らせた。しかし RFC 自身が、完全には信頼できない「ヒント」と位置づける。最後のフラグ付きパケットも失われ得るし、受信者は終了時点でまだシンボル不足かもしれない。

プッシュ型の例では、復元を終えた受信者が別の仕組みで成功を報告し、想定した全員の報告が来るまでアプリが送信を続けることもできた。だが受信者名簿、完了メッセージ、停止条件はアプリ側の責任であり、ALC はそれらを定義しなかった。

復元と信頼も同一ではない。偽造シンボルが大きなオブジェクトを汚染し、多数の受信者へ同時に影響する可能性がある。RFC はパケット認証と、検証可能なデジタル署名を用いたオブジェクト全体の完全性確認を推奨した。FEC はバイトを回復できるか、署名は回復したバイトが正しいかを問う。どちらも送信側へ「誰が受理したか」を返さない。

実験仕様から標準提案へ

RFC 2357 は信頼性マルチキャストに適切な輻輳制御を求め、証拠が成熟途上だった RFC 3450 は Experimental として出た。RFC 3048 がビルディングブロック構成を、RFC 3269 が執筆指針を、RFC 3451 が LCT を定めた。基礎のマルチキャストは RFC 1112 にさかのぼり、送信元特定型は RFC 4607 で標準化された。2010年には RFC 5775 が蓄積した経験を反映し、後方互換の Proposed Standard として RFC 3450 を廃止した。これは成熟の証拠であり、普遍的採用の証拠ではない。

Heng Lu の現実レイヤーに従えば、シンボル受信、復元、完全性検証、アプリ受理、完了報告の送信、送信側の記録は六つの台帳である。稼働コード優先は、主張を実際に観測した機構の範囲へ戻す。最小初期仕様という視点では、まず拡張可能な転送を定義し、必要な説明責任をアプリが明示的に追加する節度が見える。これは後世の編集上の解釈で、RFC 著者の内心を語るものではない。

RFC 3450 の教訓は両刃である。中核から確認応答を除いたから巨大な規模が可能になった。そして確認応答を除いた以上、誠実な送信者は全受信者の完了を知っているとは言えない。

出典