P2P帯域制御の最新状況〜技術、製品、運用、展望〜
6月29日に開催されたN+I2004のワークショップ「P2P帯域制御の最新状況」に参加してきました。最近ではP2P界隈の話題はニュース性が高いようで、単なるワークショップなのに結構記事が出てます。
ネットワーク全体の50％以上がP2Pによるトラフィック〜N+Iワークショップ(INTERNET Watch)
http://internet.watch.impress.co.jp/cda/event/2004/06/29/3697.html*1
「お行儀の悪い」P2Pトラフィックへの対処法(ITmedia)
http://www.itmedia.co.jp/enterprise/articles/0406/30/news013.html
僕はP-CubeとCaspian Networksの話を目当てに行ったのですが、今回の講演を聞いて、この2つの製品が共通して「P2P対策を売りにして製品を置いてもらい、P2Pトラフィックの問題如何に関わらず、そこに居座り続けようとしている」ことを強く感じました*2。今回はこの点と、上の記事中で触れられていなかった内容を中心に、ワークショップでのP-CubeとCaspian Networksの講演内容を簡単に紹介してみます。
-
-
- -
-
まず、P-CubeのService Engineについて。これは同時通訳による講演でした。
Service Engine（SE100, SE1000, SE2000のシリーズ）はトラフィックをユーザ、アプリケーション、フロー単位で分析し、帯域制御することができる製品です。既に日本でも、ぷららを始めとするいくつかのISPで導入されているとのこと*3。
P-Cubeの製品がISPにとって魅力的なのは、次々と生まれるファイル共有ソフトの対策だけで投資を回収できる点。プレゼンの中で示された帯域制御前後のトラフィックの推移を見た感じでは、どうも必要以上にP2Pトラフィックを抑制するようになっている（＝帯域をフルに使わせるようにはなっていない）ようで、外部接続にかかる費用はかなり削減されそうです。日本のキャリアの例（ぷらら？）では、4ヶ月で投資を回収できた(ROI of 4-month)と言ってましたが、確かにそれも頷けます。
また、Service Engineには後からプログラムを追加可能であるため、新しいプロトコルにも迅速に対応できる、という点もアピールしていました。例えば、日本独自のWinnyをサポートするまでにかかった時間は3週間とのこと。それと、公演中に「WinnyやShare*4のような〜」という言い回しを多く使っていたので、恐らくShareの対策も着々と進めているのではないでしょうか（単なるパフォーマンスかもしれませんけど、ちょっと驚きました）。
そして、プレゼンの最後には「P2Pを越えて(Beyond P2P)」というスライドで、今後の目標を以下のように示していました。
- トラフィックの最適化：トラフィックを詳細に分析することで、ネットワークの使われ方を賢く理解する。この最適化の格好の例がP2Pであるに過ぎない。
- セキュリティ機能：セキュリティ対策をきちんとしていないユーザのために、DoS攻撃やワーム、スパム等を遮断する。
- コンテンツへの課金：品質の高い（プレミアム）コンテンツやサービスに課金する。例としてはストリーミング配信、VoIP、オンラインゲームなど。
- プレミアムサービスの優先制御：上記コンテンツやサービスを実現するための優先制御を行う。
これだけストーリーが出来ていれば、バカ売れになるのもわかるなぁ、という感想です。
とはいえこのP-Cubeのビジョンが現実になるということは、P2Pトラフィックが今後合法化するようなことがあったとしても、トラフィックの完全な監視によるQoSが一般的なものになるということです。ISPにとって便利な機能というのは分かるのですが、これが普及したらNATが混在する今以上にネットワークが息苦しくなりそう*5で、ちょっと良い気分はしませんね……。
-
-
- -
-
一方、Caspian NetworksのフローベースルータApeiroについて。こちらは日本語での講演で一安心でした。
Apeiroはフロー単位でQoSの適用や輻輳制御を行うルータ（＝フローベースルータ）です。P2P……というかファイル共有ソフトのフローを、その特性に基づいて制御できる、ということを最近は売りにしているようです。
フローベースの考え方と、P2Pトラフィックの制御の相性がいい理由の一つには「P2PトラフィックがWebアクセス等のレスポンスを悪化させるのは、それが帯域を占有させるからだけではなく、TCPの実装にも一部の原因がある」という意外な事実があります。詳細は省きますが、現在のTCPの実装（ウィンドウサイズの決定方法*6、再送制御*7）では、Webトラフィックのようなフロー持続時間が短い(short-lived)通信は、ファイル共有ソフトのようなフロー持続時間が長い(long-lived)通信よりも失敗しやすい――そのため、単純にバックボーンの帯域を増やしても、Webとメールを主に利用する一般ユーザの使用感は改善しにくいのだそうです。これは初めて知りました。
そして、こちらのプレゼンでも、最後には「フローの特性に応じたアクション」の可能性として以下のようなものを挙げていました。
- 輻輳制御時のプリファレンスをISP毎にカスタマイズ
- フローステート情報に基づくPBR/PBF(Policy Based Routing/Forwarding)
- アドミッションコントロール
- セキュリティ、DDoS対策（特定ホストに対するトラフィックが閾値を越えたら遮断する、等）
- 課金
- 統計情報
感想としては……Caspian NetworksもP-Cubeと似たようなことを言っているようにも見えますが、僕はこちらのモデルの方にはあまり抵抗を感じませんでした（課金機能のような、ユーザの識別が必要な機能はあまりアピールしていなかったので）。ISPネットワークの境界にこのApeiroを置くだけでユーザ間の公平な帯域利用を実現できるなら、何もユーザの側に近い部分にService Engineのような不気味な代物を多数設置することはないじゃないか、とも思います。
ただ、日本テレコムの今村氏の講演で出た話題の中に「最近はISPネットワークの中で閉じるP2Pトラフィックも増加している」という話も出たので、そこまで対処しようと思ったら、やはりService Engineのような製品を多数設置する必要があるのは事実なんですが……。
とりあえず、この辺りの製品動向については今後も注意してみる必要がありそうです。
*1:プレゼン画面を（音のしない）デジカメで撮影してる人が僕の前の席に居て、「配付資料があるのに、なんでわざわざ写真なんか撮ってるんだろう？」と思ったのですが、どうやらこの取材の人だったみたいです。
*2:別に、それが悪いと言ってるわけじゃないですよ。一応。
*3:参考（ぷららのP-Cube製品導入に関する記事）：Plala Networks Picks P-Cube(Boardwatch)
*4:Share（仮）とは言ってませんでしたよ、一応念のため（？）
*5:新しく登場したアプリケーションを動作させるために、ユーザの手前にあるNATひとつを騙すのにも一苦労してる現状を見ていますから。こんな「インテリジェント」な機器がネットワークのあちこちに置かれるなんて、正直ゾッとします。
