要約

  • RFC 1257は、等時性を必要とするアプリケーションでも、経路上の全ネットワークに等間隔配送を要求する必要はないと論じた。十分な帯域と既知の最大転送遅延が、より狭いネットワーク側の約束になる。
  • 送信側が生成時刻を付け、受信側がデータを蓄え、「生成時刻＋最大遅延」で処理する。到着、受け入れ、時計、プロセスの起床、再生は別々の証拠のまま残る。
  • 後のIntegrated Servicesも配送時間の上限を必要とし、RFC 2212はジッタを最小化せず最大遅延を保証した。早着したデータグラムは再生時刻まで受信側で待つ設計だった。

画面の周期と回線の周期は別の場所にあった

電話は一定間隔で音声を標本化し、固定レートの映像コーデックも周期的にデータを生成する。最終出力が乱れれば、人は音の歪みや画面のちらつきを感じる。だからネットワークも同じ周期でデータを渡すべきだ、という要求は自然に見えた。

RFC 1257は人間の感覚を否定しなかった。会話には過大な遅延が許されず、映像には十分な容量が必要だとも認めた。そのうえで、受信インターフェースに届く間隔と、アプリケーションが出力を処理する間隔を切り分けた。前者が揺れても、後者は受信側で復元できる。

異なるサブネットを連結するインターネットでは、この切り分けが共通実装の範囲を狭める。すべてのネットワークに同じジッタ制御を強制しなくても、最終的な等時処理を成立させられる可能性があるからだ。

ネットワークは締切の外枠を出す

前提は、チャネルに必要な帯域があり、最大転送遅延を上から押さえられることだった。少なくとも受信側はその値を知る。ある単位はすぐに着き、次は上限近くまでかかってよい。上限は平均値でも到着周期でもなく、条件を満たすデータが越えてはならない最終時刻である。

この値は設定欄に書くだけでは成立しない。経路と資源の根拠が必要であり、経路が変われば旧い上限の適用範囲も変わる。送信量が容量を越えれば、受信メモリは不足帯域を補えない。損失した単位は、他の単位が締切内に着いても復元されない。

RFC 1257の主張は、宣言された仮定の下で何が十分かを示すものだった。実在網の普遍的性能測定ではない。

早着分はバッファ滞在時間に変わった

送信側は共通の時間基準を用いて、生成時に各単位へ時刻を付ける。受信側は到着するとすぐバッファへ入れる。必要容量はチャネル帯域と最大到着間隔変動の積であり、論証上の最悪条件では最大遅延をその変動として見積もれるとした。

到着直後には処理しない。時計が「生成時刻＋最大転送遅延」に達したときに取り出す。早く届いたものほど長く待ち、上限近くで届いたものは短く待つ。転送時間のばらつきはバッファ内滞在のばらつきへ移り、出力周期は生成周期に戻る。

この動作は一つの成功フラグでは説明できない。生成時刻は送信側の記録である。時計源、偏差、不確かさは時刻比較の証拠である。到着は観測経路を示す。バッファへの受け入れと占有量はメモリ状態を示す。実際の起床はOSスケジューラの記録である。再生、破棄、損失隠蔽はアプリケーションの決定だ。人が正しく聞いたかはさらに別である。

パケットが定刻でもプロセスは眠り得る

ネットワークが完全な周期でホストへ渡しても、OSが受信アプリケーションを適時に走らせなければ、出力はまとめて処理される。ネットワーク内の等時性はホスト境界で失われる。

RFC 1257はこれをエンドツーエンドの配置論に使った。ネットワークの性質にかかわらず、受信システムには規則的な起床機構が要る。パケット割り込みでプロセスを起こせるなら、時計割り込みでも起こせる。端点で再び保証しなければならない機能を全ネットワークに重ねるのは冗長になり得る。

ただし、端点は帯域と最大遅延を入力として必要とする。これはネットワーク責任の否定ではなく、共同作業の境界だった。

メモリは費用を消さず、置き場所を変えた

到着変動が大きいほど、必要な記憶量と再生待ち時間は増え得る。RFC 1257は、当時の電話のようにメモリを持たない装置を限界として挙げた。将来端末にメモリが増えるか、最終スイッチが端末直前で等時性を戻す案を示した。

ネットワーク内でジッタを制御する設計は、経路上のキュー、時計、スケジューリングへ費用を置く。端点復元は受信側のメモリ、時刻同期、ソフトウェアへ置く。同じ滑らかな出力でも、所有者と障害領域は違う。

文書はジッタ制御を無価値とはしなかった。ばらつきを狭めれば中間ノードのメモリを減らせる場合がある。「アプリケーション支援の必須条件ではない」と「役に立たない」は同義ではない。

リアルタイム要求は最初から複数の境界だった

RFC 1193は前年、クライアント要求をスループット、遅延、遅延変動、信頼性などの上限・下限として整理していた。対話は長い遅延に弱く、大量転送は最低スループットを重視し得る。音声や映像は限定的な損失を許しても、無制限な待ちを許すとは限らない。

RFC 1257は遅延変動を消したのではなく、どの層が最終周期を作るかを分解した。利用者の要求から直ちに各ネットワーク要素の実装を決めることはできない。ネットワークの外枠と端点状態を結合し、どの仮定がどこで満たされたかを残す必要がある。

したがって「リアルタイム」というラベル自体は結果ではない。個別フローの達成には、投入量、受付、経路、到着履歴、時計、メモリ、実行、出力の照合が要る。

後の保証サービスもジッタ最小化を約束しなかった

RFC 1633は1994年、初期のインターネット音声・映像実験が可変キュー遅延と輻輳損失に苦しんだと記した。アプリケーションが適応しても、人間の対話と明瞭度があるため配送時間の上限は必要だとし、予約、受付制御、フロー単位のソフト状態を提案した。同時に、外部サービスモデルと変更可能な実装機構を分けた。

RFC 1257からの直接の因果関係を示す資料ではない。しかし、ネットワークが信頼できる遅延外枠を管理し、端点が処理責任を残すという境界は両立する。

RFC 2212は1997年、適合トラフィックに帯域と数学的な最大エンドツーエンド遅延を与える保証サービスを規定した。最小遅延、平均遅延、ジッタを小さくするサービスではない。再生アプリケーションは、多くのデータグラムが締切より早く届くため、処理時刻まで受信側で保持する必要があった。

ネットワークの上限と受信側の再生周期は補完関係にある。一方をもう一方の証拠にしてはならない。

滑らかな再生から途中の規則性は推定できない

アプリケーションは損失を無音で埋め、定刻に出力できる。全データが遅延上限内でも、メモリ不足で早着データを落とし得る。時計差は測定誤差を片方向遅延違反に見せる。定刻到着後にCPUが遅れることもある。経路変更後に旧い保証を使い続けることもある。

監査には、投入・受付レート、経路または予約、上限と適用条件、単位別到着、時計源と不確かさ、受け入れと占有量、要求・実起床時刻、遅着・損失・重複・順序逆転、処理方針、利用者結果が必要だ。最終出力だけから欠けた証拠を作ってはならない。

出典と証拠の限界

中心資料は RFC 1257 である。先行する要求語彙は RFC 1193、後のIntegrated Servicesは RFC 1633、ジッタを最小化せず最大遅延を保証する仕様は RFC 2212 に基づく。

これらは現行製品、フロー、予約、展開、時計精度、バッファ量、スケジューラ動作、利用者体験を証明しない。文書間の直接因果も確定しない。RFC 1257はInformationalであり、結論は明示された仮定の範囲に限られる。