要約

  • RFC 3208 の PGM は受信者ごとの ACK を使わず、欠落を検出した受信者の NAK を抑制・集約し、ルーターに修復が必要な下流インターフェースを記録させた。
  • NAK Confirmation が保証したのは、そのホップで負の要求が処理されたことだけだった。修復データの送信、到着、復元、未知の全メンバーの成功は別の事実である。

一対一の通信では、確認応答は会話を閉じる記号になりやすい。相手が受け取ったと分かれば、送り手は再送をやめられる。しかし、一つの送信元から多数の受信者へ同じデータを配るとき、全員に同じ返答を求めれば、確認そのものが障害になる。

Pragmatic General Multicast、PGM が避けようとしたのは ACK implosion だった。数千の受信者が各パケットに肯定応答すれば、データより多い制御トラフィックが送信元へ集中しかねない。規模を増やすほど成功報告がシステムを壊すという逆説である。

そこで PGM は、通常時の沈黙を設計した。送信元はシーケンス番号を持つ Original Data、ODATA を配る。受信者は自分が観測した並びから穴を見つけ、そのときだけ selective negative acknowledgement、NAK を発する。

これは ACK を NAK に置き換えただけではない。PGM にはグループメンバーシップのモデルがない。送信元は誰が加入し、誰が離脱し、現在何人が聞いているかを列挙しない。既知の受信者全員への確認配達や、複数送信元間の全順序を必要とする用途は契約の外に置かれた。

信頼性の表現も受信者中心になった。適用される transmit window の内側で、受信者は元データか修復データを受け取るか、回復不能な損失を検出できる。送信元が未知の集団について「全員成功」と宣言する仕組みではない。

受信者が欠落を見つけると、データが来た枝の最後の PGM network element に NAK をユニキャストする。そして、そのインターフェースへ送られる NAK Confirmation、NCF を聞くまで要求を繰り返す。

ネットワーク要素は NAK を受けると、下流へ NCF を出し、上流の次の PGM 隣接点へ NAK を転送する。上流側も同じ動作を行い、要求は最終的に送信元へ届く。NCF はホップごとの確認であり、ルーターが端から端まで運ぶ受領証ではない。

したがって、NCF の主張は狭い。この地点で NAK を受け付けた、ということだけである。欠けた ODATA は NCF に含まれない。送信元が対象シーケンスをまだ保持しているとも、修復担当が RDATA を送ったとも、受信者がそれを使えたとも述べない。

NAK を受けたネットワーク要素は repair state を作る。セッションと失われたシーケンスを手掛かりにし、どの下流インターフェースから要求が来たかを記録する。確認後に NAK 自体を捨てても、必要な枝は状態として残る。

Repair Data、RDATA が戻ると、ルーターは状態に登録されたインターフェースだけへ転送する。失っていない枝へ修復を再び洪水のように流さず、助けを求めた部分木だけを通す。対応する状態がなければ、RDATA は原則として破棄される。

ここでは「正しい修復パケットが存在すること」と「そのパケットに通行権があること」が分離している。送信元が適切な RDATA を発していても、逆方向の要求がある枝の状態を作れなければ、その枝には届かない。途中の NCF は、往復の経路が完成した証明にはならない。

Source Path Message、SPM は逆方向の手掛かりを作った。送信元はデータの間に SPM を送り、各 PGM 要素は上流アドレスを更新する。受信者とルーターは、元の配布経路を逆にたどって NAK をどこへ渡すかを学ぶ。

SPM は transmit window の境界も知らせる。後端より古いデータは修復対象として残っていない。受信者が穴に気付いたとき既にウィンドウ外なら、正しく届けられた NAK でも消えたコピーを作り直せない。損失を検出できることが、損失を回復できることと一致しない場面である。

修復の唯一の引き金が NAK である以上、要求経路には粘り強さが必要だった。最近 ODATA が流れていなくても、SPM は受信者に欠落の再確認を促す。受信者は NCF を待つタイマーと RDATA を待つタイマーを別に持つ。確認を聞いた後にも、修復を待つ仕事は残る。

同じ欠落を多数の受信者が検出したとき、全員がすぐ NAK を出せば負の応答でも implosion が起きる。各受信者はランダムな back-off を置き、その間に一致する NAK または NCF を聞けば、自分の送信を抑制する。他者の要求が自分の欠落も代表すると扱うためだ。

ルーター側でも集約が続く。既に同じセッションとシーケンスの repair state があれば、新しい要求元インターフェースを追加しつつ、上流へ重複 NAK を送らずに済む。多くの受信者が失っても、送信元には一つの NAK しか見えないことが望ましい動作だった。

この圧縮が拡張性を生み、同時に人数を消した。送信元が見る一件の NAK から、何人が抑制によって黙ったかは分からない。枝へ送った一件の NCF は個々の受信者を列挙しない。repair state の一つのインターフェースも、その先のホスト数や現在の参加状態を表さない。

RDATA の物理的な発信者が元の送信元である必要もなかった。Designated Local Repairer、DLR はパケットを保存し、近い場所から修復に応答できる。DLR の RDATA は元の Transport Session Identifier を保ち、正しいシーケンス空間に入る。セッションの連続性は、元の送信元がそのバイトを送ったという来歴証明ではない。

DLR の広告、選択、NAK のリダイレクトもそれぞれ別の段階である。利用可能という広告は、要求されたシーケンスを今も保持している証拠ではない。リダイレクトは到達や応答を保証せず、同じ TSI は受信者の受理を保証しない。

transmit window は運用方針も表した。データ駆動の前進では、後端付近の未解決 NAK のためにウィンドウを止め、遅延と引き換えに完全性を守れる。時間駆動では、未解決要求があっても前進し、時刻を守る代わりに古い損失を回復不能にする。

どちらの方針でも NCF の形式は同じである。NCF を数えても、データがあと何秒残るか、完全性と即時性のどちらを優先したかは分からない。確認の記録だけでポリシーを推定することはできない。

Forward Error Correction は修復の素材を変えるが、証拠の連鎖は変えない。RDATA が元パケットのコピーではなく復元用パリティであっても、NCF は要求された修復数を確認するだけである。受信者は十分な断片を実際に得て、復号に成功しなければならない。

RFC 3208 のステータスは Experimental だった。適用性の記述は、輻輳制御、ルーター支援、ローカル再送、プログラミングインターフェースを試作領域として挙げている。RFC 2357 は信頼性マルチキャストを評価する観点を示し、RFC 3208 は実験可能な具体的機構を提示したのであって、普及や性能の達成証明ではない。

セキュリティ上の弱点も、状態を作る表現に沿って現れる。偽の SPM は上流経路を変えられる。偽の NAK は状態資源を消費する。偽の NCF は要求の上流転送を早く止める。偽の RDATA は正当な repair state を先に消し、後から来る本物を妨げる可能性がある。

攻撃者はアプリケーションの本文を偽造しなくてもよい。誰が上流に見えるか、どのインターフェースが失ったように見えるか、要求が生きているか、どの修復で状態を閉じるかという表現を操作すれば経路が変わる。送信元、受信者、DLR、ネットワーク要素を完全に認証することは、単純な基本設計の範囲外だった。

歴史的に重要なのは、NCF が弱かったという話ではない。負の要求が途中で消えないようにするため、NCF は不可欠だった。その強さは射程が明確だったことにある。「この地点で NAK を聞いた」は有用な証拠である。しかし、それを「修復は届いた」と読み替えた瞬間、フィードバックを抑えるための仕組みが、存在しない配達台帳に変わってしまう。