P2P ストリーミングにおけるジッタ性能評価
2007MI024 福島悠太

指導教員

2007MI111 近藤

河野

大樹

浩之

前方 (再生前) バッファのうち使用可能なセグメントの1 はじめに数，c(t) を同タイムスロット中にダウンロードしたデー

P2P 技術の発達につれ，P2P ストリーミングの利用タチャンク量，そして C は 1 タイムスロットあたりの者が増加している．しかし従来のクライアント・サー総チャンク量とすると，式 (1) が成立する．この式は文バー方式と同様に，ジッタによる動画再生への悪影響の献 [2] 内で証明が行われている．

問題を持つ．このジッタを発生しにくくすることで，ストリーミングサービスの品質向上を図ることができる．

q(t + 1) ≤ P r[c(t) < C|L(t) = 1] × P r[L(t) = 1](1)

本研究では，ストリーミングサービスの品質向上をどの文献 [2] では，5 つのノードと 2000 のクライアントをように実現すればいいのかを提案する．実験では P2P設定したシミュレーションによってピアのダウンロードネットワークを構築し，パケットキャプチャソフトでパ待ち時間をうまく分散させる手段を模索していた．

ケットの計測を行い，ジッタ発生率の解析を行う．ジッ

本研究では，シミュレーションではなく実際にハードタの発生を極限まで減らしつつ，動画再生品質を出来るウェアを用いて P2P 環境を構成する．しかし文献 [2]だけ向上させる方法を模索する．のように 2000 以上のピアを用意する事は実環境ではコ

2 P2P ストリーミングのクオリティ向上へのスト面から見て不可能なので，各ピアの中継にリピータ提案ハブを使うことで，ネットワーク内のパケットを増やしてジッタの変化を推測する．

2.1 クライアント・サーバ方式との違い
Masahiro Sasabe らの文献 [1] では，高品質かつ低遅文献 [2] では式 (1) によって一定時間毎のジッタ発生率を主に計測している．本研究では，TCP が定期的に延なビデオストリーミングサービスを提供する為のプ算出する RTT 値と，連続するパケットの到着間隔の変ロキシ貯蔵メカニズムを提案している．このメカニズム

動からジッタの変化を推測する．

はクライアント・サーバ方式のストリーミングに対する提供であり，本研究で取り扱う P2P ストリーミングと表1はネットワークの形式が異なる．文献 [1] に限らず，クライアント・サーバ方式のストリーミングのクオリティピア数を向上させるには，その大黒柱である配信サーバの安定性や処理速度に焦点を当てる必要がある．それに対して

P2P ストリーミングのクオリティを向上させるには，配信者だけでなく，中継するピアの環境も重要な要素とな研究内容の比較

文献 [2]

本研究

2005

12環境

仮想環境

実環境

過負荷方法

膨大なピア数

リピータハブジッタ算出

式1

RTT&到着間隔

る．本研究では P2P ストリーミングについての測定を

3 ジッタ測定に必要なツールなどの提案行うので，サーバ周辺だけでなく，各ピア間の送受信に焦点を当てている．

3.1 ジッタの計算方法
TCP プロトコルには，RFC 3550 RTP のようなパ

2.2 Xiaosong Lou らによる類似研究
Xiaosong Lou らの文献 [2] では，P2P を利用したIPTV*1 の映像再生中のジッタによる動画の不具合をケットの到着時間の差を直接参照できる要素は存在しない為，別の要素でジッタの変化を測定する必要があ解決する提案を行っている．シミュレーションを用いてる．TCP プロトコルでは，帯域測定の為に往復遅延時

P2P を用いた IPTV サービスを構成し，ピアのダウン

間 Round Trip Time(RTT) を定期的に計測する．双方

ロード待ち時間をどうすれば分配できるかの模索をする

向通信の TCP では，パケットを送信してから，そのパ事で，P2P ストリーミングのジッタを軽減させようとケットの ACK を受け取るまでの時間差を計ることがでしていた．文献 [2] より，q(t) をタイムスロット t 内できる．

ジッタが発生したピアの割合，L(t) をクライアントの*1

