間違いだらけのネットワーク作り(117) 2000/02/26
「VoIP&VoFR&Webキャッシュ・サーバ」

今日は土曜研究会です。 この記事を書いてから出かけます。 時間がないから、というわけではないのですが、今週は読者の方から皆さんにフィードバックする価値のあるメールをいくつか頂きましたのでご紹介します。 最初のは先週のVoIPの記事で、わずか9拠点にVoIPを導入するのに本社にルータを10台以上も並べる理由が分からない、と書きましたが、それに対する回答です。 この企業の方は研究会の会員ではありませんが、毎週読んでくれているのですね。

2つめは入会申し込みのメールからの引用です。 VoPがうまくいかない、という話はなかなか流通しないものです。 ベンダーから高い広告収入を得ているマスコミはVoPの悪口なんか書きませんし、実際にVoPを導入している当事者は失敗を認めたりしません。 いわば「裸の王様」的状況があるわけです。 この方はVoFRが国際FR上でうまくいかないことを率直に述べておられるので、感動しました。

3つめは今日の「ポリシー・ベース・ネットワーキング」の講師でもある、NTT−PCの波多さんから、WEBキャッシュサーバについて私が間違った理解をしているのを指摘し、かつキャッシュ・サーバの問題点を説明してくれたものです。 実際にISPとしてネットワーク管理をされているだけあって、説得力がありますね。

以下、*印のあとは私のコメント、それ以外は引用です。 今後も皆さんから「現場感覚あふれる」貴重な情報をいただければと思います。

○何故、9拠点のスター状VoIPネットで中心にルータを10台以上も並べるのか?

 松田様のHP上での疑問にお答えします。
 

 導入時点でHuntGroupとGatekeeperの動作が確認できていなかったため、 (その後に他拠点でのVoIP化に使う予定の)VoIPルータをPeerで接続し たためです。そのため9拠点に対して約同数のルータをHUB拠点に設置 していました。

すでにHuntGroupとGatekeeperの動作を確認済ですので、ずらりと (一時的に)並べたVoIPルータは3台(もしくは2台)に集約されます。  すでに本日も一部の移行作業を無事終えております。 ずらりと並んでい たVoIPルータは今後の展開で拠点側に移設して使用しますので資源的に は無駄になりません。

また回線帯域に1.5M必要なのは、音声以外のIPトラフィックから必要な のでそのようになっています。音声以外で1.5Mの40〜50%くらいを使用 しています。また、あまり設定内容についての細かい議論は避けますが、 ご指摘の通りヘッダ圧縮とフラグメントに関しては必要ありませんので 現在は行っていません。

*低速回線での拠点の収容は来年度の予定だそうです。  ヘッダ圧縮やフラグメントが不可欠な低速部分と、不要な基幹部分がうまくインターワークできるのか興味があります。 それにしてもVoIPルータの開発にあわせてネットワークを組替えつつ、移行するのは大変ですね。 VoIPルータが規模の大きなネットワークでも使える、ちゃんとした製品になった段階で導入するか、VoFRなりVoATMなら簡単に手間と時間をかけずに移行できると思うのですが。

○国際FR網でのVoFR

松田様

はじめまして。  Y@国際通信事業者と申します。 私も国際でVoFRを中心に設計構築に携わるものですが、最近音とぎれ等の問題に多く直面し、VoFR(公衆FR)というものの限界について考えさせられる日々を送っております。

A社とB社のFRADを取り扱っているのですが、国際FRは揺らぎが大きくなりがちで、揺らぎバッファの限界値までの設定を余儀なくされている状況です。

*公衆FRをVoFRで使うべきではない、というのは私の持論ですが、 Vo公衆FRが悪いと率直にいう方はいません。  自分のやっていることを否定することになりますから、機器ベンダーはもちろん、採用したエンドユーザも問題ないとしか言わないのです。   

公衆FRはとりあえずCIRという帯域保証はあります。 それでも問題がでるのですから、いわんやVoIPをや。 RSVPで帯域だけ確保したところで規模が大きく、ゆらぎが生じやすいネットワークでは音質確保が大変なのは想像に難くありません。
 
 

○Webキャッシュ・サーバの功罪

松田さま

NTTPCの波多です。  間違いだらけのネットワーク作り(111) 2000/01/15で、WEBキャッシュサーバのことをトラフィックサーバとおっしゃっていますが、厳密には、トラフィックサーバとは、Inktomi社の製品名です。  NVC社以外にも、アダムネット、NTTソフトウェアなどが代理店をしています。  一般名詞はWebCacheサーバだと思います。TrafficServerはその機能を実現するソフトウェアであり、もうひとつの雄であるCacheFlowは専用ハードウェアで実現します。

プライベートネットワークではどうかわかりませんが、私はパブリックなネットワークにトランスペアレントキャッシュを入れるのは相当抵抗があります。  理由は以下のとおりです。(以下キャッシュは、エンドユーザ端末内キャッシュではなく、ネットワーク内キャッシュのことです)

・Webコンテンツの著作権者に無断でコピーを保持し、第三者に配布してよいのか

 音楽コンテンツなどには以下のようなただし書きがついていることが良くあります。   "各音楽作品を権利者の許可なく無断で、複製・転載・再配布・放送・上演等することを禁じます。"   これはキャッシュするなという意味を含んでいるのでしょうか。   また、IBMなどのハードウェアベンダは、自社製品のデバイスドライバを無償ダウンロード 可能にしています。  しかし、そのファイル添付されている配布条件は、 他のネットワークへの転載を禁じています。  例えば ftp://ftp.ibm.co.jp/pub/pccsvc/aptiva/bkren05/readme.txt
 キャッシュはこれに該当しないと誰が保証してくれるのでしょうか。   (いまのところ、問題はないと言ってくれるのは製品代理店のセールスマンだけです)

・コンテンツ要求者は、米国サイトにあるコンテンツを要求しているのに、 無断でコピーを渡してよいのか。

お客様から、「米国からのトラフィックを買っている のに、国内でキャッシュしたものを配信するな」と苦情があっても、我々は 「内容が同じならいいじゃないですか」とお応えしてよい根拠を持っているのでしょうか。

・コンテンツ製作者がキャッシュをための標準的手段がない
 (HTTPのメタヘッダにNocaheというのがあるが、誰がこれを見てくれるのかわからない)

・本物とキャッシュの内容の同期にわずかながらも時間差が生じ、要求者に古いコンテンツ を渡してしまう可能性がある。
・要求IPパケットの発IPアドレスを元にアクセス制限をかけているサーバには、 セキュリティホールを生み出す可能性がある。
・本物サーバ側にアクセスログが残らないので、製作者が真のヒット数をカウントできない。
・本物サーバ側にアクセスログが残っても、Cacheサーバのアドレスなので、どこの誰がコンテンツを要求してきたのかわからない。

私自身は、トランスペアレントキャッシュはかなり問題点を抱えていると認識しています。
 
 
 
 
 

ホームページへ