間違いだらけのネットワーク作り(141) 2000/08/19
「Window制御方式とQueuing制御方式」

ここ2回ほど、IP−VPNへの辛口の記事を掲載しました。 情報化研究会にはNTTコミュニケーションの方も日本テレコムの方もかなりいるのですが、残念ながら異論や反論が返ってきません。 ツマラないですね。 議論が深まらなくて。  そこで、匿名性を保って、どなたでも異論・反論が書き込めるよう「ネットワーク掲示板」をホームページに設置しました。 私が一番ほしい情報は記事に対するコメントではなく、皆さんが現場で直面している問題やニーズです。 問題や疑問を書き込めば、私に分からないことでも、どなたかが答えてくれるかも知れません。  

自分のホームページにCGIで掲示板を置くのは面倒なだけでなく、トラブルの元になるので掲示板なんて置くものか、と思っていました。 しかし、ダカーポ8月16日号「ホームページ1週間入門講座」で無料掲示板サービスがあるのを知り、これなら人畜無害で簡単、とさっそく使うことにしました。 ダカーポは創刊から20年近くなりますが、ほぼ毎号読んでいます。 よくも面白い話題をコンパクトにまとめるもんだ、と感心しています。 ちなみに、この号のホームページ以外の特集は「なぜ、どうして関ヶ原の真実」と「このままの人生で後悔しないか?」。 「このまま・・」では転職から下半身の問題まで取り上げています。 どこまで真剣に読むかは別にして面白いです。

さて、前置きが長くなりましたが、もう一つ前置きです。 今週いただいた入会メールの中で、一番ウレシイことを書いていたSさんのを引用します。
”A社のSと申します。 今日、初めてホームページを見させていただきました。 最近、仕事が変わりQOS関係の仕事をすることになりましたが、あまり知識がなく、色々検索していてこのページに出会いました。 非常にためになり、今日一日かじりついてみていました。”

QOSはVoIPに限らず、企業ネットワークを設計する上で重要になっています。 QoS制御方式について、パケッティアの原田さんから再び詳しいメールを頂いたので紹介します。

Window制御方式とQueuing制御方式

以下、引用
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
コメントありがとうございます。

松田さまのコメントの通り、IP-VPNに関しては、専門家にコメントをお任せいたしたいと思います。

まず、誤解して頂きたくないのですが、Queuingが悪いと言っているつもりはまったくございません。 弊社のPacketShaperでもQueuingの仕組みを作ることは可能ですし、通信のタイプによってはQueuingの方が都合が良い場合もございます。 しかし、Queuingはパケットの廃棄->再送を伴います。 queueに蓄積されているパケットを廃棄しても、上位層のプロトコルによって再送されますから、通信が途絶えたりすることはありません。 この再送までの時間を稼いで、その間に、より優先度の高いパケットを流すことで高優先のueueに入る通信を確保するのがqueuingの基本的な原理です。

しかしながら、特に使用率の高い回線では、このパケット廃棄は問題になります。 一般に使用率が60%を越えると、queueの長さは2次曲線を描いて上昇することが待ち行列理論によって証明できます。 これに伴ってパケット廃棄も多発するようになって行きますから、ネットワークの効率は向上しません。 次に、この機能をルータに持たせることの是非を議論すべきでしょう。 ルータの最も重要な機能は、パケットをフォワードすることです。 ルータの性能を表すのに、PPS(Packet Per Second)という単位が使われるのは、ルータの本分がパケットをいかに高速に通過させるか、というところにあります。 しかし、QoSの仕組みをルータに持たせることで負荷が上がり、パフォーマンスが落ちるとしたら本末転倒であり、QoSを導入する意味が無くなります。

VoIPに焦点をあてたコメントのつもりでしたので、あらゆる種類のデータ伝送を考えた場合とは、観点が少し異なっていたかも知れません。 Queuingでの制御で満足できる場合もあるかも知れませんが、特にVoIPのように呼毎の制御が必要な場合、1本1本の「フロー」を認識して制御する必要性があり、これは基幹回線の通信速度に依存するものではありません。

また、ルータによるqueuingも必ずしもシンプルなソリューションとは言えません。 ルータのCPU負荷を考えると、ルーティングとQoSの仕組みを一体化するメリットは特に無く、高速回線になればなるほど、CPU負荷の増大がもたらすデメリットが大きくなることを心配すべきでしょう。

(ルータのハードウエアが高速化すれば、将来はCPU負荷も取るに足らない問題になるかも知れません。 しかし、ハードウエア技術の進歩は、PacketShaperにも同じようにメリットをもたらします。PacketShaperのようなソリューションは、1本毎のフローを制御する場合の処理能力を心配するむきもありますが、ハードウエアの進歩による将来の高速回線への対応能力は、ルータと同等かそれ以上と考えています。)
 

>*好き嫌いの話をしても仕方ないのですが、エンドシステムが設定する情報をネット
>ワークが書き換えるというのがそもそも気に入りません。 ラベルやDLCIはもと
>もとネットワークが書き換えながら使うものなのですが、Windowサイズはエン
>ドシステムが相手システムに対して「これだけ送っていいよ」と意思表示する情報で
>す。 それを書き換えるというのは変則的だと思うのです。