3.2 ソフトウェア構成と使用するツール
ジッタ評価を行う為に P2P ネットワークを構成し，IPTV(Internet Protocol TeleVision)，インターネットを利

そのネットワークに意図的に負荷をかけつつストリーミ

用してテレビ放送を配信するサービス

1

ングを行い，ジッタの変化がどのような環境に依存する

表 2 既存の P2P ストリーミングサービスの性能表かを測定する．本研究では，WireShark，PeerCast を用いて，ストリーミングと．小節 3.2.1 以降は，これらツールの特性を記述する．

サービス名

個人での配信ビットレートLiveStation

不可—KeyHoleTV可

100/200/500(Kbps)

PeerCast

可任意

LiveStation*3 は個人で配信が不可能であり，ストリーミングを自由な形式でキャプチャする事ができず，測定には向かない．KeyHoleTV*4 は 500Kbps を超える高ビットレートでの配信ができないので，今回の実験で想定している高ビットレートの動画とジッタ変化量の関係の測定が困難になってしまう．よって，PeerCast*5 やLivetube*6 のような，個人での配信が可能で，動画の形式を自由に指定できるストリーミングサービスがこの測定に適していると言える．

3.3 ローカルネットワーク内で負荷を与える手段
PeerCast は節 3.2.2 でも述べたように，ピア同士の最初の接続は YellowPages を介して行うが，一度接続してしまえばそれ以降はピア同士で直接パケットの送受信を行う．ストリーミングに参加するピアが全て同じネッ
図1

トワーク内にいれば，最初の接続以外の全ての通信をソフトウェア構成図

ローカルネットワーク内で行う事になる．近距離の通信
これらのツールは，各 Receiver 内で動画データの流れなので帯域への負荷が少なく，長距離通信を前提としたが図 3.2 のようになるよう構成する．図中の PeerCast計測を行うには不向きである．同一ネットワーク内にあは他 PC とのパケットのやりとりを中継しつつ，動画るコンピュータで長距離通信時のような負荷を再現した
い場合，ソフトウェアで意図的に負荷を与えるか，帯域再生ソフトへデータを動画再生できる形式にして渡す．

WireShark は配信先へ送るパケットの解析を行う．この狭いハードウェアを中継させれば，長距離通信でなくこで得られるデータから RTT 値とジッタの変動についても，帯域に負荷を与えることができる．本研究では，測定時にリピートハブを用いて各 PC を接続する．そうて考察する．

3.2.1 パケットキャプチャする事でパケットがスムーズに到着せず，ネットワークRTT 値を得る為のキャプチャには，WireShark*2 を使用する．WireShark はパケットキャプチャソフトに負荷をかけることができる．

3.4 配信に使用する動画
本来のストリーミングは，低帯域回線のピアが中継にEthereal の後続のフリーウェアである．通信している参加しても当たり障りのないようにと，配信する動画のプロトコルを解析する機能を持ち，パケットからジッタデータ量はできるだけ小さくするべきである．データ量や遅延がどの程度発生しているかを検出することが出来る．本研究では，WireShark を一部のピアに導入しを小さくし出来るだけ回線に負荷を与えないようにすてジッタの測定を行う．WireShark は TCP 通信でのる事で，ジッタによるストリーミングへの悪影響も抑えRTT 値およびパケットの到着時間間隔の変化をグラフることが出来る．しかしこの研究では動画がストリーミングへ与える影響を測定するので，できるだけ回線に負化して出力することができる．本研究ではこのグラフ化

荷を与える動画を配信する．出来るだけ動きの激しい動の機能を用いて，RTT 値とパケット到着時間の変化を画を高ビットレートで配信すれば，動画の持つデータ量考察する．

が増加し，動画がストリーミングに与える影響も大きく

3.2.2 ストリーミングソフトウェア
視 聴 が 個 人 で 自 由 に 可 能 な P2P ス ト リ ー ミ ン*3 LiveStation，http://www.livestation.com/*4 KeyHoleTV，http://www.v2p.jp/video/*5 PeerCast，http://www.peercast.org/download.php*6 Livetube，http://livetube.cc/

