要約

  • IntServ はフローごとの状態によって精度を得たが、コアの処理・記憶コストを増やした。
  • DiffServ は集約で拡張性を得た一方、RFC 2990 はコアから境界への資源信号と、境界からアプリへの受付結果が未定義だと指摘した。
  • クラス指定、受付、配送、計測、利用帰属、請求は別々の事実であり、同じ印を領収証にしてはならない。

優先印は制御ループではない

パケットに優先クラスを示す印があっても、資源は増えない。RFC 2990 は、差別化された応答には振る舞いだけでなく、その振る舞いへ入れる負荷を制御する規則が必要だと捉えた。受付を欠いた優先制御は、混雑の場所と被害者を変えるだけになり得る。

Integrated Services では、アプリケーションが予想トラフィックを示し、経路上の資源を求める。受け入れられた予約について、各要素は経路、分類、メータ、スケジューラに関わる状態を保つ。要求と判断の対応は明瞭だった。

しかし、その明瞭さは予約数に比例する負担を生む。高速なコアほど多数のフローが集中するため、一件ごとの状態と処理は厳しい。

Differentiated Services は、境界で分類と調整を行い、内部では少数の振る舞い集約を扱う。個々のアプリとの会話をコアが記憶しないから拡張できる。

その代わり、ネットワークが要求を満たせなくても、アプリケーションへ通知する義務はなかった。アプリは、遅延や損失を観察し、サービスが来なかったことを自分で推定する。沈黙は拒否ではない。拒否なら動作を変えられるが、沈黙は原因さえ特定できない。

境界には二つの背後があった

RFC 2990 は DiffServ を境界中心の運用モデルと表現した。境界は利用資格を調べ、分類し、整形し、集約へ入れる。内部は簡潔な状態で転送する。

ところが、境界の内側にある資源状況を境界自身がどう知るかは定義されていなかった。静的に見積もった容量は、障害や経路変更で古くなる。それでも境界が受付を続ければ、約束の根拠が消える。

さらに境界の外側、すなわち要求元アプリケーションへの応答も定義されていない。必要だったのは一本の万能信号ではなく、二つの異なる伝達だった。

  • コアから境界へ、現在の集約が受けられる負荷を伝える。
  • 境界からアプリへ、要求が受理・縮退・拒否されたことを伝える。

資源情報は判断材料であって受付そのものではない。受付は方針決定であって配送結果ではない。証拠の境界を保つことが制御ループの前提だった。

サービスを探す経路

IntServ も DiffServ も、通常はベストエフォートのルーティングが選んだ経路を利用した。段階導入では、ある経路だけが特定サービスに対応し、別の経路は対応しないことがある。最小メトリックの経路が、要求品質に最適とは限らない。

RFC 2990 は、候補経路を調べ、特定のサービスプロファイルを支えられるか問う堅牢な仕組みがないとした。印を付けることは発見ではない。既に選ばれた経路で予約することも、他の経路の可能性を調べたことにはならない。

ここで必要な品質メトリックは空き容量だけではなかった。低優先トラフィックを別経路へ移すことも含め、「ある品質で追加負荷を運べる潜在力」を測るという発想だった。この潜在力には、誰を移動させるかという運用方針が埋め込まれる。

経路発見、経路選択、資源受付は別の決定である。

ACK が示した往復の現実

TCP は、サービスが片道で完結しないことを示す。送信側は戻ってくる ACK を使って次のデータ送信を調節する。データだけを優遇し、ACK を別の扱いにすれば、最終的なスループットは両方向の組み合わせで決まる。

ACK のジッターは複数の確認を圧縮し、データのバーストを誘発する。そのバーストが優遇クラスの容量を再び圧迫する。対称なサービスを使うとしても、誰が逆方向を要求し、二方向の利用をどう重複なく数えるかが残る。

一つのキューの観測だけでは、アプリケーションの体験を説明できなかった。

高い料金には別の測定が要る

RFC 2990 は、受付のための資源測定と、配送後のサービス測定を区別した。前者は「追加できるか」を判断する。後者は「仕様どおり届いたか」を検証する。

事業者はサービス主張を客観的に裏づける必要がある。顧客は追加費用がアプリ性能の改善を生んだか確認したい。設定画面、クラス印、予約成功は、配送測定の代わりではない。

文書は、プレミアムサービスが追加料金を伴う可能性を認めた。価格は追加資源の費用を配分し、需要を抑える。しかし、利用を特定顧客へ結びつける QoS 会計モデルも、そのデータ収集方法も定義されていないとした。

権利、要求、受付、資源配分、配送観測、利用帰属、料金規則、請求は一続きだが、同じ出来事ではない。

集約領域を一つの要素として扱う

RFC 2998 は、IntServ の経路内に DiffServ 領域を組み込む枠組みを示した。アプリケーションは RSVP で要求し、境界は個別フローを互換性のある集約へ対応づける。内部は逐流状態を避け、外側はアプリケーションとの対話を保つ。

境界は、個別要求と集約容量という二つの世界を翻訳する。容量が固定なら設定値で管理できる。動的ならコアからの信号が要る。そして DiffServ 領域で受付に失敗したなら、RSVP を介してアプリへ返し、要求変更または終了を可能にしなければならない。

成功時のマッピングだけでは翻訳は半分だった。失敗を実行可能な回答へ変える責任が、精度と規模を接続した。

一つに統一しない設計

RFC 2990 は、単一の差別化技術が全 Internet に広がる可能性を低いと見た。異なる小規模展開と橋渡しが残るなら、能力発見、サービス呼出し、結果計測はいずれも不可欠になる。

結論は勝者を選ばなかった。規模が重要なコアでは集約を使い、精度を維持できるエッジでは逐流要素を使う。必要なのは、複数の仕組みが安定して協調する最小の接続面だった。

Lu Heng の最小初期仕様という視点では、共通層は要求、容量、判断、結果を交換するために十分なものに限られる。各運用者の将来の資源配分まで中央で決める必要はない。しかしローカルな決定は、依存する相手へ結果を返さなければ、相互運用可能な権限にならない。

現実の層も分ける必要がある。クラス印は要求、受付は判断、容量は条件、キュー処理は動作、アプリ性能は結果、測定は証言、会計は帰属、請求は商取引である。稼働コードが、この間をつなぐ記録を出す。

RFC 2990 が見つけた空白は、ネットワークが拒否できることではない。拒否を返さずに済んだことだった。

情報源