------------------------------------------------------------------- プレゼンテーション名:ISPサービスとしてのIP QoS現状とこれから 〜運用・実装の実際と今後〜 時間:2002/1/25 10:00 - 11:30 発表者:NTT-COM:池尻 Cisco :河野 HITACHI:阪田 IIJ :渡辺 JT :松嶋 記録者:BBX 小木曽・富岡 ------------------------------------------------------------------- 運用と実際から見てみるパネルセッション。 (池尻) IPサービスとしてのIPQoS ISPでは、本当に必要か?よく話が出る。 ISPでは実際に使用されていて、QoSをサービスとして提供している ユーザ向けに実際に運用。 実際、どこまで行われているか?   現在のトレンド   シェーピング回線容量などのコスト節約 たとえば1Gを10Mに絞った使用など アプリケーション品質は確保して欲しい 現実と今後の展望 DiffSer・クラス分類・クラス単位QoSと定義する Ipと例やQoSのマッピングは排除 IPv6は排除 ISPとすれば、Layer3に依存した使い方 実際と今後の議論のポイント どのような技術が使われているか? ISPはルータしか見れないが、実装はどこまでできているか? エッジ、コアのどこでQoSする? エッジ側でまず制御しコアはなにもしない。そして出口のエッジで制御する 128K1500Byteのパケットを投げたら93msかかる Voiceは200msでおさえたいが、パケットが割り込まれると遅延が発生し使えなくなる さらに進んでコアにも制御をさせる 真中で何ができる? RSVPにてフローごとにできる?   マイクロフローへのRSVPによるQoSシグナリングは論外。ISPは大変 (松島) IP-VPNにおけるIP QoS 1.IP-VPNでのQoSサービス JTでも実際にサービスしている どんな要求があるのか? 何を持ってQoSと言う? お客様の背景なども考慮 IP-VPNは閉じられた世界なので、やりやすい面もある 同じ拠点間で子特定のトラフィックを優先させて欲しい 帯域保証型 何が何でも優先クラス:アプリケーション音声などを使われる場合 帯域制限のクラス:Webブラウジングくだらないトラフィックをしぼる QoSの粒度について 特定のトラフィックに適用 ・特定サイトの間のQoS ・特定のトラヒックフロー ・src/des addr ・Src/des TCP/UDP Port 特定サイト間のそれだけの帯域を確保しなくてはならなくなった場合、設定が複雑になる   Qosクラスについて どのような技術を持ってサービスを提供するか? P5は早だしP4は守られるP0は低い 現在サービスされているqosクラス ・それぞれのクラスはIP Precedenceの値で識別される ・特定サイト間・・・検討中 IP Precedence値と各Qosクラスの対応 各クラスのためのキュースケジューリングテクニック ・求める用件は満たされている。 3IP-VPN QoSの実際  現状のIP-VPN QoS機能配置  ・IP-VPNの出口で設定 ・出口回線の帯域はお客さまに依存  IPVPNバックボーン  ・IPVPNとインターネットバックボーンは分けて使用  ・MPLSとうまく共存できるのではないか?  現状のQOSの問題点  ・パフォーマンスの維持にかかわる問題 維持していることの説明をどうするか  対策  ・間接的なアプローチ 定量的に把握する必要有り 実機で測定を続ける 理論値と実際値を把握する必要有り(重要) あくまで理論値と通りにはならない。     対策の実行 (渡辺) JANOG9カルトQ準優勝者 QoS Serviceの実際と課題  Qos利用例・問題  ・QoS技術の実例  ・Qos技術に対する要求   品質確保にはあまり使われていない  ・問題 測定品質MRTGでリンクが埋まっていないか遅延が起きてないか アプリケーションに依存 本来のネットワークの品質確保では使われていないのが実際のところ装置の 負荷を見ていないといけない オペレータが緊張(苦労)する ルータのCPU的に安定してるかどうかなどの問題もあるのが現状。    例1 8MメニューをEtherで実現するにはQoSが必要 0.6S間に何が起きているか再送が14回起きている 再送間隔がながくなっている シェーピングは綺麗に並んでいる FTP100ホストインターネットは何台端末があるか不明 応答時間にばらつきが発生する 1000ホストではTCPが切れてしまう。 シェーピングはみんなが同じでデータ転送を終わらせる なぜレートリミットは駄目なのか? TCPのシーケンスをたどった図により説明 人によって代わる レートリミットの例でした  例2 FTPサーバクライアントでどれぐらいのスループットが出るかの 検討125kで再送が起きて 水色の線 1.5Gでちゃんとでるが1.2Gは最初はCBWFQかけてでる Case by Caseでかわる インターネットは早い者勝ちだとリンクをふやしていく? バッファキューの設定が大変大きくても小さくても駄目 どの辺が抑えどころか難しい 有限個のクラスにアグリゲートする、アプリケーションは無限で判断できない TOSはだれが打つ物? パブリックではIngressを定義できない  まとめ ・Internet QOS難しい  ・(Cont)  ・Diffserv/RSVP etc   エッジのところでできる制御 結論 エッジのHOPで制御を続けていく HTTPなどのアプリケーションを追いかけていきベストソリューションを見つける。 (阪田) 作る側からのお話(エッジでのQoSの適用) IPSエッジにおけるIPQOSの実装状況と今後について ISPネットワーク Queingについて話す どのような物が実装されているか今後何が必要になってくるかQueuingにフォーカス エッジの出口で輻輳を想定して話す ポリシングは廃棄制御マーキングに連動 ハードでやってるかソフトでやってるか 入力エッジでの制御 廃棄制御・・・廃棄されやすいものとされにくいものを作る   出力エッジでの制御 キューイング方式   優先制御(PQ)      WFQ      PQ+WFQ   最大帯域制限付きPQ+WFQ      帯域制御 GFR(ATM用語):MFRを開放する動作      現状エッジでの実装    キュー数    キューイング方式   なぜ多キューが必要か1      なぜ多キューが必要か2      なぜ多キューが必要か3      今後のキューイング方式 1000QoSが登場してきたのだろう? 1キューで複数ユーザを収容すると期待値が出ない よって各ユーザごとにキューが必要   今後のキューイング方式 例1:会社編      今後のキューイング方式 例2:個人編   今後の高速化に対する課題    2.たくさんの箇所に集まったとき、まるべくトラヒックを落とさないように HITACHIからの提案 2段階の多キューをサポートしなくてはいけないのではないか? どこにトラフィックがあってそこを優先的に(帯域があるときは)使う キューごとに閾値を持つ 今後の高速化に対する課題 多点から1点に集まってくるのでおおきなバッファを持っていた ほうが良い帯域割り当ての再計算演算をどう高速にするか (河野) 作る側からのお話(Ciscoからの話) IPバックボーンにおけるQoSの適用 例えば、ルータのフォワーディング能力は早ければ早いほど良いが、QoSに 関しては、トラフィック特性(遅延、廃棄、遅延揺らぎ)がそれぞれトレード オフの関係にあるため、バッファは多ければ多いほど良い、というようには 割り切れない。   ATMでは当たり前のQOS制御... 2つの条件に適合されると必要と考える QoSが必要になるのは、複数の異なるトラフィック特性が混在し、かつリソース に競合が発生しうる時のみ。 ATMのQoSとルータのQoSの違いを説明 ホップごとの振る舞い(behavior)は同じ CACは最初から帯域が確保できないのであればコネクションしない VS/VDクローズドループでキューイングの処理を見ながら動作 ユーザQOSとバックボーンQoSは個別に動いている カスタマーごとに同じアプリケーションでもプライオリティが異なる バックボーンでは混乱 Ether-ATM-Etherのネットワーク ATMを目指せばよい? Cisco→No MPLSをIPQoSを合わせる MPLSQoSTunneling 拡張の提案 Uniform Mode(デフォルトの動作) Short Pipe Mode(QoS Tunnel) Egressの動作までTunnelが規定しない場合は、Short Pipe Modeと呼ぶ。 ->c.f. Pipe Mode Pipe Mode(QoS Tunnel) IPバックボーンQoSを提供する基盤としてのMPLS 結論 あまり精度に走ってしまうといけないので中間点が必要 高速・拡張性を保つ (池尻) ひとつはQoSの利用と言うことで、ISPからの問題点 2番目は設計からIP-VPN、パブリックは違うかな? パブリックインターネットは異なるトラフィックがくるのでマッピング など難しい エッジのところで高速なところはユーザごとにQoSができないか バックボーンで同じことはできないアグリゲートできないか ユーザQoSを分けてあげると・・・ リンクできていないところがある 最初の問題に上がったQoSの問題 オペレータが見ることのできる実装を頑張って欲しい 上記に関するベンダーさんからの意見 作る方からは難しいが機能は必要と考える どのように実装するか考える ベンダーさんからツールについて (阪田) 難しいが必要なもの。SLAの観点からも必要。キューに割当てた帯域と 最大キュー長を覚えておき遅延を計算すようなしかけが必要 (河野) どこまでするかを考える必要有りMIBから始める QoSはパフォーマンスが下がるため、ハードで実装 (松島) QOSはいまのるーただとパフォーマンスが下がるかも ハードでサービスの性能が落ちないならば (渡辺) 一歩先を行ってカスタマーがわかるよう・・。 QoSのコマンドは難しい 最大公約数をしてしますとユーザによっては困る みんな同じような形にしたい(ジレンマ) IP-VPNとパブリックインターネットは違う お客さんの言うQoSとネットワークのQoSをマージしていく ToSの数などお客さんにはQoSをうれしく使って欲しい (池尻) ISP QoSとユーザQoS Posの数、BBのアグリゲートについて (松島) クラスはたくさんあればよいが、契約してもらったのに対し、どうして欲しいかなど、 ユーザに開放して割り振りを考える (渡辺) クラスは多いほうが良い、インターネットToSは誰が打つか・・・。まとめるのが難しい (阪田) クラスは4から上まで限りなくあるので是非ヒアリングしたい (河野) 多ければ良い、というものではなく、ある程度限定した方が良いと思う。 (池尻) まとめ: 運用面などで難しい面が残っている。 それを広げるとISPをまたがってQoSが出てくるがどのようにアグリゲーション していくか・・・? スケーラビリティを確保していくこと。 Q&A e-Accsess Q:現実的にこすとが安くなっている状況で、そういう技術ができてもサポートが可能か? Q:個人のトラヒックが圧倒的で昔と逆転している。個人のトラヒックを落とすことに   意味があるのではないか。  -このあたりの融合をどうするか検討が必要 Q:キューイングコントロールは?  -ゲームユーザは廃棄してしまうとクレームがすごい  -チケット予約など集中する自体が発生した場合、キューイングコントロールの  -融合性がコンシューマには必要 A : サーバ系やPublicインターネット関連は、おいしいネットワーク〜でも関係してく るので、そこでも続きが議論できると思います。 以上