Windowサイズの変更についてですが、これはRFCのどこにも抵触しません。 ルール破りはしていませんから、これによって通信が阻害されることが無いことを、まず明言させて頂きます。 本来の意味でエンドツーエンドと言えば、通信を行っているホスト間のことです。 ルータレベルで行うQoSは、あくまでもルータ同士の間での処理の仕組みに過ぎず、エンドツーエンドのソリューションではありません。 この「エンドツーエンド」を実現しようと思うと、何らかの方法で通信を行うホストに制御をかけざるを得ませんが、ホスト側のシステムとかアプリケーションの変更を伴うような仕組みでは、普及は困難です。 そこで現行の仕組みの中で、エンド間の制御を行う必要があります。 Windowサイズの変更は、RFCなどのルールに抵触せず、効率的にホストにQoSの仕組みを持たせるために、最適な方法であると弊社では考えます。
 

>*QoS制御の理想形はATMのようなメカニズムではないでしょうか? エンドシ
>ステムからネットワークにQoSを明示的に要求し、ネットワークがそれを実現す
>る。 IPの世界もATMと同様のメカニズムを目指しているのではないでしょうか
>? MPLSはその手始めのように思います。 まだまだ道のりは遠そうですが。
 

確かにMPLSは理想的のように喧伝されています。しかし、ご存知の通り、現在のところMPLSはその実現可能性や導入実績という点で、現実的な解ではありません。 また、トラフィックの重要性にかかる決定をエンドシステムに任せるという事は、不要不急なソフトウエアが、ネットワークに対してね高い優先度を指定してくる可能性もあり、これを調停する仕組みが確立されない限り、導入は難しいと思います。 また、ATMの持つメカニズムは、IPの世界に適用するには大まか過ぎると考えます。 IPv6の持つ(であろう)QoSでもトラフィックを細かく識別して帯域を配分するという点で、不充分なものです。

QoSの仕組みを考える時、制御の方法だけでは無く、重要なトラフィックとそうでないものをいかにして見分けるか、という点も考慮しなければなりません。 ATMやMPLS、ルータのQueuingなどの問題点は、トラフィックの区別の仕方が大まか過ぎ、しかも将来においてトラフィック区分をより細分化するというロードマップが見えない点です。これに対してPacketShaperは、現在既に200種類以上のプロトコルやアプリケーションを識別可能で、今後も新しいプロトコルやアプリケーションに順次対応していう予定です。 ATMは元々WANの世界で考案された仕組みです。 IPはどちらかと言えばLANの世界を出発点とするもので、ATMとは異なった発展をして来ました。 将来これらは本当の意味でシームレスに繋がるようになると思いますが、現在(および現時点で見えている将来)の話しとしては、ATMのメカニズムはIPの世界の要望を吸収しきれていないように見受けられます。 てまえ味噌になってしまうかもしれませんが、結論としては、現時点で実現可能なQoSソリューションとしては、PacketShaperのような専用の装置(アプライアンスサーバ)を用いて、フロー毎に制御するタイプのQoSがベストであると考えます。

よろしくお願いします。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
*異論、反論を唱えようとするときりがないのですが、いくつかコメントします。

*Queuing方式がパケット廃棄と再送を前提としたものだ、という意味ではないですね? トラヒックの集中にたえられるだけの充分なバッファがあればいいわけですから。 

*私はATMをQOS制御に使っていこうというつもりはありません。 ATMのようにエンドシステムがQOSをネットワークに指定し、ネットワークがそれを実行する、という方式が理想ではないか、と思っているだけです。 

*重要でもないエンドシステムが過度な優先度を要求したら大変、という指摘はもっともなのですが、エンドシステム(=ユーザ)の要求をエンドシステムが知らないところでネットワーク内で勝手に変えるのはユーザとネットワークの関係として良くないと思うのです。 ネットワークはあくまでユーザ主体のものですから。

*ATMの仕組みはご存知のように、エンドシステムが帯域幅や遅延に関する通信の条件をネットワークに要求し、ネットワーク側は資源との見合いで受け入れるかどうかを判定してエンドシステムに通知します。 勝手に条件を変えたりしません。

*そもそもエンドシステムの要求が過度である場合、それをチェックし、是正するのはネットワーク自体の仕事ではなくネットワーク管理者の仕事だと思います。

*トラヒックを識別するキーがいくつ必要かは別にして、結果としての何種類のQOSが必要かというと、せいぜい4〜5種類だと思います。 ATMのサービスカテゴリーはCBR、rt−VBR、nrt−VBR、ABR、UBRと5種類ありますが、これがMAXではないでしょうか。

*パケットシェーパ−がエンドシステムやルータに手を入れず、簡単に使える現実的なツールだということは良く理解できます。 近い将来、もっとスッキリしたQoS制御ができるようになるのではないか、その方式はQueuing方式がベースではないか、と思っているだけです。
 

ホームページへ