Analisis of Peer-to-Peer Traffic on ADSLという論文を読んだんで概要をアップします。概要少々長いです。フランス人が英語で書いた論文です
http://www.pam2005.org/PDF/34310070.pdf


ADSL環境下におけるP2Pトラヒックの解析


1.はじめに
P2PアプリケーションがADSL帯域の多く(60％以上)を消費している。
ADSL環境下で主にTCPレイヤのパケットキャプチャを行うことにより、4つのP2Pアプリケーションのトラヒックを解析する。


4つのアプリケーションは以下の通り
・eDonkey
・BitTorrent
・Fast Track
・Win MX
実験環境下(フランス)では、eDonkeyが大人気なので、eDonkeyの解析を主体にする。

解析内容は以下の通り

・実験環境下(フランス)で人気のあるP2Pアプリケーションの調査
・Signaling Traffic(ファイル転送を行っていないTraffic)の量の測定
・ファイルのアップストリーム量と、ダウンストリーム量の測定
・ピアの接続時間の測定
・eDonkeyとBitTorrentの1日あたりのトラヒック量とピア数の測定
・コネクション終了時のパケット解析
・ローカル実験環境下におけるピアの接続ノード数の測定



2．実験環境

測定は、フランスの一部地域のADSL回線が集中したポイントで行った。
計測したポイントは以下の通り


modem　---------- DSLAM--(Collect Network)--BAS-------(IP Backbone Network)----POP
一般ユーザと　　xDSL回線をまとめ 　　　 Broad Band 　　↑
大学や　　　　　　　　　バックボーンへ 　　 Access Server　 ここですべてのTCPを
プライベートIPなど　　　橋渡しを行う　　　　　　　　　　　　　　　　　キャプチャする
制約がないユーザを
数千調査


P2Pプロトコル(アプリケーション)の識別には、使用しているポートにより分類した。


(ポートによる識別について)
Kazaa(Fast Trackネットワークを使用)や、WinMXなどはポートを任意に指定できる。
そのため、キャプチャに失敗するアプリもあるかもしれない。
P2Pトラヒックのアプリケーションレベルのシグニチャマッチングはポートベースの特定に比べ、分析に必要となるトラヒックが3倍になる＋処理も重くなる。
後で述べるが、実験環境でのP2P利用は、ほとんどがeDonkeyである。

eDonkey(とBitTorrent)のピアは主にデフォルトのポートを使用している。
理由：eDonkeyの場合、ピアが非デフォルトのポートを使うとLowIDになる。
　　　HighID(デフォルトのポートを使用)のピアは、ファイルダウンロードの制約を受けない。
　　　一方、LowIDのピアはHighIDのピアのみからDLできる。←制約を受ける。
　　　(←LowIDとHighIDの指定がポートにだけ依存するか?)


言葉の定義
ローカルピア：DSLAMに接続したP2Pアプリを利用しているADSLユーザ
外部ピア　　：ローカルピアと接続のあるローカルピアでないピア
upstream traffic:ローカルピアからBackboneに送信されたパケットによるもの
downstream traffic:Backboneから、ローカルピアに送信されたパケットによるもの



3．実験結果

3.1 実験環境下(フランス)で人気のあるP2Pアプリケーションの調査



Jun-2003 　　　　　　　　　　　　　　Sep-2004
プロトコル トラヒック量　　パケット数　トラヒック量 パケット数
eDonkey 84% 　　　　　96% 　　　91% 　　　93%
BitTorrent 　　0.8% 　　　　0.01% 　　　6% 　　　2.70%
WinMX 　1.3% 　　　　 0.06% 　　　1% 　　　0.08%
FastTrack 　　12% 　　　　1.8% 　　　1% 　　　　0.01%
Gnutella 　　　0.8% 　　　　0.9% 　　　1% 　　　　3.60%
その他 　　1.1% 　　　　1.2% 　　　0% 　　　　0.60%



2003/6に調査したとき、全トラヒックの65％がP2Pによるものだった。
2004/9に調査したとき、全トラヒックの60％がP2Pによるものだった。

フランスでは、eDonkeyの利用者が多いことがわかる。
BitTorrentがシェアを伸ばしている一方で、FastTrackの利用者が減少している。
ヨーロッパではeDonkeyが人気がある。(←理由は調べてない)


3.2 Signaling Traffic(ファイル転送を行っていないTraffic)の量の測定

P2Pのトラヒックは2つに分類される。
．ダウンロード中のデータのために発生するトラヒック
．ネットワークを維持する、またはファイル検索要求を行うために発生するトラヒック
　(Signaling Traffic)


他の論文では、P2Pのトラヒックの90％以上はSignalingトラヒックだといっている。

２つのトラヒックの判断基準は、各コネクション時に転送されるサイズの合計である。
(サイズが小さいものをSignalingとしている)


実験では判断基準の値、閾値を20kbyteとした。
(他の論文ではSignalingトラヒックの平均サイズは16.7kbyteといっている)
(←これで正しい識別ができるのか？)



実験でわかったこと

閾値を20kbyteとすると、４つのP2Pアプリすべてにおいて、
(コネクション数ベースで見た)全トラヒックの90％以上はSignalingである。(Fig.2)
(eDonkeyの場合、一番高く95％以上。FastTrackの場合一番低くちょうど90％)


