間違いだらけのネットワーク作り(39)  98/08/22
「IPのQoS(続き)」
 

先週につづき、IP over FR/ATMでのOLTP(オンライントランザクション処理)とFTP間でのQoS制御をどうすれば良いか、という話題です。
何人かの人からのアイデアは次のとおりです。

@サーバー上のミドルウェアの機能による方法
あるミドルウェアではOLTPとFTPが同一PVC上を流れるとき、FTPがOLTPを圧迫しないようにFTPのスループットの上限を設定できるとのこと。
つまり、ネットワーク側のQoS制御にたよらず,不完全ではあるがアプリケーションが面倒を見るということです。
この方法が不満なのはOLTPのトラヒックがなく、回線が空いていてもFTPのスループットは制限されることです。

AQoSなんて気にしない方法
これが現実には一番多いようです。OLTPとFTPが同一PVC上を流れてもPVCに充分な帯域を割り当てているため、FTPがOLTPを圧迫することはない、というものです。

Bプロキシサーバによる方法
LANとATM交換機の間にプロキシを置き、LAN上のアプリケーションはQoSを意識しないが、プロキシがFTP等のアプリケーションを識別し、それにふさわしいQoSをATMに要求してコネクションを張る、という方法。Packet Shaper(詳しい内容は知りませんが)はこれに近い機能なのでしょうか?
この方法の欠点はプロキシの能力にスループットが制約されること。プロキシという余分なハード/ソフトが必要なこと。

CルータのQoSによる方法
RSVPが候補になりますが、Windows等からRSVPをキックする仕組みをアプリに組み込む必要があります。実験した人の話では結構大変そうです。

DIPng(次世代TCP/IP)による方法
次世代IPはIPの世界でのQoSを持っていますが、システムやルータへの実装などまだ先でしょう。

ということで、なかなか決めてがないようです。

p.s. ATM国際セミナーが9月17日東京で開かれます。
 http://www.atmjig.or.jp/t4f-smnr.html
 

 
 

ホームページへ