■ キューイング

ネット君。ルータの動作はもちろん知っていると思うが？

え？ ルーティングでしょ？

いやまぁ、確かにルーティングだが。それはBSCIの範囲だからな。
そうだな、パケットを受け取る・受け取った場合のルータの動作だ。

あ〜、入力インタフェースからパケットを受け取って。ルーティングして。
でもってルーティングで決定された出力インタフェースから送信？

そうだ。その際、出力インタフェースでは一度パケットをバッファしてから、送信することになる。

細かく言えば、入力、出力時にACLが入ったり、出力前にL2ヘッダの付け替えがあったりするが、基本的にはこの流れだ。

入力→ルーティング→（バッファ）→出力、ですね。

で、だ。このバッファだが。なんの為に必要なのかね？

なんのために、と言われても。

ルーティングし、出力インタフェースへパケットがスイッチングされたら、すぐ送信すればいいではないか。なんでバッファするのかね？ 逆に言えば、すぐ送信できない事情があるのかね？

すぐ送信できない事情…、あぁ、ありますあります。
イーサネットのCDによる待機とか、全二重イーサネットのPauseとか、WANだと輻輳とか。

そうだ。送信できない場合、バッファにたまっていくわけだな。
つまり、バッファに列ができることになる。送信待ちの行列だな。

あ〜、いやだいやだ。「待ち行列」なんて言葉は聞きたくないです。

M/M/1の待ち行列理論の話ではなくてだな。まぁ、M/M/sとか言われると帰ってくれといいたくなるが。
ともかく、バッファにたまった場合、パケットをどの順番で送り出すかということがポイントになる。

んん？ 列で並んでるんだから、入ってきた順じゃないんですか？

まぁ、基本はそれだ。FIFOと呼ばれるアルゴリズムだな

ふぁーすといんふぁーすとあうと。最初に入ってきたものから出て行く、でしたよね。

そういうことだ。このFIFO方式、つまりキューイングが出力インタフェースでのバッファの基本なわけだ。

くえうえ〜。

帰れ。

はぅっ。
Queueって「くえうえ〜」って感じじゃないですか？

どんな感じだ、それは。
ともかく、ここから来てるのかどうかは知らんが、出力バッファのことを「キュー」、バッファでの待ち行列の処理のことを「キューイング」と呼ぶ。

ん〜、バッファがきゅ〜。処理がきゅ〜いんぐ。

「〜」で言うな。「キュー」と呼べ、「キュー」と。
何処のゴマフアザラシだ、君は。

きゅ〜。

■ キューイングの種類

さて、基本はFIFOなのが、キューイングだが。
これには問題がある。

え？ いいじゃないですか、先入れ先出し。シンプルだし、競争原理にも則ってますよ？

別にネットワーク上のパケットに競争原理はいらん。
例えば、FTPによるファイル転送のような「重い」トラフィックと、Telnet・DNSのような「軽い」トラフィックが混在した場合。

データ量ですか？ 重いと軽いは？

そうだ。そうなると、通常のFIFOではTelnet・DNSトラフィックが遅延する可能性が高い。

まぁ、FTPのようなアプリケーションが送り出す一連の連続データフローをパケットトレインなどと呼ぶのだが。
こうなると、特に出力側が低速WAN回線などではキツイわけだな。

ぱけっととれいん…パケット列車。
何がキツイんですか？

Telnetのレスポンスが極端に悪化する。本来なら輻輳を引き起こすほどではないTelnetが、FTPが前に入ることによって輻輳の影響を受けてしまうわけだ。

FTPのファイル転送待ちになっちゃうわけですね。そうなると確かに遅く感じるなぁ。

さらに、レスポンス勝負のトラフィックの場合は、応答の悪化が致命的にもなりうる。
ビデオ会議や、VoIP、リアルタイムストリーミングなどだ。

確かに。ビデオ会議で遅延発生すると、じれったいですからね。

