JP6348377B2 - コンテンツ配信ネットワークの通信装置及びプログラム - Google Patents

コンテンツ配信ネットワークの通信装置及びプログラム Download PDF

Info

Publication number
JP6348377B2
JP6348377B2 JP2014172971A JP2014172971A JP6348377B2 JP 6348377 B2 JP6348377 B2 JP 6348377B2 JP 2014172971 A JP2014172971 A JP 2014172971A JP 2014172971 A JP2014172971 A JP 2014172971A JP 6348377 B2 JP6348377 B2 JP 6348377B2
Authority
JP
Japan
Prior art keywords
content
request packet
value
threshold
segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014172971A
Other languages
English (en)
Other versions
JP2016048844A (ja
Inventor
クォック ディン グェン
クォック ディン グェン
浩平 杉山
浩平 杉山
敦士 田上
敦士 田上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2014172971A priority Critical patent/JP6348377B2/ja
Publication of JP2016048844A publication Critical patent/JP2016048844A/ja
Application granted granted Critical
Publication of JP6348377B2 publication Critical patent/JP6348377B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本開示は、コンテンツ配信ネットワークにおけるコンテンツの要求パケットの送信技術に関する。
コンテンツ名に基づきルーティングを行うネットワークが提案されている。特許文献1及び非特許文献1は、その様なネットワークの1つであるコンテンツ・セントリック・ネットワーク(CCN:Content Centric Networking)を開示している。CCNを構成する各転送装置は、コンテンツ名と、当該コンテンツ名が示すコンテンツを公開しているサーバ装置への経路(パス)を有するインタフェースとの対応関係を示すFIB(Foward Information Base)テーブルを維持している。各転送装置は、コンテンツを要求するインタレスト・パケット(要求パケット)を受信すると、当該インタレスト・パケットを、当該コンテンツを公開しているサーバ装置に向けて転送するため、FIBに基づきインタレスト・パケットを転送するインタフェースを決定する。
なお、CCNにおいて、コンテンツは、複数のチャンクと呼ばれるセグメントに分割され、コンテンツはセグメント毎に配信される。また、インタレスト・パケットも、要求するセグメントを指定するものである。したがって、コンテンツを取得する通信装置(クライアント装置)が1つのコンテンツの全体を取得する場合、当該クライアント装置は、異なるセグメントを要求する複数のインタレスト・パケットを送信することになる。よって、転送装置は、同じコンテンツの異なるセグメントを要求する複数のインタレスト・パケットの転送を行うことになる。なお、CCNにおいて、転送装置及びクライアント装置は、インタレスト・パケットを送信したインタフェースで、当該インタレスト・パケットで要求したセグメントを受信する。
ここで、クライアント装置や転送装置において、あるコンテンツを公開するサーバ装置に至る経路を有するインタフェースが複数ある場合、当該コンテンツに関する複数のインタレスト・パケットを複数の経路に分散させて転送することで、1つの経路のみに転送することと比較してスループットを高めることができる。非特許文献2は、あるコンテンツを公開するサーバ装置に至る経路を有するインタフェースが複数ある場合に、当該サーバ装置に向けて転送するインタレスト・パケットを送信するインタフェースをどの様に決定するかを開示している。
特開2009−277234号公報
V.Jacobson,et al.,"Networking Named Content",in Proceedings of ACM CoNEXT 2009,2009年12月 G.Carogiglio,et al.,"Optimal Multipath Congestion Control and Request Forwarding in Inforamtion−Centiric Network",in Proceedings of IEEE International Conference on Network Protocols,2013年 V.Jacobson,et al.,"Congestion Avoidance and Control",Symposium Proceedings on Communication Architectures and Protocols, ACM CoNEXT 1988、314−329
非特許文献2に記載の方法は、転送装置が、セグメントを含むデータ・パケットを転送する際に、当該データ・パケットに当該転送装置を示す情報(ラベル)を記録するものである。非特許文献2に記載の構成において、データ・パケットを受信したクライアント装置又は転送装置は、ラベルからサーバ装置に至る経路を把握し、各経路のラウンド・トリップ・タイム(RTT)に基づきインタレスト・パケットを送信するインタフェースを決定している。しかしながら、非特許文献2に記載の方法では、総ての転送装置及びクライアント装置に、ラベルを設定する機能とラベルを認識する機能を追加する必要がある。さらに、ネットワーク規模が大きくなると、転送装置及びクライアント装置は、多数の経路を管理しなければならなくなる。さらに、ネットワークにおいては、ネットワーク構成の変更による経路の生成及び消滅が繰り返されるため、非特許文献2に記載の方法では転送装置及びクライアント装置の処理負荷が大きくなる。
本発明は、簡易な方法でコンテンツを要求するパケットの送信インタフェースを決定し、コンテンツ配信のスループットを高めることができる通信装置を提供するものである。
本発明の一側面によると、コンテンツを1つ以上のセグメントに分割して配信し、コンテンツはセグメント単位で要求されるコンテンツ配信ネットワークの通信装置は、コンテンツと1つ以上のインタフェースの対応関係と、コンテンツ及びインタフェースの組み合わせに対する閾値及びウィンドウ・サイズを示す情報を含む経路情報を保持する保持手段と、コンテンツを要求する要求パケットを出力するインタフェースを、当該要求パケットで要求するコンテンツと前記経路情報とに基づき決定する決定手段と、を備えており、前記ウィンドウ・サイズは、対応するインタフェースから送信した、対応するコンテンツの要求パケットの送信数と、当該要求パケットの応答として受信したセグメント数との差の許容可能最大値を示し、前記閾値は、対応するインタフェースから送信した、対応するコンテンツの要求パケットの応答としてセグメントを受信できたか否かの判定に用いられ、前記通信装置は、さらに、要求パケットの応答としてセグメントを受信できたか否かに応じて前記経路情報の前記ウィンドウ・サイズを求めて前記経路情報に設定する第1設定手段と、要求パケットを送信してから、当該要求パケットの応答としてセグメントを受信するまでの第1時間に基づき前記閾値を求めて前記経路情報に設定する第2設定手段と、を備えており、前記第2設定手段は、前記第1時間の平均値と、前記第1時間の最大値と最小値の比と、を使用して前記閾値を求めることを特徴とする。
コンテンツ配信のスループットを高めることができる。
一実施形態によるコンテンツ配信ネットワークの構成図。 一実施形態によるクライアント装置の構成図。 一実施形態によるFIBを示す図。
以下、本発明の例示的な実施形態について図面を参照して説明する。なお、以下の各図においては実施形態の説明に必要ではない構成要素については図から省略する。また、以下の実施形態は例示であり本発明を実施形態の内容に限定するものではない。
図1は、本実施形態によるコンテンツ配信ネットワークの概略的な構成図である。なお、以下の説明において、コンテンツ配信ネットワークは、CCNであるものとする。しかしながら、本発明は、コンテンツを複数のセグメントに分割し、セグメント単位でコンテンツの要求と配信が行われ、かつ、コンテンツを要求する要求パケットと当該要求パケットの応答として配信されるセグメントが同一経路を通る、任意のネットワークに適用できる。転送装置21〜25は、コンテンツ配信ネットワークを形成し、コンテンツを公開するサーバ装置3と、コンテンツを取得する通信装置であるクライアント装置1が、コンテンツ配信ネットワークに接続されている。なお、以下の説明において、サーバ装置3は、コンテンツ名が"/動画/映画#1"であるコンテンツを公開しているものとする。また、上述した様に、サーバ装置3は、コンテンツを複数のセグメントに分割して保存している。クライアント装置1は、サーバ装置3から、コンテンツ名が"/動画/映画#1"であるコンテンツを取得する場合、コンテンツ名"/動画/映画#1"と、取得するセグメント番号を含むインタレスト・パケット(コンテンツの要求パケット)をサーバ装置3に向けて送信する。なお、クライアント装置1は、取得するコンテンツのセグメント番号については、1から順に増加させてゆくことができる。
図1の例において、クライアント装置1は、2つのインタフェースIF#1及びIF#2を有し、IF#1により転送装置21に接続し、IF#2により転送装置22に接続している。また、転送装置21からサーバ装置3に至る経路には転送装置24を経由する経路と、転送装置25を経由する経路の2つが存在する。同様に、転送装置22からサーバ装置3に至る経路には転送装置24を経由する経路と、転送装置25を経由する経路の2つが存在する。クライアント装置1は、サーバ装置3から、コンテンツ名が"/動画/映画#1"であるコンテンツを取得する場合、各セグメントの要求パケットを、IF#1とIF#2に分散させて送信することで、1つのインタフェースのみを使用する場合に比べて、より早くコンテンツを取得することができる。但し、コンテンツ配信のスループットは経路毎に異なり、コンテツを素早く取得するためには、要求パケットの送信割合は、経路のスループットに応じて決める必要がある。つまり、スループットの高い経路には、多くの要求パケットを送信し、スループットの低い経路には少ない要求パケットを送信する様に制御する必要がある。
このため、本実施形態では、あるコンテンツを取得するための要求パケットの送信数をインタフェース毎のウィンドウにより管理する。ここで、ウィンドウ・サイズは、送信した要求パケットに対応するセグメントを受信することなく、送信できる要求パケットの最大数である。例えば、図1の構成において、"/動画/映画#1"を取得するためのIF#1のウィンドウ・サイズが10である場合、クライアント装置1は、セグメントを全く受信していなくとも10個の要求パケットをIF#1から送信することができる。そして、10個の要求パケットを送信した段階で、セグメントを全く受信していないと、少なくとも1つのセグメントを受信するまで、更なる要求パケットを送信することはできない。つまり、インタフェース及びコンテンツに関連するウィンドウ・サイズは、当該コンテツを取得するために当該インタフェースから送信した要求パケットの総数と、当該インタフェースで受信した当該コンテンツのセグメントの総数の差の許容可能な最大値を示している。
なお、パケット・ロスを抑えつつ、経路のスループットを最大に利用するためには、スループットの高い経路に接続するインタフェースについてはウィンドウ・サイズを大きくし、スループットの低い経路に接続するインタフェースについてはウィンドウ・サイズを小さくする必要がある。また、スループットは時間と共に変動し得る。このため、本実施形態では、ウィンドウ・サイズを動的に変更する。例えば、要求パケットの応答としてセグメントを受信するとウィンドウ・サイズを増加させ、要求パケットに対するセグメントを受信しないとウィンドウ・サイズを減少させる。このウィンドウ・サイズの変更には、例えば、非特許文献3に記載の(AIMD:Additive−Increase Multiplicative−Decrease)アルゴリズムを使用できる。具体的には、要求パケットの応答としてセグメントを受信すると、そのときのウィンドウ・サイズに所定値を加えることで、ウィンドウ・サイズを増加させ、要求パケットに対するセグメントを受信しないと、そのときのウィンドウ・サイズに1より小さい所定の係数を乗じることでウィンドウ・サイズを減少させることができる。
なお、要求パケットに対するセグメントを受信しなかったとの判定、つまり、要求パケット又は当該要求パケットの応答としてのセグメントを運ぶデータ・パケットがパケット・ロスとなったか否かの判定には閾値を使用する。なお、閾値も、ウィドウ・サイズと同様に、取得するコンテンツとインタフェースの組み合わせ毎に設定される。具体的には、ある要求パケットを送信すると、クライアント装置1は、タイマを起動させ、タイマの値が閾値に達するまでに当該要求パケットの応答としてのセグメントを受信しないと、パケット・ロスが発生したと判定する。なお、この閾値を適切な値に設定しないと、パケット・ロスが発生していないにも関わらず、パケット・ロスが発生したとして、ウィドウ・サイズを減少させたり、パケット・ロスが発生しているにも拘らず、ウィンドウ・サイズを大きな値のままとしたりすることが発生する。このため、本実施形態では、この閾値を、要求パケットを送信してから、当該要求パケットの応答としてセグメントを受信するまでのラウンド・トリップ・タイム(RTT)の平均値に基づき求める。なお、平均値の算出に使用するRTTは、直近の所定数とする。つまり、RTTの移動平均値に基づき閾値を決定する。
例えば、クライアント装置1が複数のインタフェースでコンテンツ配信ネットワークに接続しているが、各インタフェースからサーバ装置3に至る経路が1つのみである場合には、上述した方法により適切なウィンドウ・サイズと、閾値が設定できる。しかしながら、図1に示す様に、一般的には、1つのインタフェースからサーバ装置3に至る経路は複数ある。図1の構成において、IF#1からサーバ装置3に至る経路は、転送装置24を経由する経路と、転送装置25を経由する経路の2つが存在する。したがって、あるインタフェースで観測されるRTTは、使用された経路により大きく変動する。したがって、閾値をRTTの移動平均のみで決定すると適切な値とならない。したがって、本実施形態においては、閾値tを、直近の所定数のRTTの平均値aと、その偏差dと、係数uから、t=a+udにより求める。
ここで、係数uは、直近の所定数のRTTの最大値をRa、最小値をRbとすると、u=Ra/Rbとして求める。つまり、直近の所定数のRTTの最大値Raと最小値Rbとの差が大きい程、閾値tは大きくなり、差が小さい程、閾値tは、平均値aに近づく。この構成により、クラインアント装置1は、要求パケットの送信を適切に制御し、コンテンツ配信ネットワークの帯域を適切に利用できる。
図2は、本実施形態によるクライアント装置1の構成図である。インタフェース部15は、複数のインタフェースの総称である。通信処理部14は、図3に示すFIBを保持しており、ユーザが所定のコンテンツを要求すると、当該コンテンツを要求する要求パケットを生成し、FIBに基づき当該要求パケットを送信するインタフェースを決定する。図3の例においては、"/動画/映画#1"を取得する要求パケットについては、IF#1又はIF#2に送信することが示されている。また、FIBには、"/動画/映画#1"について、IF#1とIF#2それぞれについて、閾値と、ウィンドウ・サイズが示されている。既に説明した様に、通信処理部14は、閾値に基づきパケット・ロスを判定する。また、ウィンドウ・サイズに基づき要求パケットを送信するインタフェースを決定する。例えば、ウィンドウ・サイズから、要求パケットをIF#1とIF#2に送信できる場合には、任意の方法にて選択したインタフェースから要求パケットを送信する。また、いずれか一方のインタフェースには送信可能であるが、他方のインタフェースから送信できない場合には、当該一方のインタフェースから送信する。さらに、両方のインタフェースから送信できない場合には、どちらかのインタフェースから送信可能となるまで要求パケットを保持しておき、送信可能となったインタフェースから要求パケットを送信する。
RTT測定部13は、コンテンツ及びインタフェースの組み合わせ毎にRTTを測定する。閾値判定部12は、RTT測定部13が測定するRTTに基づき閾値を求め、求めた閾値をFIBに設定する。なお、閾値の更新タイミングは、セグメントを受信したときとするが、所定の周期毎に行う構成でも、所定数のセグメントを受信する毎に行う構成であっても良い。ウィンドウ更新部11は、セグメントの受信に応じて、所定のアルゴリズムにより上述した様にウィンドウ・サイズを更新し、FIBに設定する。
なお、本実施形態において、閾値判定部12は、セグメントを受信すると、当該セグメントを含む、受信した直近の所定数のセグメントのRTTに基づき閾値を決定するが、直近の所定期間内に受信したセグメントのRTTに基づき閾値を決定しても良い。
なお、本発明によるクライアント装置1は、コンピュータをクライアント装置1として動作させるプログラムにより実現することができる。これらコンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて、又は、ネットワーク経由で配布が可能なものである。

Claims (8)

  1. コンテンツを1つ以上のセグメントに分割して配信し、コンテンツはセグメント単位で要求されるコンテンツ配信ネットワークの通信装置であって、
    コンテンツと1つ以上のインタフェースの対応関係と、コンテンツ及びインタフェースの組み合わせに対する閾値及びウィンドウ・サイズを示す情報を含む経路情報を保持する保持手段と、
    コンテンツを要求する要求パケットを出力するインタフェースを、当該要求パケットで要求するコンテンツと前記経路情報とに基づき決定する決定手段と、
    を備えており、
    前記ウィンドウ・サイズは、対応するインタフェースから送信した、対応するコンテンツの要求パケットの送信数と、当該要求パケットの応答として受信したセグメント数との差の許容可能最大値を示し、
    前記閾値は、対応するインタフェースから送信した、対応するコンテンツの要求パケットの応答としてセグメントを受信できたか否かの判定に用いられ、
    前記通信装置は、さらに、
    要求パケットの応答としてセグメントを受信できたか否かに応じて前記経路情報の前記ウィンドウ・サイズを求めて前記経路情報に設定する第1設定手段と、
    要求パケットを送信してから、当該要求パケットの応答としてセグメントを受信するまでの第1時間に基づき前記閾値を求めて前記経路情報に設定する第2設定手段と、
    を備えており、
    前記第2設定手段は、前記第1時間の平均値と、前記第1時間の最大値と最小値の比と、を使用して前記閾値を求めることを特徴とする通信装置。
  2. 前記閾値は、前記最小値に対する前記最大値の比が大きくなる程、大きくなることを特徴とする請求項1に記載の通信装置。
  3. 前記第2設定手段は、前記第1時間の平均値を、前記最小値に対する前記最大値の比により変更することで前記閾値を求めることを特徴とする請求項1に記載の通信装置。
  4. 前記第2設定手段は、前記第1時間の偏差に前記比を乗じた値と、前記平均値との和に基づく値を前記閾値とすることを特徴とする請求項3に記載の通信装置。
  5. 前記第2設定手段は、所定数のセグメントを受信する度に前記閾値を求めることを特徴とする請求項1から4のいずれか1項に記載の通信装置。
  6. 前記第2設定手段は、所定の周期毎に前記閾値を求めることを特徴とする請求項1から4のいずれか1項に記載の通信装置。
  7. 前記第2設定手段は、前記閾値を、算出時点から過去所定数の第1時間、或いは、算出時点から過去所定期間の第1時間を使用して算出することを特徴とする請求項1から6のいずれか1項に記載の通信装置。
  8. 請求項1から7のいずれか1項に記載の通信装置としてコンピュータを機能させることを特徴とするプログラム。
JP2014172971A 2014-08-27 2014-08-27 コンテンツ配信ネットワークの通信装置及びプログラム Active JP6348377B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014172971A JP6348377B2 (ja) 2014-08-27 2014-08-27 コンテンツ配信ネットワークの通信装置及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014172971A JP6348377B2 (ja) 2014-08-27 2014-08-27 コンテンツ配信ネットワークの通信装置及びプログラム

Publications (2)

Publication Number Publication Date
JP2016048844A JP2016048844A (ja) 2016-04-07
JP6348377B2 true JP6348377B2 (ja) 2018-06-27

Family

ID=55649540

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014172971A Active JP6348377B2 (ja) 2014-08-27 2014-08-27 コンテンツ配信ネットワークの通信装置及びプログラム

Country Status (1)

Country Link
JP (1) JP6348377B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7168596B2 (ja) * 2020-02-18 2022-11-09 Kddi株式会社 コンテンツ配信システムのクライアント装置及びプログラム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8923293B2 (en) * 2009-10-21 2014-12-30 Palo Alto Research Center Incorporated Adaptive multi-interface use for content networking
US8751638B2 (en) * 2010-07-02 2014-06-10 Futurewei Technologies, Inc. System and method to implement joint server selection and path selection
US9749384B2 (en) * 2012-10-24 2017-08-29 Panasonic Intellectual Property Management Co., Ltd. Communication system, reception terminal, transmission terminal, and flow rate control method
US9986063B2 (en) * 2012-11-28 2018-05-29 Panasonic Intellectual Property Management Co., Ltd. Receiving terminal and receiving method

Also Published As

Publication number Publication date
JP2016048844A (ja) 2016-04-07

Similar Documents

Publication Publication Date Title
US8943206B2 (en) Network bandwidth detection and distribution
US10560383B2 (en) Network latency scheduling
WO2018112877A1 (zh) 路径计算和访问请求分发方法、装置及系统
US11190430B2 (en) Determining the bandwidth of a communication link
JP4761078B2 (ja) マルチキャストノード装置とマルチキャスト転送方法ならびにプログラム
US11258716B1 (en) System and method for optimizing dynamic multi-stream network connections
JP6348377B2 (ja) コンテンツ配信ネットワークの通信装置及びプログラム
Zinner et al. Using concurrent multipath transmission for transport virtualization: analyzing path selection
US9130843B2 (en) Method and apparatus for improving HTTP adaptive streaming performance using TCP modifications at content source
JP4798495B2 (ja) 映像配信品質測定システム、装置および方法
JP6223151B2 (ja) 配信サーバ振り分けシステム、配信サーバ管理装置および受信装置
JP2015216498A (ja) コンテンツ配信ネットワークの通信装置、クライアント装置及びプログラム
JP2004135065A (ja) 送信端末、受信端末及びデータ伝送システム
JP6555853B2 (ja) 送信装置、送信制御方法及びプログラム
JP6403567B2 (ja) コンテンツ配信ネットワークの通信装置及びプログラム
JP6369024B2 (ja) 映像配信システム及び映像配信システムにおいて使用されるノード装置
JP6081322B2 (ja) 転送したコンテンツを保存する通信装置
JP6371230B2 (ja) コンテンツ配信ネットワークの転送装置及びプログラム
JP6195785B2 (ja) 転送したコンテンツを保存する通信装置、サーバ装置及びプログラム
JP6362536B2 (ja) コンテンツ配信ネットワークのクライアント装置及びプログラム
JP4774411B2 (ja) エッジノードおよび帯域制御方法
JP2003209574A (ja) Tcpスループット算出方法及びその装置、tcpスループット算出プログラム
JP2007019903A (ja) 映像配信サービスにおける通信速度測定方法及び通信速度測定システム及び通信速度測定端末
JP2011193536A (ja) 映像配信品質測定システム、装置および方法
JP2009206734A (ja) Tcpフローレート制御エッジノードにおけるフローレート制御方法及びエッジノード

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170118

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171211

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171226

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180511

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180531

R150 Certificate of patent or registration of utility model

Ref document number: 6348377

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150