認証と負荷分散を考慮した ストリーミングシステムに関する研究 認証と負荷分散を考慮した ストリーミングシステムに関する研究　 SING B4 Yohey 親：yasu

目的 配信者が、送りたい複数の相手に対して、 高画質なライブストリーミングを配信できる 世界の実現 自分の帯域をあまり気にせず、 認証により受信者を把握しつつ、 高画質なライブストリーミングを配信できる 　　世界の実現

CDN Content Distribution Network インタネット上のcacheサーバを利用 original server Content Distribution Network インタネット上のcacheサーバを利用 オリジナルサーバと回線にかかる負荷を分散 ISP ISP ISP IX ISP ISP ISP ISP ISP ISP ISP IX IX ISP ISP ISP ISP ISP ISP ISP ISP ISP ISP

実態 配信者はISP,CDSP 受信者は一般ユーザ 業者→ユーザという形態 一般ユーザが配信できない CDN網等の利用 RealやWMTが主流 unicastでの受信 業者→ユーザという形態 一般ユーザが配信できない 発信者側の帯域がボトルネック

マルチキャスト メリット デメリット 帯域の節約 インタードメインで利用できない ユーザを特定できない 認証問題 PIM-SM (Protocol Independent Multicast-Sparse Mode） ・分散する受信者を対象にした（スパース・モード）マルチキャスト経路プロトコル ・マルチキャスト・グループの受信者が、離散的に分散しているときの 　通信を効率的に行うためのマルチキャスト経路プロトコル ・マルチキャスト配送ツリーは、共有ツリーだけでなく、 　送信元ツリー（最短パケット経路）もサポートしています。 　送信パケットが多くなった場合に、送信元ツリーへ移行できるような仕組みをもっています。 　これによって、共有ツリーの最短経路を通らないという欠点を補っています http://www.hitachi.co.jp/Prod/comp/network/gr2000/manual/html_b/kaisetsu/0256.htm X-Cast 小規模であり、拡張性に欠ける 最初に全てのdstアドレスが必要

PeerCast Gnutellaのライブストリーミング版 高価なサーバやネットワーク帯域を使わない 誰でもインターネット上で放送者になれる 耐障害性が高い 中央サーバを必要としない 放送者の匿名性 認証不可 配信サーバ検索は位置管理サーバに依存 位置管理 サーバ

問題意識 家庭にいるユーザ(配信者)が配信したい複数のホストに対して配信する術がない 帯域問題 認証問題

実現したい世界 ライブストリーミングに関して、 誰もが配信者 誰もが受信者 配信者が帯域を気にしなくてもよい ユーザを特定できる(認証) 簡単に 透過的に受信できる

アプローチ DVTSを使用 アプリケーションマルチキャストの実現 ストリーミングシステム DVスプリッタ 受信側/配信者のシグナルコントローラ ストリーミングシステム 負荷分散 配信者が自分の帯域を気にせずに配信 認証 配信者側が受信者を把握 認証さえすれば、受信可 動的 スプリッタの検知 ユーザに透過的 スプリッターの存在を意識しないでよい

システム概要 重要 配信者 DVスプリッタ DVスプリッタ DVスプリッタ DVスプリッタ DVスプリッタ 受信者 受信者 受信者

設計 Probe パケットを利用 ルーティングをしない プロトコルとしてより汎用的なものに 透過性を高める DVスプリッタを動的に検知 位置情報サーバ不必要 ルーティングをしない トポロジを把握する必要なし プロトコルとしてより汎用的なものに シグナル・コントローラーとDVTSを分ける 今後、DV以外のフォーマットにも対応可 透過性を高める スプリッタを意識させない

流れ advertise TTL計算 TTL計算 配信者 request/ 認証key capture ルータB DVスプリッタB probing packet probing packet probing packet サーバー だけ capture ルータB DVスプリッタB capture advertise advertise request/ 認証key TTL計算 ルータA DVスプリッタA タイムアウト Request/ 認証key TTL計算 ホストA

DVデータは既に持っているので、 認証Keyだけ 流れ２ 認証 key 配信者 Probe packet Probe packet DVデータは既に持っているので、 認証Keyだけ TTL計算 複製 detect ルータB DVスプリッタB ホストB advertise Request / 認証key ルータA DVスプリッタA ホストA

シグナルコントローラ 配信側 監視制御 受信側 Request packet処理 認証処理 dvsend制御、監視 スプリッタ選択の判断 配信側 監視制御 Request packet処理 認証処理 dvsend制御、監視 受信側 スプリッタ選択の判断 TTL dvrecvの制御、監視 シグナル コントローラー dvsend シグナル コントローラー dvrecv

DVスプリッタ ルータからのパケット監視 CPU/memoryリソース監視 probe packetの監視 DVパケットの監視 ホストへ報告 DVパケットの監視 複製＆配信 CPU/memoryリソース監視 複製不可能になった場合、複製無視

パケット Probing packet Request packet Terminate スプリッタの検知 動画配信要求 停止要求 Src IPアドレス TTL Request packet 動画配信要求 src IPアドレス ホストIPアドレス DVTS受信用ポート番号 認証Key Terminate 停止要求 ホスト IPアドレス スプリッタIPアドレス

動作 往復経路が違う場合を想定 処理はスプリッタで全て処理 一定のCPUリソースを超えたスプリッタはprobeパケットに応答しない ルータの負担を減らす 一定のCPUリソースを超えたスプリッタはprobeパケットに応答しない 安定したサービスを提供。 probeパケット配信ををDVスプリッタ毎に行う。 多段スプリッタに対応 切れた場合、上の階層からDV受信可

進捗 もう少し詳細を決めた後、これから実装 OS：FreeBSD 4.8R 言語：C言語 DVスプリッタ

評価 定性評価 定量評価 家庭でできそうな帯域に収まっているか 階層化スプリッタでの負荷分散 認証 ユーザがストリームを受けるまでのユーザの待ち時間 パケットロス 1ホップ複製ごとの遅延

課題 パケット複製能力 タイムアウトをどうするか？ 非効率な場合の対処方 受信者が少数の際に、複数のスプリッタで転送を行っている場合

Q&A 目的は？ 何をするの？ システムとは？ 何のためのプロトコル？ 何でDVTS？ なぜ盗み聞く必要があるの？サーバーが処理できないの？ 一般家庭などから、帯域を気にせずに複数ホスト相手にUDPライブストリーミングを行いたい 何をするの？ 新しい形のストリーミングシステムを作ります。 システムとは？ プロトコルとその実装を作る 何のためのプロトコル？ トラフィックの分散 何でDVTS？ 身近 WMTやRealの様にプロトコルが複雑でない。エラー処理など なぜ盗み聞く必要があるの？サーバーが処理できないの？ 盗み聞きをせずにサーバーが処理をして、DVスプリッタの位置を把握するためには、位置情報管理サーバが必要であったり、サーバ側がネットワークトポロジー的な場所を把握する必要が出てくる DVスペシフィックな話が出てこないがなぜか？ シグナリングとスプリッタを使用することによってトラフィック分散を行えるこのシステムを、もうすこし汎用的なものとしてとらえており、dvsendとdvrecvを分けた理由もそこにある。

設計 ルータ DVスプリッタ 受信者 配信者 capture probe packet response Request/認証 タイムアウト