間違いだらけのネットワーク作り(140) 2000/08/12
「IP−VPNは設計不能−その2」

先週のIP−VPNの記事に情報化研究会の3人の方からコメントをもらいました。 Kさんは短く、「最近のIP-VPNの書き込みは急所攻撃でしたね」。 まさに同感、ということでしょう。 YさんとXさんからはかなり長いコメントを貰いました。 ポイントだけ引用します。

IP−VPNは設計不能−その2

Yさん、Xさんのコメント(混在しています)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−
> 日本テレコムのSOLTERIAでも、NTTコミュニケーションのスーパー
> VPNでも、そんな帯域保証のことは一切言及していません。保証などないの
> です。これではネットワーク設計になりません。
 

  保証する項目もメカニズムもありませんね。ただ、CBQでとか、TOS
 値でとか言われても、帯域制御のメカニズムと実際の効果が一致する保証
 (証拠)もないといけません。

> 日本テレコムさん、NTTコミュニケーションズさん、IP?VPNを使った
> 真面目な設計の仕方がありましたら、是非、ホームページに公開してください。
 

  う〜ん。あるのかなぁ。
 

> NTTのArcstar21、JTのSOLTERIA、KDDIのIP-VPNでVoIPは可能か?

JTは現状ではVPN上でVoIPは無理。
NTT−CのArcster21およびスーパーVPNについてもNTT−Cは現時点では困難(無理)であると言っています。
 

>QoSへの各社の取り組みは?
JT、KDDはMPLS以外の今後の実装は不明。
ちなみにJTは網が込んだ場合に音質は悪くなる。 さらに128Kbps以上の契約帯域が必要とのこと。
 

>網内遅延はJTは往復で40msを保証、NTTは数十ms(?)

JTはEnd to End、アクセス回線速度128kでの前提です。

*これは少し数字が良すぎますね。 パケットサイズが1Kバイトとすると片方向、アクセス部分だけで100ミリ秒を超えます。 間違いだと思います。

網内遅延時間については、かなり長時間(約1ヶ月)を平均してのものと考えられます(この当たりもNTT−Cは殆ど何も詳細を語りません)。
そうであれば、想定トラヒック量(トラヒック発生パターン、平均、最繁時)と集中率をどう仮定するかによって、何とでもなる数字ではないでしょうか?

*1ヶ月平均の遅延なんて何の意味もありませんね。 ユーザが一番使いたいとき、つまりピーク時にどれだけの遅延時間なり、帯域幅が保証できるかが重要です。 日中のビジネスアワーも、夜中も、休日・平日も一緒くたにした平均では意味がありません。 現実のトラヒックはピークと通常時で数倍から10倍を超える差があります。

>公衆VPNサービス上のVoIP案件は松田さんがおっしゃるよう に現在は無理です。  「各社来年には..」と言っていますが、来年になると何が変わるというのでしょう?

う〜ん。MLPPPかFRF.12のフラグメントか? うまくいけばTOSかDiffserveを利用した優先制御機能をサポートしているかもしれません。

やはり、IP−VPNは、End〜Endの本当の遅延はどの程度か(遅延変動があるとVoIPなどは非常にまずい)は問題でしょう。

大きなキューバッファをもって、トラヒックの急激な変動を吸収してくれるようになっていると、VoIPのようなAPでは非常に困ったことになると考えます。(データは落ちないが、音声パケットの遅延が大きくなり、ゆらぎも大きくなる)

*「来年になれば」とルータ屋が言っているからキャリアも言っているだけで中身がないのでは?と疑いますね。 
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
*IP−VPNの現在のレベルは公衆フレームリレーで言えば、CIR=0でも差し支えない中小規模ユーザ向けと言えるでしょう。 公衆フレームリレーがかつてそうだったようにユーザ数が少なくてガラ空きのうちは問題なく使えるかも知れませんが。

*「次世代」などというイメージだけのキャッチフレーズに惑わされず、客観的な回線サービスの選択と設計をしたいものです。
 

ホームページへ