要約

  • RFC 1453は、下位層にある帯域と、アプリケーションが時間内に使える帯域を別の事実として扱った。ドライバ、OS、受信FIFOが詰まれば、高速回線でも会議は成立しない。
  • 文書はXTPを、機構と方針を分離できる候補として推した。同時に、優先度だけでは遅延を制御できず、会議への参加許可は上位層の仕事だと限界も明記した。
  • 当時の実験報告は特定条件での可能性を示すにとどまる。リンク、ホスト、アプリ、セッション、利用者という各境界で、別々の証拠が必要だった。

帯域はどこでサービスに変わるのか

RFC 1453を、単に古いマルチメディア用プロトコルの紹介として読むと核心を逃す。文書が突いたのは測定地点の問題である。データリンク層が高速になり、トランスポートが大量のデータを扱えても、上位層がその帯域へアクセスできなければ、利用者から見た性能は生まれない。

William J. Chimiakが1993年4月に公表したこの文書はInformationalで、Internet Standardではなかった。しかも、Xpress Transfer Protocol（XTP）をInternetコミュニティへ知らせる媒体だと自ら述べている。したがってXTPの評価は、利害のない判定ではなく提案者側の主張として扱う必要がある。

それでも問題設定は独立して残る。高速な入力の先に、割り込み処理、コンテキストスイッチ、メモリコピー、ドライバ、カーネルキュー、ユーザー空間のスケジューリングが並ぶ。そのどこかが狭ければ、入口の余裕は再生バッファの余裕にならない。

インターフェースの受信カウンタはリンクの観測であり、会議の観測ではない。ソケットへの配送はトランスポートの観測であり、表示時刻の観測ではない。各層の事実は本物だが、隣の層の事実を代行しない。

「マルチメディア」という一語では粗すぎた

RFC 1453が想定した遠隔会議には、対話型の音声と映像、マルチキャスト、データ転送、グラフィックス、録画・録音素材、データベース照会が同居した。それぞれが別の失敗を嫌う。

ファイルは欠損を許しにくい。会話の音声は、期限後の再送を待つより一部を捨てた方がよい場合がある。データベース照会は往復時間に敏感である。映像と音声は、それぞれの連続性だけでなく、互いの時刻関係も守らなければならない。

会議の制御も必要だった。開始し、進行中に参加し、一人が離れても残りの会議を壊さず、最後に終了する。文書は、およそ2人から15人の厳密な多対多型と、より緩い一対多型を区別した。

誰が会議の存在を知り、誰が参加できるかは上位プロトコルの判断だった。優先ビットは認証情報ではない。高い転送優先度を持つパケットが、正当な参加者になるわけでもない。

QoSはアプリケーションから下へ渡す要求だった

RFC 1453は、保証スループット、接続信頼性、呼の完了と切断、許容誤り、圧縮、動きの乱れ、フロー制御、遅延をQoSの候補に挙げた。そしてQoSを、アプリケーションまたはトランスポートサービス利用者からトランスポート層への入力にすべきだとした。

この向きには意味がある。アプリは、フレームがいつ無価値になるか、コーデックがどれほどの欠損を隠せるか、どの程度の音画ずれを許せるかを知っている。ネットワークは、経路、キュー、資源を知っている。前者の目的を後者の制約へ翻訳して、初めて交渉可能なサービスになる。

RFC 1193はそれ以前に、遅延、遅延変動、最小スループット、信頼性をクライアント側から記述していた。「保証」を、条件と双方の義務を伴う強い約束として論じた点も重要である。法的な構図をそのまま採用しなくても、保証には指標、境界、条件、検証が要るという原則は変わらない。

したがって「1Gbpsのポート」は「会議が使えるか」への答えにならない。平均スループットが高くても、周期的な停止で再生FIFOが空になるかもしれない。損失を減らす大きなバッファが、対話には耐えられない遅延を作るかもしれない。

XTPが目指したのは交換可能な方針

文書は、アプリケーションの種類ごとに新しいプロトコルを作る流れを問題視した。XTPは、共通のトランスポートに豊富な機構を置き、アプリケーションが方針を選べる案として提示された。

32ビットのSORTフィールドは優先度を運び、選択確認、迅速な否定確認、選択再送は誤り制御を調整する。レート、バースト、フローの制御はスループット要求に使える。マルチキャストと帯域外配送も用意された。Partially Error Controlled Connectionsは、完全性と期限の間を動かし、受信FIFOを飢えさせないことを狙った。

