問題: リソースの割り当て

これまでにネットワークプロトコルの階層を十分詳しく見てきたので、アプリケーションプロセスが不均一なネットワークを通じてどのようにデータを転送するかは理解できたことだろう。続いてプロトコルスタック全体に関係する問題に焦点を当てる ── 互いに協力関係に無い多くユーザーに対してリソースを効率的かつ公平に割り当てるにはどうすればいいだろうか？ 共有されるリソースにはリンクの帯域、ルーターのバッファ、あるいはスイッチでパケットが転送を待つ間に格納されるキューなどがある。例えばルーターに到着したパケットはリンクの利用権を誰よりも早く受け取ることを望み、ルーターは受け取ったパケットを特定のリンク越しの転送を待機するパケットを取り置くキューに配置する。あまりにも多くのパケットが同じリンクに殺到するとキューが満杯になり、望ましくない二つのことが起きる: パケットが経験するエンドツーエンドの遅延が大きくなり、キューがオーバーフローする最悪のケースではパケットが破棄される。長いキューがいつまでたっても解消されず、パケットの破棄が頻繁に起こる状況を輻輳ふくそう (congestion) と呼ぶ。多くのネットワークはこういった状況に対処する輻輳制御 (congestion-control) の仕組みを提供する。

輻輳制御とリソース割り当ては同じコインの裏と表と言える。一方では、ネットワークがリソース割り当てに積極的に関与すれば ── 例えば、仮想回線が特定の時間帯に利用する物理リンクを完全にスケジュールすれば ── 輻輳はおそらく避けられるので、輻輳制御は必要なくなるだろう。しかしネットワークリソースの割り当てを正確に行うのは難しい: 考えている「リソース」はネットワーク中に分散されており、いくつものルーターを結ぶ複数のリンクに関するスケジュールを立てなければならない。もう一方では、パケットの送信元に望むだけのデータを送信させて、輻輳が起こったら回復処置を行わせることもできる。このアプローチは簡単であるものの、輻輳が起こってから解決されるまでの間に大量のパケットが破棄されるので無駄が大きい。さらに言えば、競合するユーザーに対するリソース割り当てが最も切実に必要とされるのはネットワークで輻輳が発生する ── 需要に対してリソースが足りなくなる ── まさにそのときである。大まかな割り当てを行う中間のアプローチも考えられるものの、その場合でも輻輳が起こったときは回復処置が必要になる。そういった中間のアプローチを輻輳制御と呼ぶかリソース割り当てと呼ぶかはあまり重要ではない。ある意味で両方とも言える。

輻輳制御とリソース割り当ての問題にはホストに加えてルーターをはじめとしたネットワークの構成要素も関係する。ネットワークの構成要素の内部には、パケットが転送される順番とパケットの破棄される順番を決定する様々な順番待ち規則が存在する。適切な規則を定めれば、あるユーザーのパケットが不当に他のユーザーのパケットに影響を与えないようにトラフィックの分離を行うこともできる。エンドホストでは、送信元がパケットを送信する速度が輻輳制御の仕組みによって調整される。この調整は輻輳がそもそも起こらないように、そして輻輳が万一起きたときに早く解消できるようにするために行われる。

本章は輻輳制御とリソース割り当てという問題の概観 (第 6.1 節) から始まる。その後はネットワーク内のルーターで実装される可能性のある順番待ち規則をいくつか議論 (第 6.2 節) し、続いてホストの TCP が提供する輻輳制御アルゴリズムを説明 (第 6.3 節) する。第 6.4 節では輻輳を問題になる前に解決するためにルーターとホストが利用する様々なテクニックを紹介する。最後に第 6.5 節では QoS (quality of service) という奥が深い話題に触れる。アプリケーションが異なるレベルのリソース割り当てを必要とする理由や、そういった割り当てをホストがリクエストする方法、そしてネットワークがそういったリクエストに応える方法を説明する。