要約

  • RFC 1046の低遅延クラスは、受け入れたデータグラムのノード内待ち時間を上限内に収めるため、キューを小さく制限する案だった。満杯なら新着を廃棄し、他クラスを締め出さないようリンク利用率にも上限を置いた。
  • 複数のType-of-Service指定は、混雑時には累積する権利ではなくORの選択肢だった。別キューへの退避は受け入れ機会を増やす一方、順序反転や片方向遅延のばらつきを招いた。

1988年2月に公開されたRFC 1046は、自らを議論のためのアイデア文書と位置付けている。W. PrueとJ. Postelが扱ったのは、IPv4ヘッダーに既に存在していたサービス種別の希望を、出力リンクの具体的な待ち行列へどう結び付けるかという問題だった。

文書は実装の普及を報告していない。帯域の配分率も、保証する遅延値も確定していない。だからこそ、マークとサービスを同一視しない読み方が必要になる。

キューが伸びるときだけ、選択は現実になる

RFC 791のType of Serviceオクテットは、優先度に加えて低遅延、高スループット、高信頼性の希望を持っていた。三つは同時に良くなる目録ではなく、ある特性を高めると別の特性が悪化し得る三者間の取引として説明されていた。

RFC 1046は、入力需要が現在の能力を超えることを前提にする。キューが大きくならないなら、特別な方式は不要でFIFOで足りる。つまり、パケット上の指定が意味を持つのは、有限のバッファと送信機会を誰に渡すか決めなければならない瞬間である。

送信者は希望を書ける。しかし、資源の不足と他者への影響を観測するのはノード側だ。この役割差は、後の運用証拠にも残さなければならない。

MGDは配送保証ではなく、受け入れ後の待ち時間だった

低遅延クラスの目標は、ノードごとのMaximum Guaranteed Delay（MGD）だった。ただし、文書は「データグラムがインターネットを正常に通過するなら」と条件を付ける。全てのマーク付きパケットを受け入れる約束ではなく、終点への到達保証でもない。

また、低遅延は低RTTと同じではない。クラスは片方向であり、応答やACKは高信頼性など別の指定を持ち得る。

計算式は次の通りだった。

最大遅延 = N / (P × R)

Nは低遅延キューの長さ、Pはそのクラスへ配分したリンク資源の割合、Rは1秒当たりのデータグラム送信率である。目標を変えずに低速リンクや小さな配分へ移れば、許容できるNは小さくなる。リンク固有の伝搬遅延も待ち時間の予算を消費する。

MGDを実体化する値はノードの設定と物理条件にあった。ヘッダーのビットだけでは、キュー深度も帯域配分もリンク速度も決まらない。

早く出られるのは、入れたパケットだけだった

提案は低遅延キューを小さくし、このクラスが過大な資源を使わないよう他クラスより低いサービス率を与える案を示した。到着が上限を超えれば廃棄する。小さなキューではSource Quenchのフィードバックが間に合わないと考え、このクラスでは基本的に送らない。

高信頼性は反対の構造を持つ。より長いキューを使い、早い段階でSource Quenchを送り、満杯になるまで捨てない。混雑損失には強くなるが、待ち時間は長くなる。誤り率の高い回線や前方誤り訂正の問題までは解決しない。

高スループットの例は最大のサービス率と大きなキューを持ち、その代わり平均ノード遅延が大きい。同じburstをまとめる案には、上位プロトコルについて不適切な仮定を置く可能性があると注意が付いた。

三クラスは品質の序列ではない。早期廃棄、長い滞留、送信機会の占有という異なる費用を選んでいる。

複数指定は「全部」ではなく「どれか」だった

RFC 1046は、資源が競合するとき、複数クラスの要求はANDではなくORだと明記した。競合がない場合に限って、低遅延と高スループットの結果が同時に得られ得る。

一つのノードで一つのデータグラムが直ちに入れるクラスキューは一つだけである。候補順は低遅延、高スループット、高信頼性とされた。低遅延と高信頼性の両方を指定したパケットが短いキューに入れなければ、信頼性キューへ回せる。これは入場の機会を増やすが、遅延の取引を変える。

一連のデータグラムが異なるキューへ分かれれば、サービス率の差から順序が入れ替わり、片方向時間も不揃いになる。受信者が元の指定だけを見ても、各ノードの選択や途中の廃棄は再現できない。

優先度には、待ち続ける側の救済があった

0から7の優先度はクラス内で前へ出る力を持つ。ただし、追い越されたデータグラムにはローカルなfrustration pointsが加算される。十分に待ったパケットは新着の高優先度に対抗でき、永久に後回しにされない。

この補正は次のノードへ伝わらず、ヘッダーの優先度も書き換えない。満杯のキューから既存パケットを追い出す権限もない。最後に到着したものが、高優先度であっても廃棄対象になる。

一方で、優先度はMGDの単純な見積もりを崩す。文書の例では、高優先度を伴わない低遅延パケットの待ちが、優先処理なしの1倍から28倍まで伸び得た。低遅延指定だけを成功記録にする監視では、この条件を失う。

未決の問いは、運用者に残された権限だった

17%を低遅延、50%を高スループット、33%を高信頼性へ割り当てる例や、比例したchitを配る方法は提案であって規範値ではない。文書は最後に、MGDをいくつにするか、各比率を誰が決めるか、人気クラスや高優先度の濫用をどう制限するか、複雑さを受け入れられるか、どんなシミュレーションが必要かを問いとして残した。

複数指定の場合は、実際に使った一つのキューだけを計数するよう求めている。希望を三つ数えることと、サービスを三つ提供することは違うからだ。

後の仕様は歴史の境界を示す

RFC 1349は後に、TOSは厳密に助言的な仕組みで、サービス保証の要求には適さないと述べた。RFC 2474とRFC 2475は旧TOS解釈をDS fieldへ置き換え、codepoint、per-hop behavior、サービス、トラフィック調整、実装機構を区別した。

これらはRFC 1046が普及した証拠でも、DiffServが同じアルゴリズムを継承した証拠でもない。持ち運べる印と、ローカル資源を使う挙動が別物だという境界を明確にする。

RFC 1016が記録したSource Quenchの考え方も現在の指針ではない。RFC 6633は後に送信を禁じ、受信時の無視を求め、RFC 1016方式を実装してはならないとした。

出典と限界

七つのRFCは、ヘッダー、1988年の提案、数式、未決事項、後の規範的境界を示す。特定ネットワークでの実装、実際の配分、現在のDSCP対応表、個々のパケットの待遇は示さない。指定、分類、受け入れ、待機、廃棄、配送、アプリケーション結果は別々の証拠である。