ポイントツーポイント（Ｐ２Ｐ）トラヒック制御システム及び方法
【課題】 ネットワークの境界ルータにおいてISPがP2Pトラフィックを監視し、他のISPがP2Pアプリケーション自体と直接連携することなしに、ISP間で交換されるP2Pトラフィックを削減する。
【解決手段】 本発明は、境界ルータにおいて、受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定し、通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなるよう遅延値Ａを計算し、該遅延値Ａを経由ISP数に応じた所望の遅延時間として、ファイル共有系P2Pトラフィックに対して付加して送出する。
【解決手段】 本発明は、境界ルータにおいて、受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定し、通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなるよう遅延値Ａを計算し、該遅延値Ａを経由ISP数に応じた所望の遅延時間として、ファイル共有系P2Pトラフィックに対して付加して送出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、P2P（Point to Point）トラヒック制御システム及び方法に係り、特に、P2Pトラフィックに対して故意に遅延を与えることのみによってISP(Internet Services Provider)間のP2Pトラフィックの削減を実現するためのP2Pトラヒック制御システム及び方法に関する。
【背景技術】
【０００２】
インターネットの利用形態が多様化するに伴い、トラヒックがネットワークに与える影響についての研究はより重要となってきている。実トラヒックデータの分析結果に関する報告は多く上げられており、それらによると、近年ではYouTubeのようなウェブベースの動画コンテンツ配信サービスの発展によって、過去にネットワークを支配していたP2Pトラヒックに代わり、HTTPトラヒックが支配的になってきているとされている（例えば、非特許文献１，２，３参照）。しかし、国内においては、いまだP2Pトラヒックはネットワーク全体のトラヒックに大きな影響を与えており、一部のユーザによる大容量のトラヒック生成が大きな問題となっている(例えば、非特許文献４参照)。また、先述のコンテンツ配信についても、サーバ側の容量や負荷の問題を抱えるクライアントサーバ型に代わる、P2P型での配信モデルが注目を浴びており（例えば、非特許文献５，６参照）、P2Pトラヒックがネットワークに与える影響は、いまだ大きな問題であると言える。
【０００３】
このような問題に対し、一定以上のトラヒックを送出するユーザに対して帯域制御を行うといった対策について検討されている（例えば、非特許文献７参照）。一方で、上記のように規制をする代わりに、ISP（IPネットワーク側）とP2P事業者（オーバレイ側）で協調するアプローチ（P4Pと呼ばれる）も検討されている（例えば、非特許文献８参照）。この方法では、ISP側がIPネットワークのトポロジやリンク負荷情報を開示し、特定のリンクに負荷が集中しないようなダウンロード元ノードをP2Pが選択できるようにする．こうすることにより、P2Pアプリケーションにとって高品質（ダウンロード時間の短縮）であり、ISPにとって負荷分散を図ることが可能となる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Cisco Visual Networking Index: Forecast and Methodology, 2008-2013, (http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf)
【非特許文献２】Gregor Maier, Anja Feldmann, Vern Paxson, Mark Allman, "On dominant characteristics of residential broadband internet traffic," ACM IMC, 2009.
【非特許文献３】Nate Anderson, "The YouTube effect: HTTP traffic now eclipses P2P," http://arstechnica.com/old/content/2007/06/the-youtube-effect-http-traffic-now-eclipses-p2p.ars)
【非特許文献４】Kenjiro Cho, Kensuke Fukuda, Hiroshi Esaki, Akira Kato, "Observing slow crustal movement in residential user traffic," ACM CoNEXT, 2008.
【非特許文献５】Ryoichi Kawahara, Noriaki Kamiyama, Tatsuya Mori, Haruhisa Hasegawa, "Performance evaluation of peer-assisted content distribution," IEEE CCNC, 2011.
【非特許文献６】Dongyan Xu, Sunil Suresh Kulkarni, Catherine Rosenberg, Heung-Keung Chai, "Analysis of a CDN-P2P Hybrid Architecture for Cost-Effective Streaming Media Distribution," Multimedia Systems, 2006.
【非特許文献７】帯域制御ガイドライン(http://www.jaipa.or.jp/other/bandwidth/info_080523.html)
【非特許文献８】Haiyong Xie, Y. Richard Yang, "P4P: Provider Portal for Applications" SIGCOMM, 2008.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の非特許文献８の手法では、P2PアプリケーションとISPが協調動作する必要があり、P2Pアプリケーションに対してそのようにさせるインセンティブを与えなければならないという問題と、ISPに対してネットワークの情報を開示させるための仕組みを用意しなければならない、という課題があった。
【０００６】
本発明は、上記の点に鑑みなされたもので、ISPがP2Pアプリケーション自体と直接連携することなしに、ISP間で交換されるP2Pトラフィックの削減を実現することが可能なP2Pトラヒック制御システムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明は、ネットワークの境界ルータにおいて、ISP(Internet Service Provider)がP2P(Point to Point)トラフィックを監視し、他ISPと同士で通信を行っているP2Pトラフィックを制御するトラヒック制御システムであって、
前記境界ルータは、
受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定するP2P判断手段と、
通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなる遅延値を計算し、記憶手段に格納する遅延値算出手段と、
前記記憶手段に格納されている遅延値を経由ISP数に応じた所望の遅延時間として、前記ファイル共有系P2Pトラフィックに対して付加して送出するパケット遅延手段と、
を有する。
【発明の効果】
【０００８】
本発明によれば、ネットワークの境界ルータにおいてISPがP2Pトラフィックを監視し、故意に遅延を付加することにより、他のISPがP2Pアプリケーション自体と直接連携することなしに、ISP間で交換されるP2Pトラフィックの削減を実現する。
【図面の簡単な説明】
【０００９】
【図１】本発明が適用されるネットワーク基本構成の一例である。
【図２】本発明の第１の実施の形態における境界ルータの構成例（自社ISP内からパケット受信）である。
【図３】本発明の第１の実施の形態における境界ルータの構成例（他社ISP内からパケット受信）である。
【図４】本発明の第１の実施の形態における図２の境界ルータの動作のフローチャートである。
【図５】本発明の第１の実施の形態における図３の境界ルータの動作のフローチャートである。
【図６】本発明の第２の実施の形態における図２の境界ルータの動作のフローチャートである。
【図７】本発明の第２の実施の形態における図３における境界ルータの動作のフローチャートである。
【図８】本発明の第３の実施の形態における図２の境界ルータの動作のフローチャートである。
【図９】本発明の第５の実施の形態におけるシステム構成例である。
【図１０】本発明の第５の実施の形態におけるアクセス網境界ルータの構成図である。
【図１１】本発明の第５の実施の形態におけるISP境界ルータの構成図である。
【図１２】本発明のシミュレーショントポロジの例である。
【図１３】本発明のシミュレーション結果を示すグラフである。
【発明を実施するための形態】
【００１０】
以下図面と共に、本発明の実施の形態を説明する。
【００１１】
[第１の実施の形態]
図１は、本発明が適用されるネットワークの基本構成の一例を示す。
【００１２】
ISP(ISP A，ISP B)は、キャッシュ機能を有したキャッシュノードをネットワークの境界ルータとして配置するものとする。
【００１３】
図２および図３は、キャッシュノード(境界ルータ)の構成例を示すブロック図である。図２は、自社ISP内ユーザaからパケットが送られてきたときの境界ルータのブロック図であり、図３は、他社ISP内ユーザbからパケットが送られてきたときの境界ルータのブロック図であり、パケット送信元が自社ISP内ユーザか他社ISP内ユーザかによって分けているのみであり、同一の装置である。
【００１４】
図２、図３に示すキャッシュノードは、P2P判断部１１、ハッシュ値計算部１２、フローキー管理部１３、パケット遅延部１４、遅延値計算部１５を有する。
【００１５】
本実施の形態では、ISPがネットワークの境界ルータにおいて、P2P判断部１１がファイル共有系P2Pトラフィックを監視し、遅延値計算部１５が他ISP同士で通信を行っているようなファイル共有系P2Pトラフィックに対して、遅延を計算して付加させる。その際に、通信先ISPまでの経由ISP数が多いほど、与える遅延の値も大きくする。
【００１６】
以下、図４のフローチャートにおいて、自社ISP内のユーザaからパケットが送られてきたときの動作フローを、図５のフローチャートにおいて、他社ISP内のユーザbからパケットが送られてきたときの動作フローを説明する。
【００１７】
図４について、自ISP内のユーザaからパケットが到着した場合、まずP2P判断部１１Aに転送する（図４のステップ１０１）。
【００１８】
P2P判断部１１Aでは、送られてきたパケットの特徴から、パケットがファイル共有系P2Pトラフィックであるかどうかを判断する（図４のステップ１０２）。ファイル共有系P2Pと判断されなかった場合、そのパケットはそのままユーザbに転送する（図４のステップ１０９）。ファイル共有系P2Pであると判断された場合、パケットをハッシュ値計算部１２Aに転送する。
【００１９】
ハッシュ値計算部１２Aでは、予め用意したハッシュ関数に対して、{送信者（ユーザa）のIPアドレス，受信者（ユーザb）のIPアドレス，送信者（ユーザa）のポート番号，受信者（ユーザb）のポート番号}のフローキーを入力し、ハッシュ値を得る（図４のステップ１０３）。得られたハッシュ値が、フローキー管理部１３Aのフローテーブルにエントリされているかどうか確認する（図４のステップ１０４）。もし既にエントリされている場合、フローテーブルを参照して得られた遅延値の時間だけ、パケット遅延部１４Aにてパケットをキャッシュし、遅延を発生させる（図４のステップ１０５）。その後、パケットをユーザbに転送する（図４のステップ１０８）。
【００２０】
もし、ブローテーブルにエントリされておらず、新規である場合(ステップ１０４、No)、遅延値計算部１５Aに準備したマップを参照し、送信先ISPまでの経由ISP数を呼び出し、その数に応じた遅延値を決定する（図４のステップ１０６）。このとき、経由ISP数が大きいほど、遅延値も大きくなるようにする。得られた｛ハッシュ値，遅延値｝の組を、フロー管理部１３Aのフローテーブルに新しくエントリする（図４のステップ１０７）。その後、パケット遅延部１４Aにて遅延値の長さだけパケットをキャッシュし（図４のステップ１０５）、パケットをユーザbに転送する（図４のステップ１０８）。
【００２１】
一方、図５について、他ISPのユーザbからパケットが到着した場合、まずP2P判断部１１Bに転送する（図５のステップ２０１）。
【００２２】
P2P判断部１１Bでは、送られてきたパケットの特徴から、パケットがファイル共有系P2Pトラフィックであるかどうかを判断する（図５のステップ２０２）。ファイル共有系P2Pと判断されなかった場合、そのパケットはそのままユーザaに転送する（図５のステプ２０８）。ファイル共有系P2Pであると判断された場合、パケットをハッシュ値計算部１２Bに転送する。
【００２３】
ハッシュ値計算部１２Bでは、予め用意したハッシュ関数に対して、パケットの発着IP、発着ポート番号を入れ替えた{受信者（ユーザa）のIPアドレス，送信者（ユーザb）のIPアドレス，受信者（ユーザa）のポート番号，送信者（ユーザb）のポート番号}の逆転フローキーを入力し、ハッシュ値を得る（図５のステップ２０３）。得られたハッシュ値が、フローキー管理部１３Bのフローテーブルにエントリされているかどうか確認する（図５のステップ２０４）。もし既にエントリされている場合は(図５のステップ２０４、Yes)、フローテーブルを参照して得られた遅延値の時間だけ、パケット遅延部１４Bにてパケットをキャッシュし、遅延を発生させる（図５のステップ２０５）。その後、パケットをユーザaに転送する（図５のステップ２０８）。
【００２４】
もし新規である場合は(図５のステップ２０４、No)、遅延値計算部１５Bに準備したマップを参照し、送信元ISPまでの経由ISP数を呼び出し、その数に応じた遅延値を「実際にネットワーク上で発生した遅延」として、決定する（図５のステップ２０６）。なお、ここで、参照されるマップとは、送信元ISPに対してそのISPまでの経由ISP数を与えるテーブルである。このとき、経由ISP数が大きいほど、遅延値も大きくなるようにする。得られた｛ハッシュ値，遅延値｝の組を、フローキー管理部１３Bのフローテーブルに新しくエントリする（図５のステップ２０７）。その後、パケット遅延部１４Bにて遅延値の長さだけパケットをキャッシュし（図５のステップ２０５）、パケットをユーザaに転送する（図５のステップ２０８）。
【００２５】
上記のような処理を行うことで、P2Pアプリケーション自体の持つ最適化アルゴリズムにより、遅延の少ない同ISP内や近隣ISP内のピアが選択されやすくなり、ISPをまたぐようなファイル共有系P2Pトラフィックを減少させることが可能となる。
【００２６】
[第２の実施の形態]
本実施の形態では、前述の第１の実施の形態における制御手法で、遅延値計算部１５における遅延値の計算において、ISP間の境界ルータから送信先ピアまでのRTT(Round Trip Time)を「実際にネットワーク上で発生した遅延」として考慮し、RTTに追加して与えた遅延の和が、経由ISP数に応じた所望の遅延時間になるように遅延を与える場合について説明する。
【００２７】
キャッシュノードの構成は前述の第１の実施の形態と同様である。
【００２８】
図６にユーザaからパケットが送られてきたときの動作フローを、図７にユーザbからパケットが送られてきたときの動作フローを示す。
【００２９】
本実施の形態では、データをダウンロードする側からのパケットには遅延を与えず、データをアップロードする側のみのパケットに対し遅延を与える。
【００３０】
例えば、ユーザaがユーザbからデータをダウンロードする場合、キャッシュノード１０Aにおいて、ユーザaからのパケットには遅延を与えず、その代わりにユーザaからパケットが到着した時刻をタイムスタンプとしてパケット遅延部１４A内のメモリ（図示せず）に記録する（図６のステップ３０５）。その他の動作は図４の動作と同様である。
【００３１】
一方で、キャッシュノード１０Bにおいて、ユーザaが送ったパケットのACK番号と同じSEQ番号のパケットがユーザbから届いた場合、パケット遅延部１４Bは、ユーザaのパケットが届いたタイムスタンプと、ユーザbのパケットが届いたタイムスタンプから、ISP間の境界ルータからユーザbまでのRTTを「実際にネットワーク上で発生した遅延」として計算する（図７のステップ４０５）。ここで、RTTが200msecであったとし、遅延値計算部１５Bで求められたユーザaとユーザb間の経由ISP数に基づき与えるべき遅延が2000msecであったとすると、パケット遅延部１４Bはユーザbからのパケットに対して2000-200=1800msecの遅延を与える（図７のステップ４０６）。
【００３２】
［第３の実施の形態］
本実施の形態における境界ルータ１０A，１０Bは図２，図３の構成と同様である。
【００３３】
本実施の形態では、前述の第１の実施の形態における制御手法で、遅延値計算１５における遅延値の計算において、経由ISP数に加えて、ISP間の境界ルータにおけるルータの輻輳度合いを考慮し、ルータのバッファの占有率が高いほど大きな遅延を与える。
【００３４】
本実施の形態では、パケットの損失率を考慮した遅延を計算する。
【００３５】
例えば、ユーザaがユーザbからデータをダウンロードする場合、ユーザaから送られてきたパケットのACK番号から、その時点までのISP間の境界ルータとユーザb間におけるパケットの損失率ｐを計算することができる。当該処理はキャッシュノード１０Aのパケット遅延部１４Aにおいて行う（図８のステップ５０６）。この時、パケット損失率ｐを考慮したISP間の境界ルータとユーザb間のネットワークで発生する遅延の期待値を、
【００３６】
【数１】
として求める。ユーザbからパケットが届いたとき、キャッシュノード１０Bのパケット遅延部１４Bはこのネットワークで発生する遅延の期待値を「実際にネットワーク上で発生した遅延」として考慮して、ネットワークで発生する遅延の期待値とパケット遅延部１４Bで与える遅延が所望の遅延時間になるように、パケット遅延部１４Bで遅延を与える。
【００３７】
例えば、パケットの損失率がｐ=0.01であり、RTTが200msec、遅延値計算部１５Bで求められた所望の遅延が2000msecであったとすると、パケット遅延部１４Bはユーザbから届いたパケットに対して、
【００３８】
【数２】
の遅延を与える。
【００３９】
［第４の実施の形態］
本実施の形態における境界ルータ１０A，１０Bは図２，図３の構成と同様である。
【００４０】
本実施の形態では、前述の第１の実施の形態の遅延値の計算を、経由ISP数のみならず、ISP間の境界ルータの輻輳状態を加味して行う。
【００４１】
例えば、第１の実施の形態により、ISP数に基づいて計算された規定の遅延値を2000msecとする。ルータのバッファサイズが10GBであったとし、そのうち5GBパケットで埋められているとすると、パケット遅延部１４は以下の計算を行い、パケットに対し、
【００４２】
【数３】
の遅延を与える。このように遅延を与えることで、経由する境界ルータが混雑しているようなピアは選択されにくくなり、ルータの負荷を軽減させることができる。
【００４３】
［第５の実施の形態］
図９は、本発明の第５の実施の形態におけるシステム構成例を示す。
【００４４】
本実施の形態では、前述の第１の実施の形態における遅延値の計算において、経由ISP数に基づいて計算された遅延値に対して、ユーザがレアピースをダウンロードしている場合には遅延値を小さくし、同ISP内にピースが多く存在する場合には、遅延値を大きくする制御を行う。そうすることによって、ユーザのダウンロード時間に大きな影響を与えることなく、トラヒックをISP内に閉じ込めることができる。
【００４５】
図１０は、本発明の第５の実施の形態におけるアクセス網境界ルータの構成を示し、図１１は、ISP境界ルータの構成を示す。
【００４６】
図１０に示すアクセス網境界ルータ２０Aは、P2P判断部２１A、ピースハッシュ値計算部２２A、ピーステーブル管理部２３Aを有する。図１１に示すISP境界ルータ２０Bは、P2P判断部２１B、ピースハッシュ値計算部２２B、ピーステーブル管理部２３B、ハッシュ値計算部２４、フローキー管理部２５、遅延値計算部２６、パケット遅延部２７を有する。
【００４７】
例えば、図９に示すシステムにおいて、アクセス網境界ルータ２０Aは、P2P判断部２１Aが、アクセス網側からのデータを含むパケットを受信し、ファイル共有系P2Pトラフィックであると判断した場合、ピースハッシュ値計算部２２Aにおいてデータ部分を予め用意したハッシュ関数を用いてハッシュ化する。アクセス網境界ルータ２０Aは、ピーステーブル管理部２３Aにおいてハッシュ値ごとにパケットを送信したユニークユーザ数をカウントしたピーステーブル({ハッシュ値，当該データを送信したISP境界ルータ内のユーザ数}の組)を、常にISP境界ルータのピーステーブル管理部２３Bと共有する。
【００４８】
共有の方法としては、各アクセス網境界ルータ２０Aと各ISP境界ルータ２０Bのピーステーブル管理部２３A、２３Bが相互に直接ピーステーブルの変更情報を送信し合い、各々が最新のピーステーブル情報を更新することで共有する場合と、ピーステーブル共有用のサーバを別途用意し、各アクセス網境界ルータ２０Aと各ISP境界ルータ２０Bは変更情報を一度ピーステーブル共有用のサーバ（図示せず）に送信して、ピーステーブル共有用のサーバは送られてきた変更情報を元に最新のピーステーブル情報を更新し、それを各アクセス網境界ルータ２０Aと各ISP境界ルータ２０Bに送信することで共有をする場合の二通りを考える。また、それぞれの場合における、共有するタイミングについても、ピーステーブルに変更があった際に共有を行う場合と、5分に1回のように決められた時間間隔で共有を行う場合の二通りを考える。
【００４９】
ISP境界ルータ２０Bは、他ISPのユーザbから受け取った、データを含むパケットについて、P2P判断部２１Bにおいて、ファイル共有系P2Pトラフィックであると判断された場合、ハッシュ値計算部２４でデータ部分をアクセス網境界ルータ２０Aと同様のハッシュ関数を用いてハッシュ化する。遅延値計算部２６は、ハッシュ値を、アクセス網境界ルータ２０Aから受け取ったピーステーブルで参照し、アクセス網境界ルータ２０Aが同じデータを多くのユーザから受け取っていた場合、ユーザbが送信しようとしているファイルのピースはISP A内に多く存在するとみなし、遅延値を大きくする。
【００５０】
例えば、規定の遅延値を2000msecとする。ある係数を50と設定し、ユーザaがユーザbからダウンロードしようとしているデータが、ISP Aのアクセス網境界ルータに10ユーザから届いていたとする（ISP A内に同じピースが少ないレアピースである）。その時、与える遅延値は、
【００５１】
【数４】
となる。
【００５２】
また、ISP Aのアクセス網境界ルータ２０Aに同じデータが100ユーザから届いていたとする（ISP A内に同じピースを持つユーザが多く存在する）。その時、与える遅延値は、
【００５３】
【数５】
となる。
【００５４】
上記のように、ISPはP2Pアプリケーション自身と直接連携することなく、ISP間のP2Pトラフィックの削減を実現する。
【００５５】
実際に、第１の実施の形態の手法について、図１２のようなトポロジ上でシミュレーションを行った結果を図１３に示す。シミュレーション時のパラメータは、
・総ピア数：500（AS1〜AS5に100ずつ）
・総シーダ数：5（AS1〜AS5に1ずつ）
・交換するファイル：50MB
（256KBのチャンクが200，チャンクは16KBのピースが16）
である。また、本シミュレーションにおいては、経由AS数に関わらず与える遅延は一定とした。
【００５６】
図１３のグラフは、横軸がシミュレーション時間（sec）を示し、縦軸がトラフィック量（ピース数）である。白いグラフは、AS内を流れるピース数を表しており、黒いグラフは、AS間を流れるピース数を表している。同図（Ａ）は、AS間のトラフィックに与える遅延を50msecのまま固定した時のグラフであり、同図（Ｂ）は、シミュレーション時間1000msecにおいて、AS間のトラフィックに与える遅延を50msecから2000msecに変更した時のグラフである。同図（Ｂ）より、大きな遅延を与えることによってAS間のトラフィックが大きく減少していることが確認できる。
【００５７】
上記の図２、図３に示す第１〜５の実施の形態の各動作をプログラムとして構築し、境界ルータとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通されることが可能である。
【００５８】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００５９】
１０A，１０B 境界ルータ
１１A，１１B P2P判断部
１２A，１２B ハッシュ値計算部
１３A，１３B フローキー管理部
１４A，１４B パケット遅延部
１５A，１５B 遅延値計算部
２０A アクセス網境界ルータ
２０B ISP境界ルータ
２１A，２１B P2P判断部
２２A，２２B ピースハッシュ値計算部
２３A，２３B ピーステーブル管理部
２４ ハッシュ値計算部
２５ フローキー管理部
２６ 遅延値計算部
２７ パケット遅延部
【技術分野】
【０００１】
本発明は、P2P（Point to Point）トラヒック制御システム及び方法に係り、特に、P2Pトラフィックに対して故意に遅延を与えることのみによってISP(Internet Services Provider)間のP2Pトラフィックの削減を実現するためのP2Pトラヒック制御システム及び方法に関する。
【背景技術】
【０００２】
インターネットの利用形態が多様化するに伴い、トラヒックがネットワークに与える影響についての研究はより重要となってきている。実トラヒックデータの分析結果に関する報告は多く上げられており、それらによると、近年ではYouTubeのようなウェブベースの動画コンテンツ配信サービスの発展によって、過去にネットワークを支配していたP2Pトラヒックに代わり、HTTPトラヒックが支配的になってきているとされている（例えば、非特許文献１，２，３参照）。しかし、国内においては、いまだP2Pトラヒックはネットワーク全体のトラヒックに大きな影響を与えており、一部のユーザによる大容量のトラヒック生成が大きな問題となっている(例えば、非特許文献４参照)。また、先述のコンテンツ配信についても、サーバ側の容量や負荷の問題を抱えるクライアントサーバ型に代わる、P2P型での配信モデルが注目を浴びており（例えば、非特許文献５，６参照）、P2Pトラヒックがネットワークに与える影響は、いまだ大きな問題であると言える。
【０００３】
このような問題に対し、一定以上のトラヒックを送出するユーザに対して帯域制御を行うといった対策について検討されている（例えば、非特許文献７参照）。一方で、上記のように規制をする代わりに、ISP（IPネットワーク側）とP2P事業者（オーバレイ側）で協調するアプローチ（P4Pと呼ばれる）も検討されている（例えば、非特許文献８参照）。この方法では、ISP側がIPネットワークのトポロジやリンク負荷情報を開示し、特定のリンクに負荷が集中しないようなダウンロード元ノードをP2Pが選択できるようにする．こうすることにより、P2Pアプリケーションにとって高品質（ダウンロード時間の短縮）であり、ISPにとって負荷分散を図ることが可能となる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Cisco Visual Networking Index: Forecast and Methodology, 2008-2013, (http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf)
【非特許文献２】Gregor Maier, Anja Feldmann, Vern Paxson, Mark Allman, "On dominant characteristics of residential broadband internet traffic," ACM IMC, 2009.
【非特許文献３】Nate Anderson, "The YouTube effect: HTTP traffic now eclipses P2P," http://arstechnica.com/old/content/2007/06/the-youtube-effect-http-traffic-now-eclipses-p2p.ars)
【非特許文献４】Kenjiro Cho, Kensuke Fukuda, Hiroshi Esaki, Akira Kato, "Observing slow crustal movement in residential user traffic," ACM CoNEXT, 2008.
【非特許文献５】Ryoichi Kawahara, Noriaki Kamiyama, Tatsuya Mori, Haruhisa Hasegawa, "Performance evaluation of peer-assisted content distribution," IEEE CCNC, 2011.
【非特許文献６】Dongyan Xu, Sunil Suresh Kulkarni, Catherine Rosenberg, Heung-Keung Chai, "Analysis of a CDN-P2P Hybrid Architecture for Cost-Effective Streaming Media Distribution," Multimedia Systems, 2006.
【非特許文献７】帯域制御ガイドライン(http://www.jaipa.or.jp/other/bandwidth/info_080523.html)
【非特許文献８】Haiyong Xie, Y. Richard Yang, "P4P: Provider Portal for Applications" SIGCOMM, 2008.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の非特許文献８の手法では、P2PアプリケーションとISPが協調動作する必要があり、P2Pアプリケーションに対してそのようにさせるインセンティブを与えなければならないという問題と、ISPに対してネットワークの情報を開示させるための仕組みを用意しなければならない、という課題があった。
【０００６】
本発明は、上記の点に鑑みなされたもので、ISPがP2Pアプリケーション自体と直接連携することなしに、ISP間で交換されるP2Pトラフィックの削減を実現することが可能なP2Pトラヒック制御システムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明は、ネットワークの境界ルータにおいて、ISP(Internet Service Provider)がP2P(Point to Point)トラフィックを監視し、他ISPと同士で通信を行っているP2Pトラフィックを制御するトラヒック制御システムであって、
前記境界ルータは、
受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定するP2P判断手段と、
通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなる遅延値を計算し、記憶手段に格納する遅延値算出手段と、
前記記憶手段に格納されている遅延値を経由ISP数に応じた所望の遅延時間として、前記ファイル共有系P2Pトラフィックに対して付加して送出するパケット遅延手段と、
を有する。
【発明の効果】
【０００８】
本発明によれば、ネットワークの境界ルータにおいてISPがP2Pトラフィックを監視し、故意に遅延を付加することにより、他のISPがP2Pアプリケーション自体と直接連携することなしに、ISP間で交換されるP2Pトラフィックの削減を実現する。
【図面の簡単な説明】
【０００９】
【図１】本発明が適用されるネットワーク基本構成の一例である。
【図２】本発明の第１の実施の形態における境界ルータの構成例（自社ISP内からパケット受信）である。
【図３】本発明の第１の実施の形態における境界ルータの構成例（他社ISP内からパケット受信）である。
【図４】本発明の第１の実施の形態における図２の境界ルータの動作のフローチャートである。
【図５】本発明の第１の実施の形態における図３の境界ルータの動作のフローチャートである。
【図６】本発明の第２の実施の形態における図２の境界ルータの動作のフローチャートである。
【図７】本発明の第２の実施の形態における図３における境界ルータの動作のフローチャートである。
【図８】本発明の第３の実施の形態における図２の境界ルータの動作のフローチャートである。
【図９】本発明の第５の実施の形態におけるシステム構成例である。
【図１０】本発明の第５の実施の形態におけるアクセス網境界ルータの構成図である。
【図１１】本発明の第５の実施の形態におけるISP境界ルータの構成図である。
【図１２】本発明のシミュレーショントポロジの例である。
【図１３】本発明のシミュレーション結果を示すグラフである。
【発明を実施するための形態】
【００１０】
以下図面と共に、本発明の実施の形態を説明する。
【００１１】
[第１の実施の形態]
図１は、本発明が適用されるネットワークの基本構成の一例を示す。
【００１２】
ISP(ISP A，ISP B)は、キャッシュ機能を有したキャッシュノードをネットワークの境界ルータとして配置するものとする。
【００１３】
図２および図３は、キャッシュノード(境界ルータ)の構成例を示すブロック図である。図２は、自社ISP内ユーザaからパケットが送られてきたときの境界ルータのブロック図であり、図３は、他社ISP内ユーザbからパケットが送られてきたときの境界ルータのブロック図であり、パケット送信元が自社ISP内ユーザか他社ISP内ユーザかによって分けているのみであり、同一の装置である。
【００１４】
図２、図３に示すキャッシュノードは、P2P判断部１１、ハッシュ値計算部１２、フローキー管理部１３、パケット遅延部１４、遅延値計算部１５を有する。
【００１５】
本実施の形態では、ISPがネットワークの境界ルータにおいて、P2P判断部１１がファイル共有系P2Pトラフィックを監視し、遅延値計算部１５が他ISP同士で通信を行っているようなファイル共有系P2Pトラフィックに対して、遅延を計算して付加させる。その際に、通信先ISPまでの経由ISP数が多いほど、与える遅延の値も大きくする。
【００１６】
以下、図４のフローチャートにおいて、自社ISP内のユーザaからパケットが送られてきたときの動作フローを、図５のフローチャートにおいて、他社ISP内のユーザbからパケットが送られてきたときの動作フローを説明する。
【００１７】
図４について、自ISP内のユーザaからパケットが到着した場合、まずP2P判断部１１Aに転送する（図４のステップ１０１）。
【００１８】
P2P判断部１１Aでは、送られてきたパケットの特徴から、パケットがファイル共有系P2Pトラフィックであるかどうかを判断する（図４のステップ１０２）。ファイル共有系P2Pと判断されなかった場合、そのパケットはそのままユーザbに転送する（図４のステップ１０９）。ファイル共有系P2Pであると判断された場合、パケットをハッシュ値計算部１２Aに転送する。
【００１９】
ハッシュ値計算部１２Aでは、予め用意したハッシュ関数に対して、{送信者（ユーザa）のIPアドレス，受信者（ユーザb）のIPアドレス，送信者（ユーザa）のポート番号，受信者（ユーザb）のポート番号}のフローキーを入力し、ハッシュ値を得る（図４のステップ１０３）。得られたハッシュ値が、フローキー管理部１３Aのフローテーブルにエントリされているかどうか確認する（図４のステップ１０４）。もし既にエントリされている場合、フローテーブルを参照して得られた遅延値の時間だけ、パケット遅延部１４Aにてパケットをキャッシュし、遅延を発生させる（図４のステップ１０５）。その後、パケットをユーザbに転送する（図４のステップ１０８）。
【００２０】
もし、ブローテーブルにエントリされておらず、新規である場合(ステップ１０４、No)、遅延値計算部１５Aに準備したマップを参照し、送信先ISPまでの経由ISP数を呼び出し、その数に応じた遅延値を決定する（図４のステップ１０６）。このとき、経由ISP数が大きいほど、遅延値も大きくなるようにする。得られた｛ハッシュ値，遅延値｝の組を、フロー管理部１３Aのフローテーブルに新しくエントリする（図４のステップ１０７）。その後、パケット遅延部１４Aにて遅延値の長さだけパケットをキャッシュし（図４のステップ１０５）、パケットをユーザbに転送する（図４のステップ１０８）。
【００２１】
一方、図５について、他ISPのユーザbからパケットが到着した場合、まずP2P判断部１１Bに転送する（図５のステップ２０１）。
【００２２】
P2P判断部１１Bでは、送られてきたパケットの特徴から、パケットがファイル共有系P2Pトラフィックであるかどうかを判断する（図５のステップ２０２）。ファイル共有系P2Pと判断されなかった場合、そのパケットはそのままユーザaに転送する（図５のステプ２０８）。ファイル共有系P2Pであると判断された場合、パケットをハッシュ値計算部１２Bに転送する。
【００２３】
ハッシュ値計算部１２Bでは、予め用意したハッシュ関数に対して、パケットの発着IP、発着ポート番号を入れ替えた{受信者（ユーザa）のIPアドレス，送信者（ユーザb）のIPアドレス，受信者（ユーザa）のポート番号，送信者（ユーザb）のポート番号}の逆転フローキーを入力し、ハッシュ値を得る（図５のステップ２０３）。得られたハッシュ値が、フローキー管理部１３Bのフローテーブルにエントリされているかどうか確認する（図５のステップ２０４）。もし既にエントリされている場合は(図５のステップ２０４、Yes)、フローテーブルを参照して得られた遅延値の時間だけ、パケット遅延部１４Bにてパケットをキャッシュし、遅延を発生させる（図５のステップ２０５）。その後、パケットをユーザaに転送する（図５のステップ２０８）。
【００２４】
もし新規である場合は(図５のステップ２０４、No)、遅延値計算部１５Bに準備したマップを参照し、送信元ISPまでの経由ISP数を呼び出し、その数に応じた遅延値を「実際にネットワーク上で発生した遅延」として、決定する（図５のステップ２０６）。なお、ここで、参照されるマップとは、送信元ISPに対してそのISPまでの経由ISP数を与えるテーブルである。このとき、経由ISP数が大きいほど、遅延値も大きくなるようにする。得られた｛ハッシュ値，遅延値｝の組を、フローキー管理部１３Bのフローテーブルに新しくエントリする（図５のステップ２０７）。その後、パケット遅延部１４Bにて遅延値の長さだけパケットをキャッシュし（図５のステップ２０５）、パケットをユーザaに転送する（図５のステップ２０８）。
【００２５】
上記のような処理を行うことで、P2Pアプリケーション自体の持つ最適化アルゴリズムにより、遅延の少ない同ISP内や近隣ISP内のピアが選択されやすくなり、ISPをまたぐようなファイル共有系P2Pトラフィックを減少させることが可能となる。
【００２６】
[第２の実施の形態]
本実施の形態では、前述の第１の実施の形態における制御手法で、遅延値計算部１５における遅延値の計算において、ISP間の境界ルータから送信先ピアまでのRTT(Round Trip Time)を「実際にネットワーク上で発生した遅延」として考慮し、RTTに追加して与えた遅延の和が、経由ISP数に応じた所望の遅延時間になるように遅延を与える場合について説明する。
【００２７】
キャッシュノードの構成は前述の第１の実施の形態と同様である。
【００２８】
図６にユーザaからパケットが送られてきたときの動作フローを、図７にユーザbからパケットが送られてきたときの動作フローを示す。
【００２９】
本実施の形態では、データをダウンロードする側からのパケットには遅延を与えず、データをアップロードする側のみのパケットに対し遅延を与える。
【００３０】
例えば、ユーザaがユーザbからデータをダウンロードする場合、キャッシュノード１０Aにおいて、ユーザaからのパケットには遅延を与えず、その代わりにユーザaからパケットが到着した時刻をタイムスタンプとしてパケット遅延部１４A内のメモリ（図示せず）に記録する（図６のステップ３０５）。その他の動作は図４の動作と同様である。
【００３１】
一方で、キャッシュノード１０Bにおいて、ユーザaが送ったパケットのACK番号と同じSEQ番号のパケットがユーザbから届いた場合、パケット遅延部１４Bは、ユーザaのパケットが届いたタイムスタンプと、ユーザbのパケットが届いたタイムスタンプから、ISP間の境界ルータからユーザbまでのRTTを「実際にネットワーク上で発生した遅延」として計算する（図７のステップ４０５）。ここで、RTTが200msecであったとし、遅延値計算部１５Bで求められたユーザaとユーザb間の経由ISP数に基づき与えるべき遅延が2000msecであったとすると、パケット遅延部１４Bはユーザbからのパケットに対して2000-200=1800msecの遅延を与える（図７のステップ４０６）。
【００３２】
［第３の実施の形態］
本実施の形態における境界ルータ１０A，１０Bは図２，図３の構成と同様である。
【００３３】
本実施の形態では、前述の第１の実施の形態における制御手法で、遅延値計算１５における遅延値の計算において、経由ISP数に加えて、ISP間の境界ルータにおけるルータの輻輳度合いを考慮し、ルータのバッファの占有率が高いほど大きな遅延を与える。
【００３４】
本実施の形態では、パケットの損失率を考慮した遅延を計算する。
【００３５】
例えば、ユーザaがユーザbからデータをダウンロードする場合、ユーザaから送られてきたパケットのACK番号から、その時点までのISP間の境界ルータとユーザb間におけるパケットの損失率ｐを計算することができる。当該処理はキャッシュノード１０Aのパケット遅延部１４Aにおいて行う（図８のステップ５０６）。この時、パケット損失率ｐを考慮したISP間の境界ルータとユーザb間のネットワークで発生する遅延の期待値を、
【００３６】
【数１】
として求める。ユーザbからパケットが届いたとき、キャッシュノード１０Bのパケット遅延部１４Bはこのネットワークで発生する遅延の期待値を「実際にネットワーク上で発生した遅延」として考慮して、ネットワークで発生する遅延の期待値とパケット遅延部１４Bで与える遅延が所望の遅延時間になるように、パケット遅延部１４Bで遅延を与える。
【００３７】
例えば、パケットの損失率がｐ=0.01であり、RTTが200msec、遅延値計算部１５Bで求められた所望の遅延が2000msecであったとすると、パケット遅延部１４Bはユーザbから届いたパケットに対して、
【００３８】
【数２】
の遅延を与える。
【００３９】
［第４の実施の形態］
本実施の形態における境界ルータ１０A，１０Bは図２，図３の構成と同様である。
【００４０】
本実施の形態では、前述の第１の実施の形態の遅延値の計算を、経由ISP数のみならず、ISP間の境界ルータの輻輳状態を加味して行う。
【００４１】
例えば、第１の実施の形態により、ISP数に基づいて計算された規定の遅延値を2000msecとする。ルータのバッファサイズが10GBであったとし、そのうち5GBパケットで埋められているとすると、パケット遅延部１４は以下の計算を行い、パケットに対し、
【００４２】
【数３】
の遅延を与える。このように遅延を与えることで、経由する境界ルータが混雑しているようなピアは選択されにくくなり、ルータの負荷を軽減させることができる。
【００４３】
［第５の実施の形態］
図９は、本発明の第５の実施の形態におけるシステム構成例を示す。
【００４４】
本実施の形態では、前述の第１の実施の形態における遅延値の計算において、経由ISP数に基づいて計算された遅延値に対して、ユーザがレアピースをダウンロードしている場合には遅延値を小さくし、同ISP内にピースが多く存在する場合には、遅延値を大きくする制御を行う。そうすることによって、ユーザのダウンロード時間に大きな影響を与えることなく、トラヒックをISP内に閉じ込めることができる。
【００４５】
図１０は、本発明の第５の実施の形態におけるアクセス網境界ルータの構成を示し、図１１は、ISP境界ルータの構成を示す。
【００４６】
図１０に示すアクセス網境界ルータ２０Aは、P2P判断部２１A、ピースハッシュ値計算部２２A、ピーステーブル管理部２３Aを有する。図１１に示すISP境界ルータ２０Bは、P2P判断部２１B、ピースハッシュ値計算部２２B、ピーステーブル管理部２３B、ハッシュ値計算部２４、フローキー管理部２５、遅延値計算部２６、パケット遅延部２７を有する。
【００４７】
例えば、図９に示すシステムにおいて、アクセス網境界ルータ２０Aは、P2P判断部２１Aが、アクセス網側からのデータを含むパケットを受信し、ファイル共有系P2Pトラフィックであると判断した場合、ピースハッシュ値計算部２２Aにおいてデータ部分を予め用意したハッシュ関数を用いてハッシュ化する。アクセス網境界ルータ２０Aは、ピーステーブル管理部２３Aにおいてハッシュ値ごとにパケットを送信したユニークユーザ数をカウントしたピーステーブル({ハッシュ値，当該データを送信したISP境界ルータ内のユーザ数}の組)を、常にISP境界ルータのピーステーブル管理部２３Bと共有する。
【００４８】
共有の方法としては、各アクセス網境界ルータ２０Aと各ISP境界ルータ２０Bのピーステーブル管理部２３A、２３Bが相互に直接ピーステーブルの変更情報を送信し合い、各々が最新のピーステーブル情報を更新することで共有する場合と、ピーステーブル共有用のサーバを別途用意し、各アクセス網境界ルータ２０Aと各ISP境界ルータ２０Bは変更情報を一度ピーステーブル共有用のサーバ（図示せず）に送信して、ピーステーブル共有用のサーバは送られてきた変更情報を元に最新のピーステーブル情報を更新し、それを各アクセス網境界ルータ２０Aと各ISP境界ルータ２０Bに送信することで共有をする場合の二通りを考える。また、それぞれの場合における、共有するタイミングについても、ピーステーブルに変更があった際に共有を行う場合と、5分に1回のように決められた時間間隔で共有を行う場合の二通りを考える。
【００４９】
ISP境界ルータ２０Bは、他ISPのユーザbから受け取った、データを含むパケットについて、P2P判断部２１Bにおいて、ファイル共有系P2Pトラフィックであると判断された場合、ハッシュ値計算部２４でデータ部分をアクセス網境界ルータ２０Aと同様のハッシュ関数を用いてハッシュ化する。遅延値計算部２６は、ハッシュ値を、アクセス網境界ルータ２０Aから受け取ったピーステーブルで参照し、アクセス網境界ルータ２０Aが同じデータを多くのユーザから受け取っていた場合、ユーザbが送信しようとしているファイルのピースはISP A内に多く存在するとみなし、遅延値を大きくする。
【００５０】
例えば、規定の遅延値を2000msecとする。ある係数を50と設定し、ユーザaがユーザbからダウンロードしようとしているデータが、ISP Aのアクセス網境界ルータに10ユーザから届いていたとする（ISP A内に同じピースが少ないレアピースである）。その時、与える遅延値は、
【００５１】
【数４】
となる。
【００５２】
また、ISP Aのアクセス網境界ルータ２０Aに同じデータが100ユーザから届いていたとする（ISP A内に同じピースを持つユーザが多く存在する）。その時、与える遅延値は、
【００５３】
【数５】
となる。
【００５４】
上記のように、ISPはP2Pアプリケーション自身と直接連携することなく、ISP間のP2Pトラフィックの削減を実現する。
【００５５】
実際に、第１の実施の形態の手法について、図１２のようなトポロジ上でシミュレーションを行った結果を図１３に示す。シミュレーション時のパラメータは、
・総ピア数：500（AS1〜AS5に100ずつ）
・総シーダ数：5（AS1〜AS5に1ずつ）
・交換するファイル：50MB
（256KBのチャンクが200，チャンクは16KBのピースが16）
である。また、本シミュレーションにおいては、経由AS数に関わらず与える遅延は一定とした。
【００５６】
図１３のグラフは、横軸がシミュレーション時間（sec）を示し、縦軸がトラフィック量（ピース数）である。白いグラフは、AS内を流れるピース数を表しており、黒いグラフは、AS間を流れるピース数を表している。同図（Ａ）は、AS間のトラフィックに与える遅延を50msecのまま固定した時のグラフであり、同図（Ｂ）は、シミュレーション時間1000msecにおいて、AS間のトラフィックに与える遅延を50msecから2000msecに変更した時のグラフである。同図（Ｂ）より、大きな遅延を与えることによってAS間のトラフィックが大きく減少していることが確認できる。
【００５７】
上記の図２、図３に示す第１〜５の実施の形態の各動作をプログラムとして構築し、境界ルータとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通されることが可能である。
【００５８】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００５９】
１０A，１０B 境界ルータ
１１A，１１B P2P判断部
１２A，１２B ハッシュ値計算部
１３A，１３B フローキー管理部
１４A，１４B パケット遅延部
１５A，１５B 遅延値計算部
２０A アクセス網境界ルータ
２０B ISP境界ルータ
２１A，２１B P2P判断部
２２A，２２B ピースハッシュ値計算部
２３A，２３B ピーステーブル管理部
２４ ハッシュ値計算部
２５ フローキー管理部
２６ 遅延値計算部
２７ パケット遅延部
【特許請求の範囲】
【請求項１】
ネットワークの境界ルータにおいて、ISP(Internet Service Provider)がP2P(Point to Point)トラフィックを監視し、他ISPと同士で通信を行っているP2Pトラフィックを制御するトラヒック制御システムであって、
前記境界ルータは、
受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定するP2P判断手段と、
通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなる遅延値を計算し、記憶手段に格納する遅延値算出手段と、
前記記憶手段に格納されている遅延値を経由ISP数に応じた所望の遅延時間として、前記ファイル共有系P2Pトラフィックに対して付加して送出するパケット遅延手段と、
を有することを特徴とするトラフィック制御システム。
【請求項２】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記ISP間の境界ルータから送信元ピアまでのRTT(Round Trip Time)を求め、前記記憶手段に格納されている前期遅延値から該RTTを引いた値を、前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項３】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記ISP間の境界ルータから送信先ピアまでのRTTとパケット損失率を求め、前記記憶手段に格納されている前記遅延値、該RTT、該パケット損失率から該パケット損失率に基づいて、ネットワークで発生する遅延の期待値を求め、該期待値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項４】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記ISP間の境界ルータにおけるルータの輻輳度合いを取得し、前記記憶手段に格納されている前記遅延値に対し、ルータのバッファの占有率が高いほど値が大きくなる遅延値を求め、該遅延値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項５】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記記憶手段に格納されている前記遅延値に対し、前記ISP内に存在するピースの数を取得し、レアピースをダウンロードしているユーザに対しては与える遅延を小さく、同ISP内にピースを持つユーザが存在する場合には遅延を大きくする遅延値を求め、該遅延値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項６】
ネットワークの境界ルータにおいて、ISPがP2Pトラフィックを監視し、他ISPと同士で通信を行っているP2Pトラフィックを制御するトラヒック制御方法であって、
前記境界ルータにおいて、
受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定するP2P判断ステップと、
通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなる遅延値を計算し、記憶手段に格納する遅延値算出ステップと、
前記記憶手段に格納されている遅延値を経由ISP数に応じた所望の遅延時間として、前記ファイル共有系P2Pトラフィックに対して付加して送出するパケット遅延ステップと、
を有することを特徴とするトラフィック制御方法。
【請求項７】
前記パケット遅延ステップにおいて、
前記遅延値を計算する際に、前記ISP間の境界ルータから送信元ピアまでのRTT(Round Trip Time)を求め、前記記憶手段に格納されている前期遅延値から該RTTを引いた値を、前記ファイル共有系P2Pトラフィックに与える遅延時間とする
請求項６記載のトラフィック制御方法。
【請求項８】
前記パケット遅延ステップにおいて、
前記遅延値を計算する際に、前記記憶手段に格納されている前記遅延値に対し、前記ISP内に存在するピースの数を取得し、レアピースをダウンロードしているユーザに対しては与える遅延を小さく、同ISP内にピースを持つユーザが存在する場合には遅延を大きくする遅延値を求め、該遅延値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする請求項６記載のトラフィック制御方法。
【請求項１】
ネットワークの境界ルータにおいて、ISP(Internet Service Provider)がP2P(Point to Point)トラフィックを監視し、他ISPと同士で通信を行っているP2Pトラフィックを制御するトラヒック制御システムであって、
前記境界ルータは、
受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定するP2P判断手段と、
通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなる遅延値を計算し、記憶手段に格納する遅延値算出手段と、
前記記憶手段に格納されている遅延値を経由ISP数に応じた所望の遅延時間として、前記ファイル共有系P2Pトラフィックに対して付加して送出するパケット遅延手段と、
を有することを特徴とするトラフィック制御システム。
【請求項２】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記ISP間の境界ルータから送信元ピアまでのRTT(Round Trip Time)を求め、前記記憶手段に格納されている前期遅延値から該RTTを引いた値を、前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項３】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記ISP間の境界ルータから送信先ピアまでのRTTとパケット損失率を求め、前記記憶手段に格納されている前記遅延値、該RTT、該パケット損失率から該パケット損失率に基づいて、ネットワークで発生する遅延の期待値を求め、該期待値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項４】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記ISP間の境界ルータにおけるルータの輻輳度合いを取得し、前記記憶手段に格納されている前記遅延値に対し、ルータのバッファの占有率が高いほど値が大きくなる遅延値を求め、該遅延値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項５】
前記パケット遅延手段は、
前記遅延値を計算する際に、前記記憶手段に格納されている前記遅延値に対し、前記ISP内に存在するピースの数を取得し、レアピースをダウンロードしているユーザに対しては与える遅延を小さく、同ISP内にピースを持つユーザが存在する場合には遅延を大きくする遅延値を求め、該遅延値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする手段を更に有する
請求項１記載のトラフィック制御システム。
【請求項６】
ネットワークの境界ルータにおいて、ISPがP2Pトラフィックを監視し、他ISPと同士で通信を行っているP2Pトラフィックを制御するトラヒック制御方法であって、
前記境界ルータにおいて、
受信したパケットがファイル共有系P2Pトラフィックであるか否かを判定するP2P判断ステップと、
通信先ISPまでの経由ISP数を取得し、該経由ISP数が多いほど、値が大きくなる遅延値を計算し、記憶手段に格納する遅延値算出ステップと、
前記記憶手段に格納されている遅延値を経由ISP数に応じた所望の遅延時間として、前記ファイル共有系P2Pトラフィックに対して付加して送出するパケット遅延ステップと、
を有することを特徴とするトラフィック制御方法。
【請求項７】
前記パケット遅延ステップにおいて、
前記遅延値を計算する際に、前記ISP間の境界ルータから送信元ピアまでのRTT(Round Trip Time)を求め、前記記憶手段に格納されている前期遅延値から該RTTを引いた値を、前記ファイル共有系P2Pトラフィックに与える遅延時間とする
請求項６記載のトラフィック制御方法。
【請求項８】
前記パケット遅延ステップにおいて、
前記遅延値を計算する際に、前記記憶手段に格納されている前記遅延値に対し、前記ISP内に存在するピースの数を取得し、レアピースをダウンロードしているユーザに対しては与える遅延を小さく、同ISP内にピースを持つユーザが存在する場合には遅延を大きくする遅延値を求め、該遅延値を前記ファイル共有系P2Pトラフィックに与える遅延時間とする請求項６記載のトラフィック制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−７４５４２（Ｐ２０１３−７４５４２Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１１−２１３４６５（Ｐ２０１１−２１３４６５）
【出願日】平成２３年９月２８日（２０１１．９．２８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【出願人】（５０４１３７９１２）国立大学法人 東京大学 (1,942)
【Ｆターム（参考）】
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２３年９月２８日（２０１１．９．２８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【出願人】（５０４１３７９１２）国立大学法人 東京大学 (1,942)
【Ｆターム（参考）】
[ Back to top ]