グ サ ー ビ ス の 候 補 を 表 2 に 記 す ．こ の 候 補 の 内 ，*2 WireShark，http://www.wireshark.org/

2

4.2 実験内容なる．

この節では，前節 4.1 で構築した環境下で小節 4.2.1

4 ジッタ測定システムの実装から小節 4.2.2 までで記す 3 種類の実験を行う (それぞ4.1 測定環境

れを実験 A，B，C とする)．それぞれの実験の大まかな

4.1.1 ハードウェアの構成

特徴は表 3 に記述する．
表3

ジッタの測定を行う 3 種類の実験検証する要素ビットレート

ピア数

実験 A

ビットレート

変動

12

実験 B

ピアの数

—

変動

実験 C

通信帯域—

12

キャプチャしたパケットには，ストリーミングには無関係のパケットも含まれている可能性があるので，グラフ化の際には WireShark 内で TCP ポート 7144 のみを抽出するフィルタリングを行う．PeerCast は全ての通信を TCP の 7144 ポートを通して行うので，このポートを通るパケットに限定すれば，ほぼ全てのキャプチャしたパケットがストリーミングに関するパケットとなる．フィルタリングのコマンドは ((tcp.port ==図27144) and (ip.src == ”src.adress”) and (ip.dst ==”dist adress”) ) と記述する．

ハードウェア構成図

4.2.1 実験 A

ビットレートとジッタの関係

ストリーミングのビットレートを変化させた時に，P2P ストリーミングを実現するためのハードウェアジッタにどのような影響があるのかを解析する．動画の構成を図 4.1.1 に示す．動画配信を行う SenderPC は，ビットレートは，500Kbps，700Kbps，1Mbps の三種類

リピート Hub である RATOC REX-0687 を経由してを用意し，ストリーミング中の参加や退出は無いものとReceiver にストリーミングを行う．PC1 は REX-0687

する．この状態でキャプチャを行う．の直下に接続し，その他の PC は 100BASE-TXHub の4.2.2 実験 B

ピア数とジッタの関係直下に接続する．こうすることで，100BASE-TXHub

この節では動画のビットレートは 700Kpbs で統一すに接続されている PC がネットワークへ接続する際る．実験 A から得られた最大ビットレートの動画を流に，REX-0687 の帯域制限に引っ掛かりやすくなり，パし，開始時のピア数は実験 1 よりも少ない状態から開ケット転送がスムーズに行われないようにする．Re-始する．ストリーミング開始後から参加させるピア数をceiverPC は RATOC REX-0687 を経由して Sender からパケットを受け取る．図 4.1.1 のようにストリーミ徐々に増やしていく．この節の実験は 3 通り行う．

ングに参加する PC は 100BASE-TX 対応の Buﬀaloノードとピア 7 台の計 8 台を P2P に参加させた状態か

LSW10/100-8HW を経由して接続する．この Hub はらストリーミングを開始し，パケットキャプチャを延べジャンパスイッチでポート毎に転送速度を指定可能で，さらに全二重転送か半二重転送のどちらで接続するか指2 分行う．測定開始より経過 30 秒から，10 秒おきにピアを 1 台ずつストリーミングに参加させ，ネットワーク定可能な Hub である．この Hub を接続し，全てのポーへの影響をキャプチャ結果から推測する．

B-1 参加ピアの増加

B-2 先端ノードから参加ピアの減少

トを 10Mbps，半二重転送モードで接続した．

4.1.2 測定に使用する動画とストリーミングの条件

参加しているピア数をノードの先端にあるピアから順に

今回の実験で用意する動画は，ゲームのリプレイ画少しずつ減少させ，その影響を検証する．実験 B-1 で途面をソフトウェア DirectShowFilter の一つ，SCHF を中から参加させたピアを，実験 B-1 とは逆の順番でスト用いてキャプチャし，WindowsMediaEncoder9 でストリーミングから退席させていく．測定開始より経過 30リーミングを行う．フレームレートは 29.97fps，解像度秒から，10 秒おきにピアを 1 台ずつストリーミングには VGA サイズ固定とする．

