要約

  • RFC 1363は、映像会議などが特別な通信サービスを求めるためのフロー仕様を提案した。要求は片方向ごとに書く。遅延の項目は改善をどこで止めてよいか示す目安で、全経路に課す到着期限ではない。
  • 持続速度、ピーク速度、バースト、受信側の緩衝、損失、保証の強さを別々に記す。最後の区間が混雑しうるEthernetなら、「たいていうまく動く」と「各区間で保証する」は別の約束になる。

通話画面に「100ミリ秒」と書けば、技術的に正確に見える。Craig Partridgeは1992年9月のRFC 1363で、その数字に行き先を尋ねた。米国と日本の間なら100ミリ秒を歓迎するかもしれない。同じ街の相手なら不満かもしれない。RFCに出てくるのは二つの実測記録ではなく、最大遅延を一律に決める発想への反例だ。

狙いは映像会議や可視化など、単にパケットが届くだけでは足りない分散アプリケーションだった。端末は送信前、接続の準備中、あるいは送信しながらネットワークと交渉できる。文書は交渉手順を一つに決めず、端末が持参する情報の書式を定めた。しかも一枚で扱うのは片方向だけだ。互いに話す通話なら、往路と復路それぞれに要求が要る。

Minimum Delay Noticedという項目は名前からして誤解されやすい。意味は、遅延をそれ以上減らしてもアプリケーションがほとんど気付かない地点を伝えること。配達の最大許容時間ではない。端末間の地理的距離はネットワークから分からないことがあり、移動端末ならなおさら変わる。利用者がその時どれだけ待てるかをアプリケーションが正確に知ることも難しい。Partridgeは、100ミリ秒を超えた会話が不可能だという定型句にも異議を唱えた。数秒の遅れを受け入れてでも話したい用件はある。

要求書にはまず送信量を書く。トークンバケットの持続速度、最大速度、おおよそのバースト量だ。経路選択はこの負荷を知らずにできない。RFCは、毎秒10メガビットを超えるフローを毎秒1.5メガビットのT1回線に通す例を退ける。遅延の数字に何を記しても、回線の幅は広がらない。

受信側にも負担がある。一定の間隔で送り出された音声が、途中の待ち行列によって不揃いに届けば、受信機は一時的にためて再生の間隔を戻す。許容する遅延の揺れは、受信側が用意できる緩衝領域とつながる。文書は到着時刻の開きと転送速度から必要量を説明した。損失も合計だけでは足りない。一定区間に失われる数と、続けて失われる数を別に問う。同じ件数でも、一度に固まって消えれば受け手に残る穴は違う。

最後に、事業者が何を保証するかを選ぶ。Quality of Guaranteeは単なる希望、不完全な保証、予測サービス、強い保証を区別した。PartridgeはIETFの会議実験を引き、最後の一跳がEthernetでも十分な性能が出る場合を挙げる。同時に、その共有区間が通話中に混雑しないとは約束できない。そこを含む経路は便利でも、全区間保証の経路とは違う。予測サービスなら協調する装置が負荷時の小幅な悪化を扱える。不完全な保証の弱点は、協調しない区間が予測なしに崩れることだ。

強い保証への答えは、基本的に受け入れるか断るか。端末が許容できる最低水準を求め、ネットワークは満たす経路を見つける。Partridgeは、通話を始めるたびに理想から妥協案まで長い値切り交渉を重ねる方法を嫌った。断ったときに修正案を返すことはできるが、それは確保済みのサービスではなく手掛かりである。

この仕様は要求を伝える言語であり、全インターネットに展開済みの予約機構を発表したものではない。価値は別のところにある。端末は自分の負荷と許容範囲を説明し、ネットワークはどの区間でどの程度の約束を守れるか答える。100ミリ秒は、そのやり取りを省いてよい魔法の数字にはならなかった。

出典：RFC 1363；RFC 1363の公式記録。