期限のあるデータでは、すべての欠損を直すことが常に正しいとは限らない。音声片を再送しても再生時刻を過ぎていれば、ネットワーク負荷を増やすだけで会話を直さない。一方、ファイル片なら遅くても取り戻す価値がある。価値はバイトそのものではなく用途と時刻で決まる。

機構と方針を分ければ、リンク状態が変わったときに、接続を閉じて別のスタックを作らず、誤り制御やフロー制御の方針を変えられる。セッションを維持したまま扱いを変えるという発想である。

ただしRFC 1453は、XTPの優先度機構がそれだけで遅延を制御するわけではないと明記した。優先度は競合順を変えても、全層の待ち行列を消さず、容量を作らず、アプリを時刻通り実行させない。既存プロトコルでも同じアプリを実現できるだろうとも認めた。

この自己制限が証拠の境界になる。機構の存在は、設定の妥当性、支配対象のキュー、最終結果のどれも証明しない。

ボトルネックは成功した層の上へ移る

部分的誤り制御の例では、受信FIFOを空にしない範囲で回復を最大化しようとした。それが成功すれば、次はアプリ、ドライバ、OSのバッファ制御が制約になり得る。局所的な改善は、問題を消すより次の境界を露出させる。

だから観測も上へ進む必要がある。トランスポートの完全性が上がっても、有効フレーム数が減る場合がある。カーネルキューが満たされていても、ユーザープロセスがスケジュールされない場合がある。音声と映像が個別に届いても、同時に提示されない場合がある。

証拠の順序は次のようになる。

利用可能なリンク容量 → 設定されたトランスポート機構 → 持続するホスト内配送 → アプリが使えるメディアを受信 → セッション要件を充足 → 利用体験を観測

矢印ごとに新しい観測が要る。優先度は遅延上限ではない。ソケット内のデータは再生FIFOの健全性ではない。二つのストリーム受信はリップシンクではない。パケット受信は参加許可ではない。

RFC 1453がハードウェア製造まで論じたのも同じ理由である。システムインターフェース、VLSI、並列状態機械、割り込みやコンテキストスイッチが価格と実効性能を決める。ワイヤ上の美しい設計が、そのままプロセスの性能にはならない。

実験値には持ち出せない条件がある

文書は、University of VirginiaでFDDI上に100を超える模擬音声チャネルを流した試験、毎秒30フレームのビデオメール実演、NRaDで単純な音声マルチキャストのマイクからスピーカーまで約25ミリ秒、そして1.2Mbpsの圧縮映像を少なくとも10ストリーム同時配信した商用例を報告した。

当時、これらはパケットネットワークにはマルチメディアが不可能だという見方への有力な反例だった。しかし、XTPの普及率、独立再現、一般のInternet条件、普遍的な遅延保証ではない。

結果を比較可能にするには、機器、トポロジー、負荷、コーデック、損失、再送方針、時計、計測開始点と終了点を残す必要がある。30fpsでも数秒の先読みがあれば対話用途ではない。100模擬チャネルは100会話の明瞭性を意味しない。

歴史記述では「RFC 1453が報告した」という主語を落としてはならない。報告は可能性を示すが、世界全体の実装状況を表さない。

資源を予約するST-II、保証を引き受けないRTP

ST-IIは別の制御配置を示した。起点がストリームを作成し、FlowSpecが要求を表し、中間エージェントが資源を予約し、宛先が受諾する。参加者の追加・削除や故障後の再構成もネットワーク状態として扱った。

これは要求を分散した約束へ変える方法だったが、セットアップ、状態、回復の費用を伴う。XTPは汎用機構と変更可能な方針を選んだ。どちらも、アプリ側の最終確認を不要にはしない。

後のRFC 3550はRTP/RTCPを、リアルタイムデータの配送と監視のために定義した。同時に、RTP自体は資源予約もQoS保証もせず、適時配送や配送そのものを保証せず、順序入れ替わりも防がないと明記した。シーケンス番号や報告は観測手段であり、サービスを作る装置ではない。

RFC 1453からRTPへの直接の因果を主張する根拠はない。比較から得られるのは、プロトコルの機能と、その機能が引き受けない責任を分けて読む方法である。

出典と限界

文書の地位と出版情報はRFC 1453のRFC Editor記録にある。問題設定、XTPの提案、限界、報告された実演はRFC 1453全文による。クライアント側の性能要求はRFC 1193に、資源予約を伴うST-IIはRFC 1190に記載される。後のRTPの範囲と非保証はRFC 3550が示す。

これらは文書、設計、主張、限定された実験報告を裏づける。現在の配備、ベンダー性能、独立再現、利用者満足、XTPからRTPへの因果関係は裏づけない。