======================================================================== □ 美味いネットワークの実現にむけて 2001, Jan. 25 (15:30-17:10) コーディネータ(敬称略): c 関岡 利典(NTTコミュニケーションズ) パネリスト: t 高橋 政夫(株式会社Jストリーム) i 伊勢 幸一(株式会社スクウェア) s 笹木 一義(アバブネットジャパン株式会社) n 中川 郁夫(インテック ウェブアンドゲノムインフォマティックス) y 矢萩 茂樹(イーアクセス株式会社) m 南 陽(NTT コミュニケーションズ株式会社) logger1: 渡辺直樹(IIJ) logger2: 里和勇人(NTTcom) logger3: 黛　潤一（MIND） ------------------------------------------------------------------------ ■ セッション紹介 (関岡さん) □ はじめに ISPの人が多く来ている JANOG ですが、アプリケーションの立場の意見を 聞ける機会にしたい。折角沢山の方に来て頂いているので会場の意見を聞き ながら進めて行きたい。 - 美味いネットワークって何なのか? - 焦げないネットワーク(落ちないネットワーク) - 快適なネットワーク - いろんなアプリケーションが使えるネットワーク - 安いこと これらが満たせればみんなハッピーといえるのか?この辺を考えていきたい と思う。 - 例: xDSL\CATV の普及 - ネットワークは凄く速くなりました。 - でも実際みんな満足しているの? 実はユーザは手加減しているのかも知れなくて、みんなが本気で トラフィックを流したらどうなるんでしょう? この辺、みんな疑問ではないのか? - 美味いアプリって何なのか? ストリーム: スムース/大画面 ネット対戦ゲーム: 地球の裏側と通信とかみんな同時に通信できる。 TV電話: 地球の裏側と通信/みんな同時に通信できる。 - 今のネットワーク構造 サーバ@IDC | ISP1 | ISP2 | コンシューマISP | ACCESSプロバイダ この構造が問題になっているのか、正しいのか - 今のネットワークって美味しいのか? JANOG のネットワーク系の人が多いので、コンテンツ業者からのリクエスト 反映させる良い機会であると思う。 まずは、アプリケーション系に強いパネリストから意見を頂き、その後 ネットワーク系の人から意見を出すという形で進めていきたい。 尚、昨日(1/24)の懇親会での 寒ぶり生中継: 高橋さん (Jストリーム) FinalFantasy: 伊勢さん (スクウェア) に協力いただいています。 ------------------------------------------------------------------------ □ 高橋 さん(株式会社Jストリーム) - ブロードバンド時代 総務省 DSCL 普及状況の結果(2001/1/25時点) 1ユーザあたりの帯域は 64k->1.5M へ段々うつっていきている。 (帯域にして24倍、ユーザ利用率は100倍) 16000ユーザ -> 1500000ユーザ(実質100倍) 実際 ISPさんのネットワークが実際どの位増強されているのか心配である。 回線コストは落ちていない。 ストリームの配信するは、流す側(コンテンツ屋)としてISPの状況が不安。 ISP に聞くと: ISP:まだ流れていないから大丈夫 ISP:トラフィック的には大丈夫 とか返事が帰って来るのですが、コンテンツ屋の立場では、 コンテンツ: 確実にながれることが大事(ビジネス) いまだと、ブロードバンド(300K)で3万人に配信などのリクエストが多い。 300K で 3万人-> 9Gbpsになる。仕掛けなしにこのようなトラ フィックは捌けない。 実際ニーズは手前まできているので、じゃあどうやって流そうか? ということ -> ISP へのお願いとして、考えてほしい。 - （おさらい）ストリームの歴史 Real Audio 20kモデム Real Video5.0 56kモデム Real VideoG2　100〜300K WMT 7 〜500K アクセス回線の帯域に合わせて、データ通信速度が増加して行く "常に時代のインフラに挑む" のがストリーミングの特徴である。 - ストリームの現状 世界記録でさえこんなもの Apple News Macwork (Jobs のプレゼンテーション) 2時間で 11TBのデータ量 ピーク 16.5Gbit トータル 81000同時アクセス TV業界の人達と話すと、なかなかまだビジネスにはなりません と言われる(ユーザ数が少なすぎるため)。 - Streamingサービス ナローバンド 20k〜56k ブロードバンド ストリーム 300kbpsのコンテンツが一番多い。 実際アーティストサイドからは 500kbpsくらいの品質を要求される。 FTTH 時代を見据えて 1Mbps のストリームを流したいという要望もあ 　　　　 る。 現在日食イベント/春の選抜のあたりから、ブロードバンド/ナローバンド が逆転してきている。 また要求として、ストリームは長時間セッションを張りつづけるものなので 　　ネットワーク品質が安定して欲しい。 - ストリーミングのビジネスモデル コンテンツホルダ | コンテンツアグリゲータ | コンテンツデリバリ業者 | ISP/IDC | USER このモデルは広告モデルにあっている。プロモーションしたいひとが、 コンテンツデリバリ業者にお願いする。 ビジネスにするのなら、USER からお金を回収する仕組みが必要。 - ストリーミング用ネットワークを考えて キャッシュ製品の導入 1台のサーバで複数のPC(すくなくとも5,6倍以上、もっと)の替わりに 　　　　 なる。 100Mbpsであれば、1Uのサーバで回線真っ黒になるくらい流れる。 しかし、ラックスペースに 1U のキャッシュサーバだと、 金額的に無駄が多い。 - トラフィック制御/エッジサーバの配置 ユーザを多くかかえているISPがトラフィックを一番流す。 エッジサーバの配置をトラフィックの多いISPにおきたい。 問題: 著作権がらみのはなし。 ライブ系のはなしだと、見れないとユーザにおこられる。 コンテンツ屋も ISP と 運用を話しあうようにしなければならない。 - トラフィック制御/エッジサーバへの誘導 製品はどれも一長一短である。 - LDNSベース 既存のISP構成であれば、ほとんど問題ない． ADSLでホールセールを利用しているISPの場合、ADSL事業者〜ISPの間が 太くないといけないとか、いろいろ問題はある． - アドレスレンジでの制御 IPアドレスレンジの公開は、企業によってはできない。 - RTT測定ベースの製品はあまりない。 - ANYCAST だとモニターができない。 (ほんとうにきれいにはいているのか、がわからない) - MULTICAST は ISP が対応不能で、いまのところ認証不能。 (ビジネス的な欠陥) - トラフィック制御 ISP によるCashe サーバの提供 - L3,L4 での横流しモデルもある。 - まともにうごく製品がない。 - ネットワークでそんなことをすると、どこが悪いのかわからない。 - 挙動不審のISPがあります。 L3,L4 でストリーム系のトラフィックを横取りし、独自キャッシュ製品から 　　　　配信を行う。 →ストリーム系の機械の相性がわるくて、ユーザまで届かない。 　＃責任の所在が不明になるのでやめてほしい 　＃課金上の問題にもなりえるので要注意 臨時にネットワークをつくる無駄 - イベント毎にネットワークを付くって壊すのは無駄ではないか? 　最後に - ビジネスとして成り立たせなければ、ISP にお金を支払うことができない。 ちゃんと配信できることがまず大事 次に、認証:/アクセスログ、課金/回収、ユーザサポートとか ただコンテンツ配信をするだけではなく、ISPでも参加できるところは まだまだあります． ---------------------------------------------------------------------- □ 伊勢 さん (株式会社スクウェア) ゲーム業界の出身なので、プレゼン中、言葉使いが失礼なこともあるかも しれませんがあらかじめお断りします。すいません。 - ブロードバンド時代のオンラインゲーム - スクウェアは今年から本格的にオンラインゲームに取り組んでいる。 そもそもオンラインゲームというのは、ここ数年の話しではなく、 昔から存在した。それがここ数年でPCの普及がかなり高くなり、オンラ インゲームも加熱してきている。 どのくらいのスペックが必要か： アクション系: スーパーマリオ/鉄拳 対戦、シューティング (ユーザの操作がダイレクトに描画に反映するタイプ) RPG系: スクウェアがターゲットを置いている。 ウルティマオンライン、EQ、AC、FFXI など。 シミュレーション系: エンタープライズ(古い物)、StarCraft, WarCraft, 三国志 昔からの陣取りゲームに近い。 (一番最初にネットワークに対応した。TEXTベースだと 十数年前からある) 1. アクション型 ネットワークに要求されるスペックがシビアである。 ノード間通信RTT 60フレームゲーム 10msec 以内 30 フレームゲーム 30msec 以内 であってほしい。 NTSC は 15/30/60フレというものがあるが、最近のユーザは 60フレ でないとならない。RTT が 10msec 以下でないとならない。 描画がリアルタイム性をもたないと、ユーザの操作が追い付かずゲームと して成立しない。 2. RPG型 FFXIについては、バンド的にはナローにも対応できる(データ圧縮等)。 1kB〜4.5kb に圧縮しておさえている。圧倒的にモデムユーザが多いため。 サーバクライアント構造にせざるを得ない。 1秒間に4回のやりとりが必要で、 ノード間通信 RTT 200msec以下にしたい。 RPG は開発コストが違うが、 シミュレーションとRPGでネットワークに対する要求は同じ 3.オンラインRPG ゲーム FINAL FANTASY XI 2002 年春 サービス開始 --------ここでビデオのデモが入りました--------------------------- 画面を見せたい(PS2のゲーム画面と、preレンダリングをみくらべてもらいた い) preレンダリングの画面とPS2上のレンダリングが混じっている。 パーティーメンバをあつめて、あるモンスターに戦いにいく --------ここでビデオのデモが終りました--------------------------- - ゲーム進行のしくみ クライアントAから50byte-60byteサーバに聞きに行き、当たり判定などを行い、 その結果をユーザに返す。当然他のクライアントの処理もする。(処理ルーチン) ポーリング通信 シングルスレッドで書いている(通常ゲームはひとつのイベントが終了しないと 次に進ませないため、マルチスレッドで作らない。) そろそろマルチにしても良いかとは思っている。 - プレイオンラインのシステム ディストリビューションスイッチシステム(L3のスイッチ)からGbEでアクセスス イッチに接続、その下にサーバが並ぶ。 サーバ間はFEで接続。1,500台のサーバがD.C.に並んでいる。 RDBやNFSはGbEでつながっている。 アクセススイッチのトラフィックはピークで50Gbpsくらいだが、サーバ間の通 信にも利用される。 サーバ間の通信も激しい。DBサーバやNFSなど。これらはInternetに流れず、D. C.内で閉じている。 １プレイヤあたり平均1k/sec から10k。プレイしている状況による。 単独で歩いてるだけだと300BYTE/sec　6人パーティで1k-1.5k流れる。 ３グループ18人同時操作可能4.5kは軽く出る。 ピーク接続数は、会員数の25%がピークが業界の常識で、ベータテストでも大体 当たってる。 会員数を100万人と考えると、2.5Gですね。 - 2.5Gをさばくネットワーク 言っちゃって良いですよね？、○○大手町においてます。 IPトランジットは○○の1G。 最初100Mまでしかありませんと言われて、げっとか思った。 当初はディストリビューションスイッチから○○に1Gで接続していたが、 現在は△△△やIXに繋がっている。 - NWゲームの問題 ・遅延による問題。 FFXIは毎秒3回のパケット交換を想定。 RTT200以上だと、ポーリングが多くなり、コントローラの反応が鈍くなる可能 性がある。その結果モンスター に攻撃されたときに、反撃ができなくて死んでしまうことがある。 ほかのプレイヤとチャットができなかったりする。 ・ゆらぎ FFXIのアニメーションは、直前のベクトルデータから、次の行動を予測してい る。 そのため、揺らぎが大きいと予測値の限界を超え、アニメーションが崩れる。 たとえば、プレイヤは走り続けてるはずなのに、時々立ち止まって見えたり、 崖から落ちたはずのキャラクタが次の瞬間隣にいたりする。 --------ここでビデオのデモが入りました--------------------------- たまたま撮影に成功した(笑)走っているキャラクタ機歌が ワープする画面 --------ここでビデオのデモが終りました--------------------------- 別にどうでもいいんだけど、バトルの最中にそうなると他のパーティの迷惑に なり、社会問題になりかねない（笑) ・バンド幅 プレイ中はそんなに太い回線はいらないが、パッチのダウンロードにに時間が かかる。 まめにパッチを当てる人は良いが、ゲーム始めようというときに2時間待ちとか だとちょっと嫌ですよね。 それじゃ、エンタテイメントじゃないだろうし。 1/10現在のパッチサイズが10M ・接続性品質 リンク断や、モデム不良によって突然目の前のキャラが消えたりする。 パーティプレイ中に消えたりするとパニックに陥る人が居る。 その際はその場でじっとしていてください。探しに行かないように(笑) - 全国のいろんな所からFFXIのサーバにどれくらいで接続できるか。 (RTTに着目) 富山からのtraceroute　はやいですね。ルータは7hop。RTT 22。IIJからUS にいって日本戻ってくる。 SINET これもUSの中で時間かかってますね。 WIDE ここでもゲームできますね。こういう基準で判断するのもどうかと 思いますが(笑) IIJ　自分ネットワークは1msec以内。やっぱりUS回ってますね。 OMP USまわり150以内 HOTNET 10hopでRTTは50〜60で結構早い 日本は富山と札幌が一番早い？(笑) この試験の後、USからの試験やろうと思ったら図らずも既にやってたんですね (笑) - どこが問題なのか考えた バックボーンの設計、経路制御が正しいのか。 そもそもブロードバンドを前提にゲームを作ってよいのか。 コンテンツホルダからはユーザまでの途中の経路が見えない。同じISPでも地域 によって違うこともある。 そして自分でASとろうと思い、昨年アドレスと共に取得した。 自分でIXやピアを張ろうと思ったが、畑違いなので困った。 頭を抱えていたら、天からクリスタルの戦士が降りてきて助けてもらった。 ディストリビューションスイッチから１本のトランジットに抜けるのではなく て、ボーダールーターから 複数のISPやIXにに抜けるようにした。 - ゲーム製作サイドからの要望 現段階では、「世界中で」「高速1.5M以上で」「揺らぎが無く、RTTは200以下 な」ネットワークがほしいなぁ。 今後はどういう事をやりたいかというと、 チャットはヴォイスちゃっとでやりたい。 しかもサーバに負荷のかからないP2Pでやりたい。 クエストコンプリートの時にはご褒美ムービをやりたい。でもいまはオープニ ングみたいに固定した部分だけ。 リアルタイム配信やりたい。リアルタイムアクティブタイムバトルの実現。 つまりコントローラで避けたら避ける。これをやるには60フレーム。 こうならよいな。 帯域は6M以上 RTT30m sec 揺らぎは6M +- 10% RTT25msec +- 5msec がよいな（はあと） 寝言は寝て言えなんて言わないでね。 □ 関岡さん アプリケーション側の意見をもらったのでざっくりと問題点を整理しましょう。 NW費用削減しながら安定したストリーム配信できるの？ データセンタは大丈夫？ 16.5Gなんてトラフィックををインターネットはさばけるか？ 遅延や揺らぎなどの、安定性は本当に大丈夫か？ ここで話を変えて、これらの問題に対応すべきネットワーク側の立場の人の意見を 聞いて見ましょう。 □　IDCの黒幕〜遅延/パケットロス/揺らぎ　不幸の種〜 　　AboveNet Japan 笹木　一義様 　　 　−遅延 　　　PeeringしないというPolicy上の問題,海底ケーブルが切れた 時の迂回路等 　　−パケットロス 　　　Traffic過負荷のバッファオーバーフロー,ループ, ブラックホール 　　−揺らぎ 　　　定常的な高Traffic負荷運用 　　 　　−Peeringなくって,米国回り問題 　　　国内のConnectivityを良くする為にみんな努力しないと駄目. 　　　高飛車系 　　　　ネットワーク小さいとpeeringしない大手.... 　　　　Transit契約時プロバイダは顧客経路優先（契約上の問題） 　　　ほのぼの系 　　　 言葉の問題とか本質的じゃない事も原因に. 　　　 　　Peeringはより好みしない！回線増強/ベンダと共にRouter増強 　　で努力,共に良いConnectivityを実現しよう！ 　　 　　−DC/IX 　　　Application（Game/CDN）は強烈. 　　　Capacity問題,危機は目の前に有り！ 　　　 　　　Trafficの東京一極集中.IXは点から面へ！Trafficを吸い込むか？ 　　　吐き出すか？集中を避け,分散を実現.きっちりとしたConnectivity 　 　を実現しよう！箱が無限に高速化すれば,Trafficさばけるけどそう でも無い,バックボーンの分散化で,運用区分やビジネス区分の 落とし込みを如何に考えるかが課題？ □　CDN/IX　Intec W&G 中川郁夫様 　　　Server から Client へコンテンツが流れるモデルで、 　　　Contents 屋さんの立場からソリューションを考えよう。 　　　 　　−CDN 　　　Server分散でUserの近い所からTrafficを提供. 　　　最適なServerConnectivityの誘導技術.一つのSolutionである. 　　　ゲームのようなApplicationの場合分散技術のアプローチは容易 　　　に使えない！ 　　−分散IXの提案をもってこよう！ 　　　ユーザとCP(Contents Provider)/CH(Contents Holder)を 　　　直接接続することによって、Delay Sensitive なアプリ 　　　ケーションでも対応できる。また、ユーザ、CP/CH の両者 　　　にメリットが出る。 □　AS／ルータホップ・不幸の始まり　eAccess 矢萩茂樹様 　　 　　　現在のブロードバンドアクセスサービスは、CATVや**BBのように 　　　自らで提供するか、DSL提供事業者の回線を使ってISPから提供する 　　　形となっている。 　　　伝送レベルでの高速化は、最近になってやっとDark Fiberが広域で 　　　手配できるようになり、 　　　 155M x N -> 2,4G -> 9.6G 　　　というように成長中。ユーザへの回線も 　　　 1.5M -> 8M 　　　へと増速されており、FTTHも当然視野に入っている。お金はかかる 　　　けどなんとかなりそう 　　　では、コンテンツの配送システムはどうだろう？ 　　　ここだとISP接続部分がボトルネックになりそう。確実に配送でき 　　　るように考えるなら、BAS直結が確実！(楽)。こういうサービスが 　　　あってもいいでしょ。 　　　J-StreamさんをはじめとするCDNの乗り入れをしていますが、適切な 　　　サーバーへの誘導方式など確立しないといけない問題もある。 　　　このあたりを解決してより美味しいネットワークを構築していく！ □　JANOG9　〜急〜　？？？　はめられたクリスタルの戦死 　　NTTコミュニケーションズ　南　陽様 　　 　　　はめられた…（笑） 　　　 　　　WAN階層,Layerを重ねて作った絵を参照ください！ 　　　IPチューンのネットワークの必要性！SonetではOver10Gで駄目かも. 　　　ところで,Ethernetって他人（技術）を真似て生きてきたけど 　　　これから大丈夫なの？ 　　　 　　　RouterHopって本当に必要？なんなら光クロスコネクトで 　　　県毎にFullMeshで実現してみようか？たくさん使って経済効果 　　　さえでれば安く提供しまっせ？土管屋としては,欲しいI／Fあれば 　　　さらに作らせてもらいますよ！ 　　　 　　　値段は別として,10GbEでもいいよ！ISDN 10Gなんて駄目かな？ ----------------------------------------------------------------- □ 最後の質疑応対/議論 c: 伊勢さんなにかありますか? i: ISPさんに対して非常に頼もしく思っています。問題はいつからできるのか ということ。 春からサービスしたいのだが、いつから増強するのか? SRC/DST の組でトラフィックが綺麗にぬけられるのか? c: 今すぐにでも抜けるということはないのか? 高橋さんの方はどうか? t: 現在は、ある程度までのメドはたつかなぁと思っている。 配信の仕掛けをうまくやれば、インフラには余裕を感じている。 CDN に関しては協調作業が必要です。 岡本: 日本のブロードバンド市場は変わっていて、CDN ですすんできたのかなぁ? 今まではアメリカの方がはやかったのだが、日本で進んできた。 日本ならではの味を出して行かなければならない。 エンジニアが協調して動作させて n: 日本が先行しはじめたというのは思います。アクセス系とかで、日本は がんばっている。分散IX というアーキテクチャも日本初。 ルータ屋さんなど、ベンダとも協調しながら新しいことをやって いきたいと思います。 y: ブロードバンドについても集中という点においては日本が先行していると思 います。ブロードバンドネットワークの規模はここ１年間で2桁の規模拡大し ています。この爆発はまだ続いており、この規模拡大の中で、日本の東京集 中という問題が拍車をかけます。 ユーザ数は東日本で8割弱となっていて、さらにこの8割の8割ぐらいが東京圏 に集中し、この小さなエリアに全国の60-70%のトラフィックが処理される。 こんな規模のユーザのトラフィックをさばける製品は米国にもありません。 10万加入者のブロードバンドアクセスを一箱でこなせるとうたっている製品 でもまったく間に合わないわないわけです。 といって弱音をはいても始まらないので引き続き頑張ります。 会場質問: エッジの方にコンテンツを持って行くのがいいに決まっているが、 それでいいのか? m: IP で運ぶのが全ていいのかがわからない。 すべてのコンテンツに対してIP がほんとうにいいと思っているのか。 t: まずニーズがあるからビジネスがなりたちます。そこをまちがえてはならない。 田中: 100Mではたりないということで 1G にしたら200Mに流れた。 収容しているルータが落ちて、大手町にいったらGigaポート c: 楽なネットワークとは 自分が正しいと思ったことをやるだけで、楽になったら仕事がなくなる。 松島: 今までアクセスメディアのブロードバンドにボトルネックがある。 キャッシュがあるものでないといけない。 下のレイヤで解決することができないのか? BRASにすべてつっこむは全てのユーザに適用することはできない。 ホールセールしているからそうなるのではないか? 安東: 東京に一極集中する状態で、分散はできるのか? 中川: 分散IXなどでトラフィック分散の方向に進んでいる。 地域への分散なども可能。 水越: peeringは今まで経営レベルの判断にまかせてきたが、RTT/Jitterとかの 問題を聞いて、エンジニアリングレベルの判断も重要であると感じた。 何か経営陣にこれをconvinceさせる方法はないか？ 荒野: OCNがfree peering方向にシフトするのなら、日本のインターネット全体の ためには大変喜ばしいことである。 エンジニアとしては、ストリーム／ゲームなどの新しいアプリケーションの 登場を前提にしたときに、RTT/Jitterなどの問題がひいては 顧客数の減少を招くということを経営陣に対し、きちんと説明すればよい。 まとめ - アプリケーション側とネットワーク側で問題の共有ができた。 - 本当に美味しいネットワークを実現して行きましょう。 ========================================================================