参加させ，ネットワークへの影響をキャプチャ結果から3推測する．ているからである．この事は，パケットキャプチャを行わなかった PC で，ストリーミングが途中で切れてし5 実験結果と考察まったことからも確認が取れる．スループットのグラフ

説 4.2 で記した内容でストリーミングのキャプチャをから，今回構成したネットワークでは 1Mbps 以上の帯行い，それぞれの RTT とジッタ到着遅延時間のグラフ域を安定して得るのが難しいネットワークだというのを得ることができた．

がわかる．ビットレートを上げすぎた場合，帯域不足で5.1 動画のビットレートごとの RTT 値の評価接続が切れてしまうということが推測される．同様に，

図 3 と図 4 は，実験 A でビットレートが 500Kbps のPeerCast で組んだ P2P が，帯域不足の為疑似的なバケ時に出力したグラフである．他の出力グラフと比較しツリレーになったのもこの為だと言える．て，ビットレートの上昇につれて RTT の最大値も上昇

6 おわりにし，RTT パケットの量が増えている事が分かる．ネットワークの余剰帯域が狭まり，パケットが潤滑に送受

本研究では，P2P ストリーミングにおけるジッタの信されていないことが原因であると言える．また I/OGraph でスループットをグラフ化した場合，今回構成したネットワークの有効帯域は 1Mbps 以下であることが変動の特性を，シミュレーションではなく実際にネット判明したので，実験 B で行うビットレートを 700kbps構築し測定したが，本研究では小規模ながらも実ネットに固定する事にした．このネットワーク環境のまま配信ワーク環境を用いて測定した．それにより，仮想ネットビットレートを 1.5Mbps に引き上げた場合，ストリーワークでは仮定を元にネットワークを構築する為，実際ミングが強制終了する場面が何度があった．この要因との環境で同じ環境を再現した時に，無視できない誤差して，ネットワークの帯域不足が深刻になり正常なストが生じるというリスクを常に意識しなければならない．

リーミングが受信できなかったと言える．

しかし，本研究は実環境で測定したので，そのような誤ワークを構築して検証した．先行研究ではネットワークシュミレーターを用いて大規模な仮想ネットワークを差は出ないということが言える．反省点としては，今回の研究ではジッタを直接測定する事が出来なかった．

RTT 値からジッタを推測する事に留まったので．今後はジッタを直接測定出来るような実験を行いたい．

参考文献[1] Masahiro Sasabe, Yoshiaki Taniguchi, Masayuki
Murata, and Hideo Miyahara, “Proxy cachingmechanisms with quality adjustment for video
図3

streaming services,” IEICE Transactions on Communications Special Issue on Content Delivery

実験 A の直下ピアへの RTT グラフ ビットレー

トが 500Kbps の場合

Networks, Vol.E86-B, pp.1849-1858, 2003.
[2] Xiaosong Lou, Kai Hwang, Gaogang Xie, “Qualityof Service in Peer-to-Peer IPTV Networks,” 2009
図4

実験 A の到着時間の I/OGraph

15th International Conference on Parallel and Distributed Systems, pp.9-17, 2009.

ビットレー[3] 川上 貴宏, 岸田 崇志, 河野 英太郎, 前田 香織, “高品トが 500Kpbs の場合

質動画像伝送を想定したネットワーク性能評価ツー

RTT 値が上昇するということは，パケット送信側かルの開発,” 情報処理学会研究報告.DSM[分散システら受信側にパケットが到達して，そのパケットが正常ム/インターネット運用技術], Vol.38, pp.1-6, 2003.に受信できたことを確認する ACK の到達時間が伸び[4] Xiaojun Hei, Yong Liu, Keith W. Ross “IPTVているということである．また，時間が経過するにつover P2P Streaming Networks: the Mesh-pullApproach,” IEEE Communications Magazine,Vol.46, pp.86-92, 2008.

れ RTT 値の最大値が大きくなっているのは，n 番目のRTT が確認され，n+1 番目の RTT を確認するまでに，ネットワーク内でのデータの滞留が n 番目の RTT を受信した時よりも大きくなり，データ転送に支障が生じ4