要約

  • RFC 5401 の受信者は途中参加、離脱、再参加をし得るため、現在のグループ構成は配信対象や完全性の分母と一致しない。
  • NACK 抑制と反復修復はフィードバックを拡張可能にするが、沈黙から個々の受信者の履歴や再構成結果を復元することはできない。
  • 完了ポリシーは、誰を数えるか、遅い受信者をどう扱うか、どの証跡をアプリケーション成功とみなすかを先に定義しなければならない。

「いまいる」と「最初から受け取った」は違う

RFC 5401 は 2008 年 11 月に標準化過程の文書として公開され、実験的な RFC 3941 を置き換えた。負の確認応答を使う信頼性マルチキャストの構成要素を示し、多数の受信者が同時に同じ欠落を訴えるフィードバック・インプロージョンを抑える。

設計上、正常な受信者は話さない。欠落を検出した受信者は NACK サイクルを始め、ランダムな時間だけ待つ。その間に他の受信者の要求が自分の必要を包含すれば、自分の NACK を抑制する。これにより、送信者は全員から同じ苦情を集めずに共有修復を行える。

ところが、グループの構成は固定されていない。受信者は途中から参加し、一度離れ、後で戻ることができる。終盤のメンバー一覧は、冒頭のデータを受け取る権利があった集合でも、実際に受け取った集合でもない。

途中参加者が NACK を出さない理由は、完全だからとは限らない。以前の送信位置を知らず、欠落として判定できる履歴がない場合もある。したがって、メンバーシップの観測とコンテンツ完全性の観測を一つの状態にまとめてはならない。

欠落検出には履歴が必要になる

受信者が修復の必要を判断するには、受信済みコンテンツの履歴を保持しなければならない。NACK サイクルを開始するときは送信者の送信位置を記録する。待機中に新しいパケットが届いても、サイクル開始時の判断境界を失わないためである。

途中参加者には、この前史が存在しないことがある。現在のシーケンスだけを見れば連続していても、オブジェクトの前半がない。プロトコルやアプリケーションは、途中参加者に完全なオブジェクトを提供するのか、次のオブジェクトまで待たせるのか、別の修復経路へ送るのかを定める必要がある。

再参加にも同じ問題がある。識別子が同じでも、保持している履歴が連続しているとは限らない。離脱中に失った範囲、状態の有効期限、再同期の方法を明示しなければ、システムは存在確認を完全性と誤認する。

運用記録には、加入時刻、対象オブジェクト、最初に観測した送信位置、保持履歴の範囲、離脱と再参加、必要な修復を残すべきだ。単なるオンライン人数は、配送義務も達成状況も表さない。

抑制された声は結果を語らない

既存メンバーが欠落を検出しても、すぐには話さない。ランダム退避の間に先行 NACK を聞き、その要求が十分なら自分の要求を止める。送信者から転送された修復状態や、修復のための送信位置の巻き戻しを見て抑制する場合もある。

抑制は「もう一つ同じ要求を送る必要がない」という局所判断である。「修復を受信した」という判断ではない。先行 NACK が送信者に届いても、修復パケットが特定の受信者に届かないことはある。修復を受信しても、再構成に必要な量へ達しないこともある。

また NACK 自体の完全な信頼性を必須にしない設計も可能である。反復サイクルで収束できるなら、失われた NACK は次の周期で再試行される。したがって、一回の静かな窓は成功証明ではなく、長い状態機械の一場面にすぎない。

記録すべきなのは、NACK が送信されたか、他の要求で抑制されたか、修復を待っているか、次のサイクルへ移ったかである。これらをすべて「問題なし」に畳み込むと、弱い受信者が消える。

FEC は異なる欠落をまとめる

前方誤り訂正を使えば、異なるソースパケットを失った受信者に同じ修復シンボルを役立てられる。RFC 5052 はコンテンツ配信の FEC フレームワークを定義しており、RFC 5401 の修復要求でも符号化ブロックや必要シンボルを扱える。

