要約

  • RFC 1458 は、同じ優先度なら、単独でも役立つ低品質データを残し、それに依存する高品質の拡張データを先に廃棄する方式を提案した。
  • その判断は、アプリケーションの依存宣言、利用者の要求、MGA の集計、出力インターフェース状態、実際の廃棄、修復、最終利用を分けて観測しなければ検証できない。

キューがあふれる瞬間、ルーターには画像が見えない。見えるのは宛先、印、優先度、そして残り容量だけである。それでも RFC 1458 は、画像のどの部分を先に諦めるかという判断をルーターに担わせようとした。

鍵は「品質」の意味にあった。高品質層は、より鮮明な細部を与える。低品質層は、粗くても画像そのものを成立させる。前者が後者に依存するなら、順序の数字と情報の不可欠性は逆になる。

大容量画像が二値の信頼性を崩した

RFC 1458 は 1993 年 5 月に発行された。RFC Editor の記録上の位置づけは Informational であり、Internet Standard ではない。想定されたのは、数万画素四方の遠隔観測画像、日量数千テラバイト、数百の分散利用者、最大六桁も異なる帯域、秒から分単位の配信期限だった。

同じシステムでも必要な信頼性は異なる。画像会議のマウス移動は一部を失ってもよい。保存や精密解析では欠落を回復しなければならない。階層画像では、基底解像度だけ確実に届け、上位の細部は補間で補える範囲の損失を許すという中間が生まれる。

利用者が欲しい品質と、確実に必要な最低品質は別の値になる。RFC 1458 はこの差をネットワーク全体の状態として扱おうとした。

MGA、RAMP、ルーティングの三分割

提案は一つのトランスポートだけではない。Multicast Group Authority（MGA）がアドレス、サービス登録、品質別の会員数を管理し、Reliable Adaptive Multicast Protocol（RAMP）が順序、損失回復、送信率を担う。ルーターは各出力インターフェースについて、グループと要求品質の組を保持する。

サービス登録は送信開始を意味しない。サーバーは MGA の指示を待つ。未登録サービスへの要求は待ち行列に置ける。ある品質の最初の利用者が送信を始めさせ、最後の利用者の離脱がその品質だけを止めることもある。

品質変更も一個のフラグ更新では終わらない。旧品質の数を減らし、新品質を増やし、階層に伝え、必要ならサーバーとルーターを更新する。要求受理、状態反映、パケット転送、アプリケーション表示には時間差がある。

TOS フィールドで意味の所有者が衝突した

RAMP は一つのパケットに複数のアプリケーション品質を付けられるとした。受信側は参加済みグループと要求品質の両方を照合する。古い IPv4 実装では Type of Service フィールドを品質ビット群として使う案が示された。

RFC 1458 自身が、これは RFC 1349 と両立しないと記している。RFC 1349 の TOS は、遅延、スループット、信頼性、金銭的コストのどれをネットワークが重視するかを示す単一の列挙値であり、複数値の論理和は意味を持たない。RFC 791 も TOS を IP のネットワークサービス指定として置いていた。

同じビットを見ても、意味の権限が異なる。IP 層の経路要求なのか、画像の依存層なのかは、値だけでは決まらない。プロトコル版、実験条件、送信側と各ルーターの設定がなければ、パケットキャプチャは形を示すだけで意味を確定しない。

先に落とすべき「上位」

提案されたルーターは、グループと品質が一致するインターフェースだけにパケットを複製する。混雑時は優先度付きパケットを最後まで残す。一方、同一優先度の中では最も高品質のパケットを先に落とす。

低品質層だけでも利用でき、高品質層は低品質層なしでは利用できない、という前提がこの順序を支える。基底を残せば退化画像という結果が残る。拡張だけを残せば、正しく届いたデータがあっても結果がゼロになる可能性がある。

RFC の例は、Q1 と Q2 が独立する場合と、Q2 が Q1 に必要な場合を分ける。独立なら別の宛先へ送る。依存するなら Q2 パケットに双方の印を付け、分岐点で両方に送る。ここで印は依存の主張であり、出力表は需要の主張である。

どちらも真実そのものではない。アプリケーションが層関係を誤る、MGA の数が古い、経路更新が途中、機器が RFC 1349 の意味で読む、基底が期限後に届く、RAMP が受けてもクライアントが処理しない、といったずれが残る。

NAK の数で修復範囲を選ぶ

RAMP では受信側が欠けたシーケンス範囲を NAK で知らせる。送信側は一定時間要求を集め、同じ欠落について閾値を超えればマルチキャスト、少数なら各要求者へのユニキャストで修復する。保持バッファからデータが消えた後なら修復できない。

単独損失を全員に再送する浪費と、共通損失を多数の個別コピーで直す浪費の間を選ぶ仕組みである。しかし NAK は原因を証明しない。閾値は全会員の必要性を証明しない。再送は到着を証明せず、到着は画像の成立を証明しない。

送信率も再送要求やルーターからの後退信号で下げ、要求のない期間を見て小さく上げる。沈黙は制御入力にはなるが、会員全員の正常性を示す監査証拠にはならない。

RFC 1458 が証明しないこと

文書は RFC 1301 の Multicast Transport Protocol を評価し、マスター、送信トークン、選択的 NAK 回復を認めながら、制御の集中が大画像配信には重いと判断した。また RFC 1112 の IP マルチキャスト参加モデルを前提にした。

これは当時の設計比較を示すが、RAMP や MGA の実運用を示さない。文書はセキュリティを論じないと明記する。グループ参加は本人確認ではなく、サービス登録はアクセス許可ではなく、品質印は送信元や完全性の証明ではない。

歴史的な価値は、制御が結果に届くまでの距離を可視化したことにある。「高品質を先に落とした」というカウンターだけでは、利用可能な画像を守ったとはまだ言えない。