Signalingトラヒックが多い理由：
．転送の多くが途中で中断されるため新たにピアを探さなくてはならない。
．ピアの多くがオフラインのピアに対し、接続要求を出すから。

(コネクションサイズベースで見た)Signalingトラヒックの量は、eDonkeyでは6％、
それ以外のアプリでは1〜2％程度に過ぎない。(Fig.2)
←P2Pコネクションのトラヒック量の殆どが、ファイル転送によるものである。
　グラフでは、すべてのP2Pアプリで1コネクションあたり最大で100MBくらい転送を
　行っている。10MB〜100MBの転送の割合が大きい。


3.3 ファイルの、アップストリーム量とダウンストリーム量の測定

実験環境下では、各アプリにおいて、upstream量よりdownstream量が多かった。
(Fig 3:eDonkeyの場合のグラフ)
←ADSLの特性(下りの帯域が広い)による。

P2Pアプリ全体でみればもちろんアップとダウンの量は等しくなるはずである。

実験下ではeDonkeyピアを２つに分類できる。
①小さなアップロード量を持つピア
uploadの1000倍のサイズdownloadする。アップロードに非協力的なピア。

②大きなアップロード量を持つピア
uploadの1.2倍のサイズをdownloadする。アップロードに協力的なピア。
(他の論文では、10％のピアが98％のトラヒックを出していると報告)(←本当か？)

実験では、eDonkeyで、20％のピアがまったくファイルをアップしない
フリーライダーだった。←フリーライダーを減らすことがP2Pアプリの一課題


3.4 ピアの接続時間の測定

４つのアプリにおいて85％以上のコネクションが10秒以上持続。(Fig.4)
90％以上のコネクションが20Kbyte以下(Signaling)。
　　　↓
ファイル交換をしていないアイドル時間が長い。


　　　　　　　　　コネクション持続時間の平均

　　　　　　　　　　　　　eDonkey　BitTorrent　Fast Track 　Win MX
Signaling traffic　　　　12s　　　22s　　　　　　　7s 　　　　　13s
Non-signaling traffic　1436s　1670s　　　　356s　　　　2721s




3.5 eDonkeyとBitTorrentの1日あたりのトラヒック量とピア数の測定


weekday(土日以外)の毎時間ごとのupstream量、
downstream量、ローカルピア数を測定。(Fig.5)


午前0時から午前9時の間にトラヒックとピア数が減少している。
downstreamがupstreamより多い。←ADSL環境にいるから
downstream量が時間的変動が大きいのに対し、upstream量の変動が安定している
←upstream量が大きい(upstram量とdownstream量がほぼ等しい)ピア10％は、
　P2Pネットワークに常時接続しているから。



0時から午後5時までの間は、ピア数(約60〜80)、upstream量(約200MB)ともに安定している。downstram量は約200MB。
外部ピアが増加した時間帯(7〜9時，13〜14時)は、downstreamが急激に(250MBから300MB)増加している。




3.6 コネクション終了時のパケット解析

Flag of last Packet 　　eDonkey BitTorrent FastTrack WinMX
NORMAL 　　　　　　20% 9% 15% 20%
SYN 　　　　　　　　21% 42% 39% 27%
FIN 　　　　　　　　　 6% 　 5% 4% 5%
PUSH 　　　　　　　20% 16% 5% 20%
RESET 　　　　　　　7% 11% 11% 9%
OTHER 　　　　　　23% 16% 25% 17%　　　　　　　　　　(Table.3)


NORMAL:　four-handshakeを表すと書かれてある。(SCTP：Stream Control Transmission Protocolのことか？)
RESETフラグ：　ピアがP2Pネットワークを離脱するとき、多くのアプリケーションでピアがRESETパケットを送っていることを確認
PUSHフラグ：　コネクションが突然切断されたとき、PUSHパケットを送っていることを確認
SYNフラグ：　ダウンロードだけを行う非協力的ピアで見られた。このピアはSYNパケットを送っても、もうネットワークには参加しない。
　　　　　　理由：　ピア間で共有する情報の伝達遅延が原因ではないか。(←よくわからない)




3.7 ローカル実験環境下におけるピアの接続ノード数の測定(Fig.7)

eDonkeyについて：
他のアプリと比べると、ローカルピアが接続している外部ピアの数が一目で見て多い。
全ローカルピアの18％----接続ピアを1つもつ
　　　　　　　　50％----接続ピアを10以上持つ
　　　　　　　2〜3％----接続ピアを10万以上持つ　←ローカル(実験環境下)にあるeDonkeyのインデックスサーバ



BitTorrentについて：
ダウンロード時の接続ピア数が、Signaling時よりも多かった。
BitTorrentは、情報管理(ファイルの情報？ピアの情報？)を1つのtrackerが行うのに対し
ダウンロードは、複数のピアから行われるため。

全体のアプリについて：
Fig.7では、1日中ピア数を測定したものと、2分間だけピア数を測定したグラフがほぼ同じであった。
ピアは、2分以内に他のピアと接続を確立するためである(←1つのピアが接続するピアの数は変わらないのだろうか？)