共有修復は効率的だが、全員が同時に完成するわけではない。各受信者は別の消失パターンを持つ。一つの修復で完成する者、複数回を要する者、ブロック開始時のソースを持たない途中参加者がいる。

受信者は、すでに予定されている修復を考慮してから追加 NACK を出すべきである。これは重複要求を減らす一方、「修復予定だが未受信」という中間状態を生む。送信者から見ると静かでも、受信者の仕事は終わっていない。

さらに FEC 単独では輻輳制御にならない。RFC 5052 と RFC 5651 は、完全なプロトコル実装に互換性のある輻輳制御が必要だと示す。修復量を増やせば常に速くなるわけではない。帯域を圧迫し、遠端の回復をさらに遅らせる場合がある。

タイマー推定は最遠端の証明ではない

ランダム退避を長くすると、先行要求が後続要求を抑制できる時間が増える。大きなグループではフィードバック量を抑えやすい。一方、欠落検出から要求送信までの遅延が増え、送受信双方が状態を長く保持する。

RFC 5401 はグループ規模やグループ最大往復時間の推定をタイマー調整に利用する。しかし推定は名簿ではない。もっとも遠い受信者が測定に含まれたこと、現在も到達可能であること、途中加入者が反映されたことを保証しない。

運用画面は推定値だけでなく、その取得時刻、対象範囲、更新条件を示すべきだ。退避時間、抑制数、修復ラウンド、再構成までの分位点も並べる。平均値だけなら、中心部の速い多数が周縁の遅い少数を隠す。

これは単なる性能調整ではない。長い窓は制御負荷を下げる代わりに利用者の待ち時間を増やす。短い窓は速く反応する代わりにフィードバック洪水を招き得る。どちらを選んだか、なぜ選んだかをサービス目標と結び付ける必要がある。

完了の分母はポリシーで決まる

アプリケーションによっては、一定割合の受信者が完成すれば処理を進められる。別の用途では最弱メンバーを待たなければならない。非常に状態の悪い受信者を除外したり、別の配信グループへ移したりする方針もあり得る。

これらは RFC 5401 の NACK メカニズムそのものが決めることではない。具体的なプロトコルとアプリケーションが完了条件を定義する。つまり「全員」の意味はパケット数から自動的に得られず、組織が責任を持って決める。

対象集合をいつ確定するのか。途中参加者は現在のオブジェクトに含むのか。再参加者の古い状態を信頼するのか。何回失敗したら別グループへ移すのか。その移動を成功、延期、例外のどれとして報告するのか。除外を承認できるのは誰か。

これらが曖昧なら、完了率は難しい受信者を分母から外すことで上がる。ネットワーク処理が正しくても、経営報告は約束した相手を変えてしまう。予定集合、現時点の参加集合、完了判定集合を別々に保つべきである。

輸送完了と利用完了をつなぐ

RFC 5740 の NORM は関連する構成要素を具体的なプロトコルへまとめる。しかしプロトコル状態が終了しても、アプリケーションがオブジェクトを検証し、保存し、実行した証明にはならない。

証跡は対象集合と配信内容の識別情報から始まる。送信位置、受信履歴、欠落検出、NACK サイクル、抑制理由、修復送信、修復受信、ローカル再構成、アプリ受理を区別する。全用途で全員から肯定応答を取る必要はないが、省略する証拠と受け入れるリスクを明示する。

通常配信では統計、重要受信者のサンプル、期限と例外管理で十分かもしれない。安全更新や旧版停止を伴う作業では、指定受信者の明示的な受理が必要になる。安い証跡を強い証明の言葉で表示しないことが重要である。

参照した標準は、現在の普及率、各製品の実装、事故頻度、唯一の最適値を示していない。具体的評価には製品資料、設定、実測が必要である。ただし、途中参加者と抑制された受信者の存在だけで、送信端の沈黙を全員完了と呼べないことは十分に分かる。