そのために、特定のトラフィックに対し一定の帯域を保障するわけだ。
これをQoSと呼ぶ。

くおりてぃおぶさーびす。
帯域を保障する？

うむ。この場合、ビデオ会議などのトラフィックを優先して、FTPなどのトラフィックの前にキューから送り出すことにより、帯域が保障されるわけだな。

ほぇ〜、VIP待遇なんですね。

これがQoSの方式の１つであるDiffServの「キューイング」と呼ばれる方式だ。
今回からはこの「キューイング」を説明していく。

「の1つ」ってことは、他にもあるんですか？

ある。IntServなどがそうだ。
それはまぁ、機会があれば。

ははぁ。

さてさて、このキューイングだが。
説明するのは以下のものだ。

FIFOは説明済みだからよいとして、あと4つだな。

あぅぅぅぅ。

どうした？

未知の世界が広がっています。

■ WFQ

ではまず、ネット君の未知の世界の1つ、WFQからだな。

うぇいてっどふぇあきゅーいんぐ？

「重み付け均等化キューイング」かな、訳としては。
あぁ、言い忘れていた。これらのキューイングは輻輳が起きる可能性のあるインタフェースでのみ実装される。

え？ 何故です？

輻輳が起きないんだったら、バッファに溜まらないだろう？
あぁ、LANのイーサネットの待機というのもあるが。

さっき言ったバッファがいる理由のあるインタフェースで実装、ってことですね。

そういうことだ。では、WFQ。
WFQはパケットトレインを分割し、トラフィックに公平に帯域を割り振る方式だ。

トラフィックに公平に…、だから「Fair Queueing」なんですか？

そういうことだな。WFQはE1(2.048Mbps)以下のWANではデフォルトで使用される。
どちらかといえば、低速回線向きのキューイングだ。

そうなんですか？

うむ、正直言ってWFQでは大帯域では対応しきれないし、調整機能も甘い。なので、新機能としてCBWFQがあるわけだ。

へ〜。じゃあWFQは古いんですね。

まぁ、古いといえば古いな。それはともかくとしてWFQの説明をしよう。
先ほど言ったとおり、トレインを分割し、公平にキューイングを行う。

公平に、ですね。

まぁ、高ボリュームトラフィックより低ボリュームトラフィックの方が優先されるが。
まず、以下の項目でトラフィックをフローに分割する。

で、このフローの中から低/高ボリュームを認識し、IPヘッダのToSやパケット長などから優先するパケットを決定する。

IPヘッダのToSと、パケット長…。

うむ。実際の処理だが。こうなる。

ほぇ〜、低ボリュームは優先、高ボリュームは均等、ですか。

そうなるわけだ。これにより、低ボリュームは優先されて帯域を消費し、残りの帯域を高ボリュームが均等かデータ量の応じて使用することになるわけだ。

なるほどです。

このWFQを実装するのはすごく簡単だ。

輻輳しきい値はオプションだ。あってもなくてもいい。

あるとどうなるんです？

輻輳しきい値はデフォルトで64だ。キュー内のメッセージが64を超えた場合、それ以上の高ボリュームトラフィックを着信しても破棄する。

ははぁ、輻輳制御の一環ですね。

まぁ、そうだな。
このように、WFQはトラフィックの中でも多い低ボリュームトラフィックを優先的に制御することにより、応答時間を制御してるわけだ。

なるほどなるほど。

ただし、あくまでのWFQは低速回線用で、フローが多くなると対応しきれなくなる。
優先順位付けが単純すぎて、追いつかなくなるんだな。

ん〜〜〜、つまり、アレですか？ みんな同じ優先度になっちゃったり？

または、さらにその中でも優先したいパケットがあったりする場合もあるわけだ。
よって、拡張版のCBWFQがあるわけだ。

ははぁ、拡張。

ま、それは次回だな。

いぇっさ〜。
30分間ネットワーキングでした〜♪