要約

  • RFC 3738はWEBRCの輻輳測定と速度判断を各受信者に置いた。受信者は送信者へ個別報告を送る代わりに、マルチキャスト・チャネルへ参加または離脱した。
  • 送信側のウェーブを複数チャネルに分けることで、参加状態が受信速度の差につながった。一方、受信側の複雑さが増し、信頼性や配信完了の証明は提供されなかった。

静かな送信者だけでは仕組みを説明できない

マルチキャストには魅力的な算術がある。受信者ごとに独立したデータストリームを開かず、一つのセッションをグループへ送信できる。しかし、混雑は均等に起きない。細いリンクや混み合ったリンクの先にいる受信者は損失に直面しても、同じセッションの別の受信者には余裕が残ることがある。送信側が速度を調整する前に全受信者から報告を集める必要があれば、フィードバックそのものが拡張性の課題になる。

2004年4月にExperimental RFCとして発行されたRFC 3738は、別の役割分担を試した。Wave and Equation Based Rate Control（WEBRC）はマルチキャスト・プロトコル向けの輻輳制御ビルディングブロックだ。受信者が輻輳報告を送信者に送る必要はない。各受信者が自分の経路を測り、目標受信速度を計算し、加入するマルチキャスト・チャネルを変える。つまり「送信者へのフィードバックなし」は「信号なし」ではない。信号はチャネルへの参加・離脱という通常のネットワーク動作だった。

この違いは微妙だが、制御の配置を変える。送信者には、損失、空き帯域、転送完了を示す受信者別の報告が届かない。一方、受信者も個別ストリームの交渉を送信者に待つ必要がない。送信者が共通のチャネル群を発信し、各受信者が自分の混雑推定に応じてその一部を選ぶ。

参加状態で表す速度制御

WEBRCでは、セッションを低速のベース・チャネルと複数のウェーブ・チャネルに分ける。ベース・チャネルはセッションの時間スロット周期を把握する助けとなり、参加中は受信を続ける。ウェーブ・チャネルの速度は時間とともに変わる。高い速度で始まった後、時間スロットごとにパケット速度が下がり、静止期間に入ったのち周期が繰り返される。

この時間パターンがあるため、受信者は新たな専用ストリームを要求せずに速度を選べた。目標速度を上げる場合は、ウェーブの下降中に次のアクティブな層へ早めに参加する。下げる場合は新たな層への参加を控え、そのウェーブが静止したときにチャネルを離れる。アクティブなウェーブの層順は周期の進行に伴って変わるため、受信者はセッションの時間スロット番号と既に参加しているチャネルを追い続ける必要があった。

目標速度は単なる好みではない。WEBRCは平均パケット損失確率と平均マルチキャスト往復時間を推定し、TFRCに着想を得たTCP類似の式に当てはめる。その結果は、次の層へ参加しても目標以下に収まるかを判断する材料となる。RFCが示した設計目標は、TCPと競合する際の合理的な公平性と、時間経過に伴う滑らかなスループットだった。その代わり、利用可能帯域の変化にはTCPよりゆっくり反応する。これらは仕様に記された設計目標であり、特定の導入環境で実現したことを示す実測ではない。

複雑さと送信者の知識の交換

送信側の役割は意図的に簡素だった。セッション全チャネルの送信速度上限、チャネル割当、時間パラメーター、チャネルと時間スロットを示すパケットヘッダーがあればよい。重い処理は受信側が担う。損失を測り、マルチキャスト往復時間を推定し、平均値を更新し、変わる層順を追い、いつ参加・離脱するか決める。受信者ごとに別の速度を選べるため、最も遅い受信者が全体の速度を決める必要はない。

この交換は、送信者が知り得ることも制限する。受信者がチャネルに参加または離脱すれば、その受信者へのネットワーク配信経路は変わる。しかし、その操作が「誰がどのデータを受け取ったか」を知らせる送信者向けの報告になるわけではない。RFC 3738は輻輳制御の部品であり、完了通知プロトコルではない。再送や損失回復も提供しない。セッション記述やパケットとセッションの識別も、他のビルディングブロックや帯域外配布に委ねている。信頼性、受信完了、アプリケーションによる受理は別の問いとして残る。

RFC 3738はRMTのモジュール型設計の一部でもある。RFC 3269は信頼性のあるマルチキャスト転送の設計指針を示し、RFC 3048はビルディングブロックを組み合わせる枠組みを定義した。したがってWEBRCは信頼性やオブジェクト配信の仕組みと組み合わせられるが、組み合わせても各部品の責任は自動的に一つにならない。輻輳制御は受信を調整できてもオブジェクト再構成を保証しない。修復レイヤーが再構成を助けても、どの受信者が完了したかを送信者へ知らせるとは限らない。

RFC 3738の位置付けも歴史の一部だ。著者らは、有効性と拡張性を初期導入と経験で確認するまで、Experimentalとして公表すると明記した。仕組みが十分と判断されればProposed Standardとして再提出する意図をワーキンググループは示している。しかし、その意図は導入実績、後続の標準化判断、運用採用の証拠ではない。文書が記録するのは設計とその前提だ。稼働中の実装、挙動の測定、後年の標準化判断にはそれぞれ独立した証拠が要る。

出典