(57)【要約】【課題】  帯域遅延積の大きいネットワークにおいて、バースト的なパケットの送出を未然に防止し、ネットワークに接続されたノードに対する負荷の軽減と、ネットワークの帯域の有効利用を図るデータ転送制御装置を提供する。【解決手段】  伝送帯域を推定し、その推定した帯域推定値と、ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積（Ｗｏｐ）を算出し、該算出した帯域遅延積（Ｗｏｐ）を基に、送信ウインドウサイズ（ｃｗｎｄ）を、帯域遅延積（Ｗｏｐ）×（１−ｅ-γt）の型（γ＝α×ＭＴＵ／（Ｗｏｐ×ＲＴＴ）、α＝定数、ＭＴＵ＝最大転送単位、Ｗｏｐ＝帯域遅延積、ｔ＝時間）で帯域遅延積（Ｗｏｐ）に収束させ、更に、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートに上限値（上限値＝帯域推定値×Ｔｉｃｋ時間×（１＋δ））を設定する。【選択図】  図１
2005244517.tif 000002
【特許請求の範囲】
【請求項１】
ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行うデータ転送制御装置であって、
伝送帯域を推定する帯域推定手段と、
前記帯域推定手段により推定された帯域と、前記ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出する帯域算出手段と、
前記帯域算出手段により算出された帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が前記帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを前記帯域遅延積に収束させる収束手段と、
基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定する設定手段と、
前記設定手段により設定された前記上限値を基に、前記収束手段により前記帯域遅延積に収束させる前記送信ウインドウサイズでデータ転送を行うデータ転送手段と、
を有することを特徴とするデータ転送制御装置。
【請求項２】
前記設定手段は、データ転送の出力要求が行われ、ｔｉｃｋの値が変化したと判断した場合に、前記１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定することを特徴とする請求項１記載のデータ転送制御装置。
【請求項３】
前記設定手段により設定される上限値は、
前記帯域推定手段により推定された帯域の値に、該帯域の値の一定比率倍の値だけ付加した値であることを特徴とする請求項１または２記載のデータ転送制御装置。
【請求項４】
前記データ転送手段は、
前記送信ウインドウサイズでデータ転送を行う１ｔｉｃｋ内の累積データ量が、前記設定手段により設定された前記上限値を超えたと判定した場合は、データ転送を行わないことを特徴とする請求項１記載のデータ転送制御装置。
【請求項５】
ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行う制御手段を有するデータ転送制御装置におけるデータ転送制御方法であって、
伝送帯域を推定する帯域推定工程と、
前記帯域推定工程により推定された帯域と、前記ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出する帯域算出工程と、
前記帯域算出工程により算出された帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が前記帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを前記帯域遅延積に収束させる収束工程と、
基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定する設定工程と、
前記設定工程により設定された前記上限値を基に、前記収束工程により前記帯域遅延積に収束させる前記送信ウインドウサイズでデータ転送を行うデータ転送工程と、
を前記制御手段が行うことを特徴とするデータ転送制御方法。
【請求項６】
前記設定工程は、データ転送の出力要求が行われ、ｔｉｃｋの値が変化したと判断した場合に、前記１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定することを特徴とする請求項５記載のデータ転送制御方法。
【請求項７】
前記設定工程により設定される上限値は、
前記帯域推定工程により推定された帯域の値に、該帯域の値の一定比率倍の値だけ付加した値であることを特徴とする請求項５または６記載のデータ転送制御方法。
【請求項８】
前記データ転送工程は、
前記送信ウインドウサイズでデータ転送を行う１ｔｉｃｋ内の累積データ量が、前記設定工程により設定された前記上限値を超えたと判定した場合は、データ転送を行わないことを特徴とする請求項５記載のデータ転送制御方法。
【請求項９】
ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行う制御手段を有するデータ転送制御装置において実行されるデータ転送制御プログラムであって、
伝送帯域を推定する帯域推定処理と、
前記帯域推定処理により推定された帯域と、前記ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出する帯域算出処理と、
前記帯域算出処理により算出された帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が前記帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを前記帯域遅延積に収束させる収束処理と、
基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定する設定処理と、
前記設定処理により設定された前記上限値を基に、前記収束処理により前記帯域遅延積に収束させる前記送信ウインドウサイズでデータ転送を行うデータ転送処理と、
を前記制御手段に実行させることを特徴とするデータ転送制御プログラム。
【請求項１０】
前記設定処理は、データ転送の出力要求が行われ、ｔｉｃｋの値が変化したと判断した場合に、前記１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定することを特徴とする請求項９記載のデータ転送制御プログラム。
【請求項１１】
前記設定処理により設定される上限値は、
前記帯域推定処理により推定された帯域の値に、該帯域の値の一定比率倍の値だけ付加した値であることを特徴とする請求項９または１０記載のデータ転送制御プログラム。
【請求項１２】
前記データ転送処理は、
前記送信ウインドウサイズでデータ転送を行う１ｔｉｃｋ内の累積データ量が、前記設定処理により設定された前記上限値を超えたと判定した場合は、データ転送を行わないことを特徴とする請求項９記載のデータ転送制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）によりデータ転送を行う際に使用するデータ転送制御装置、データ転送制御方法およびデータ転送制御プログラムに関し、特に、伝送路となる通信回線を共有してデータ転送を行う際に使用するデータ転送制御装置、データ転送制御方法およびデータ転送制御プログラムに関するものである。
【背景技術】
【０００２】
近年、ネットワークに使用される通信回線やネットワークに接続される通信装置などのコストが低くなり、ネットワークの拡張にかかるコストは年々低くなりつつあるが、大陸間を接続するような大規模な広域ネットワークの場合には、広域ネットワークの構築や維持、運用に膨大なコストがかかるのが現状である。このため、コストを削減しつつ、且つ、ネットワーク資源を活用した広域ネットワークの開発が進められている。
【０００３】
なお、ネットワーク資源の有効活用を図るためには輻輳制御が行われており、広域自律分散型のネットワーク（例えば、インターネット）では、通信処理を行う終端ノードにより自律的な輻輳制御を行っている。インターネット・トラフィックの大半は、ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を使用してデータを転送しており、ＴＣＰによる輻輳制御は、通信経路を推測しながら、その通信経路に適した送出レートを選択する簡易なアルゴリズムを用いて輻輳の発生を防止し、また、輻輳の発生を検出した際に、送出レートを下げることで輻輳崩壊を防止している。
【０００４】
しかしながら、ＴＣＰによる輻輳制御は、ロングファットパイプと呼ばれる帯域遅延積（ネットワークの帯域幅と、データ・セグメントを送信した後にその送信に対するＡＣＫ（応答信号）が到着するまでの往復遅延時間：ＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）と、を掛け合わせたもの）の値が大きなネットワークの場合には、ＴＣＰコネクションでデータを送受信する際のスループットが低下してしまうことが指摘されている（例えば、非特許文献１参照）。
【０００５】
また、本発明より先に出願された技術文献として、送信側から送信した転送データが受信側で受信されたことを示す受信側からの受信応答に基づいて、順次、送信側から転送データを送信すると共に、送信側で推定した受信側へのデータ転送に対するスループットに応じて送信ウインドウサイズを変更することによりデータ転送量を制御するフロー制御方法において、送信側では、所定範囲内でもっとも以前に受信された第２の受信応答により確認されたデータ以降、新たに受信した第１の受信応答により推定スループットを算出し、この推定スループットと、転送データの送信からそれぞれの転送データに対する受信応答の検出までに要する受信応答検出時間（ＲＴＴ）のうち最も小さい最小受信応答検出時間との積を用いて、送信ウインドウサイズを、直接算出するフロー制御方法がある（例えば、特許文献１参照）。
【特許文献１】特開２０００−２１６８１１号公報
【非特許文献１】Ｌ．Ｋｌｅｉｎｒｏｃｋ，“Ｔｈｅ  Ｌａｔｅｎｃｙ／Ｂａｎｄｗｉｄｔｈ  Ｔｒａｄｅｏｆｆ  ｉｎ  Ｇｉｇａｂｉｔ  Ｎｅｔｗｏｒｋｓ”ＩＥＥＥ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｍａｇａｚｉｎｅ  Ａｐｒｉｌ  １９９２
【発明の開示】
【発明が解決しようとする課題】
【０００６】
なお、データを効率的に転送するには、送信ウインドウサイズ（ｃｗｎｄ）を帯域遅延積（＝帯域幅×ＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ））に保持することが必要であるが、従来のＴＣＰの輻輳制御は、帯域遅延積が大きいネットワークの場合には、パケット紛失を検出した際に半減させた送信ウインドウサイズ（ｃｗｎｄ）を最適な送信ウインドウサイズの値である帯域遅延積に収束するまでに時間がかかり、例えば、数１００Ｍバイト程度のデータ転送においては帯域を有効に使い切れていないことになる。
【０００７】
また、送信ウインドウサイズが大きくなると、大量のパケットをバースト的に送り出す場合がある。この場合、ネットワークに接続されているノードは、バースト的に送り出された大量のパケットのために、トラフィックが急増することになる。また、ネットワークに対して大量のパケットをバースト的に送り出すと、その大半のパケットが再び送信されることになるため、ネットワークにおける帯域を無駄に使用することになる。なお、本明細書におけるバーストとは、受信側が１ＡＣＫで何百ものパケットの送達確認を認識した際に、何百ものパケットを送り出すことを示唆する。
【０００８】
本発明は上記事情に鑑みてなされたものであり、帯域遅延積の大きいネットワークにおいて、バースト的なパケットの送出を未然に防止し、ネットワークに接続されたノードに対する負荷の軽減と、ネットワークの帯域の有効利用を図るデータ転送制御装置、データ転送制御方法およびデータ転送制御プログラムを提供することを目的とするものである。
【課題を解決するための手段】
【０００９】
かかる目的を達成するために、本発明は以下の特徴を有することとする。
【００１０】
本発明にかかるデータ転送制御装置は、ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行うデータ転送制御装置であって、伝送帯域を推定する帯域推定手段と、帯域推定手段により推定された帯域と、ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出する帯域算出手段と、帯域算出手段により算出された帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを帯域遅延積に収束させる収束手段と、基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定する設定手段と、設定手段により設定された上限値を基に、収束手段により帯域遅延積に収束させる送信ウインドウサイズでデータ転送を行うデータ転送手段と、を有することを特徴とするものである。
【００１１】
また、本発明にかかるデータ転送制御装置において、設定手段は、データ転送の出力要求が行われ、ｔｉｃｋの値が変化したと判断した場合に、１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定することを特徴とするものである。
【００１２】
また、本発明にかかるデータ転送制御装置において、設定手段により設定される上限値は、帯域推定手段により推定された帯域の値に、該帯域の値の一定比率倍の値だけ付加した値であることを特徴とするものである。
【００１３】
また、本発明にかかるデータ転送制御装置において、データ転送手段は、送信ウインドウサイズでデータ転送を行う１ｔｉｃｋ内の累積データ量が、設定手段により設定された上限値を超えたと判定した場合は、データ転送を行わないことを特徴とするものである。
【００１４】
また、本発明にかかるデータ転送制御方法は、ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行う制御手段を有するデータ転送制御装置におけるデータ転送制御方法であって、伝送帯域を推定する帯域推定工程と、帯域推定工程により推定された帯域と、ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出する帯域算出工程と、帯域算出工程により算出された帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを帯域遅延積に収束させる収束工程と、基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定する設定工程と、設定工程により設定された上限値を基に、収束工程により帯域遅延積に収束させる送信ウインドウサイズでデータ転送を行うデータ転送工程と、を制御手段が行うことを特徴とするものである。
【００１５】
また、本発明にかかるデータ転送制御方法において、設定工程は、データ転送の出力要求が行われ、ｔｉｃｋの値が変化したと判断した場合に、１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定することを特徴とするものである。
【００１６】
また、本発明にかかるデータ転送制御方法において、設定工程により設定される上限値は、帯域推定工程により推定された帯域の値に、該帯域の値の一定比率倍の値だけ付加した値であることを特徴とするものである。
【００１７】
また、本発明にかかるデータ転送制御方法において、データ転送工程は、送信ウインドウサイズでデータ転送を行う１ｔｉｃｋ内の累積データ量が、設定工程により設定された上限値を超えたと判定した場合は、データ転送を行わないことを特徴とするものである。
【００１８】
また、本発明にかかるデータ転送制御プログラムは、ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行う制御手段を有するデータ転送制御装置において実行されるデータ転送制御プログラムであって、伝送帯域を推定する帯域推定処理と、帯域推定処理により推定された帯域と、ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出する帯域算出処理と、帯域算出処理により算出された帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを帯域遅延積に収束させる収束処理と、基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定する設定処理と、設定処理により設定された上限値を基に、収束処理により帯域遅延積に収束させる送信ウインドウサイズでデータ転送を行うデータ転送処理と、を制御手段に実行させることを特徴とするものである。
【００１９】
また、本発明にかかるデータ転送制御プログラムにおいて、設定処理は、データ転送の出力要求が行われ、ｔｉｃｋの値が変化したと判断した場合に、１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定することを特徴とするものである。
【００２０】
また、本発明にかかるデータ転送制御プログラムにおいて、設定処理により設定される上限値は、帯域推定処理により推定された帯域の値に、該帯域の値の一定比率倍の値だけ付加した値であることを特徴とするものである。
【００２１】
また、本発明にかかるデータ転送プログラムにおいて、データ転送処理は、送信ウインドウサイズでデータ転送を行う１ｔｉｃｋ内の累積データ量が、設定処理により設定された上限値を超えたと判定した場合は、データ転送を行わないことを特徴とするものである。
【発明の効果】
【００２２】
本発明にかかるデータ転送制御装置、データ転送制御方法及びデータ転送制御プログラムは、ＴＣＰ（Ｔｒａｎｓｍｉｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）による輻輳制御を行い、データ転送を行うデータ転送制御装置において、伝送帯域を推定し、その推定した帯域と、ＴＣＰにより測定されるＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）との積で帯域遅延積を算出し、その算出した帯域遅延積を基に、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、且つ、送信ウインドウサイズの値が帯域遅延積に近づくにつれて送信ウインドウサイズをゆっくりと増加させるように、送信ウインドウサイズを帯域遅延積に収束させ、基本周期である１ｔｉｃｋ内においてデータ転送を可能とするデータ転送量の上限値を設定し、その設定した上限値を基に、上記のように収束させる送信ウインドウサイズでデータ転送を行うことで、帯域遅延積の大きいネットワークにおいて、バースト的なデータパケットの送出がなくなり、ネットワークに接続されたノードに対する負荷の軽減と、ネットワークの帯域の有効利用を図ることが可能となる。
【発明を実施するための最良の形態】
【００２３】
本発明にかかるデータ転送制御装置、データ転送制御方法およびデータ転送制御プログラムは、図１に示すように、送信ウインドウサイズを帯域遅延積（Ｗｏｐ）×（１−ｅ-γt）の型（γ＝α×ＭＴＵ／（Ｗｏｐ×ＲＴＴ）、α＝定数、ＭＴＵ＝最大転送単位、Ｗｏｐ＝帯域遅延積、ｔ＝時間）で帯域遅延積に収束させ、送信ウインドウサイズの値が小さい期間は送信ウインドウサイズを速く増加させ、送信ウインドウサイズの値が最適な帯域遅延積の値に近づくにつれて送信ウインドウサイズをゆっくりと増加させ最適な帯域遅延積の値に近い値を維持させ、更に、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートに上限値を設けることとした。なお、上限値は、帯域推定値×Ｔｉｃｋ時間×（１＋δ（δは定数））により算出されることになる。なお、δは、帯域推定値の一定比率倍の値を示唆する。
【実施例】
【００２４】
以下、添付図面を参照しながら、本発明にかかるデータ転送制御装置、データ転送制御方法及びデータ転送制御プログラムについて説明する。
【００２５】
インターネット・トラフィックの大半は、ＴＣＰプロトコルを使用して転送されている。ＴＣＰが使用される環境は、さまざまではあるが、ＴＣＰの輻輳回避プログラムは、基本部分が数行であるにもかかわらず、広い範囲で効率的なデータ転送を実現している。しかしながら、ロングファットパイプと呼ばれている帯域遅延積の大きい高帯域ネットワークでは、ＴＣＰの性能が低下し、効率的なデータ転送が困難であることが指摘されている。
【００２６】
また、災害対策としてのバックアップ・データベースのネットワーク転送、あるいは、デジタル・シネマなどの大容量データの配信など、遠隔地への大容量の業務用データの高速転送が、将来増加するものと考えられる。なお、このような大容量のデータ転送は、限られた時間内に、確実にデータ転送を完了することが求められることから、帯域の保証が得られない一般のインターネットではなく、コストの高い専用線等を一時的に使用することが考えられ、大容量のデータ転送には、データ転送の効率化が重要視されることになる。
【００２７】
本実施例では、高速専用線のネットワークを使用し、大容量のデータ転送を行うことを前提に、ＴＣＰソフトをベースに、データ転送効率低下の問題点の分析、そのデータ転送効率低下の問題点に対する対策、その対策による効果について以下に説明する。
【００２８】
まず、図２を参照しながら、本実施例におけるネットワーク構成について説明する。
本実施例におけるネットワーク構成は、クライアントＰＣ（１）と、サーバＰＣ（２）と、が複数のルータＰＣ（１０、１１、１２、１３）と、ＨＵＢ（２０、２１）と、を介して接続されている。また、デジタル・シネマ・クライアントＰＣ（３）と、デジタル・シネマ・サーバＰＣ（４）と、が複数のルータＰＣ（１０、１１）と、ＨＵＢ（２０、２２）と、を介して接続されている。また、デジタル・シネマ・クライアントＰＣ（３）は、デジタル・シネマ・デコーダ（５）と接続されている。なお、本実施例におけるネットワーク構成は、ＡＴＭスイッチのＰＶＣ設定を切り替えることによりＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）を変更可能となるように構築されている。
【００２９】
また、本実施例におけるネットワーク構成は、クライアントＰＣ（１）とサーバＰＣ（２）との間のデータ通信において４つのルータＰＣ（１０、１１、１２、１３）を経由する場合のＲＴＴは、２つのルータＰＣ（１０、１１）を経由する場合の２倍のＲＴＴをもつネットワークを構築している。このため、ＤＡＴＡパケットは、クライアントＰＣ（１）−サーバＰＣ（２）間におけるメモリ・メモリ間データ転送では、ラウンドトリップタイム（ｒｔｔ）は、約９０ｍｓ、デジタル・シネマ・クライアントＰＣ（３）−デジタル・シネマ・サーバＰＣ（４）間におけるデジタル・シネマ間データ転送では、ラウンドトリップタイム（ｒｔｔ）は、約４５ｍｓである。なお、ＡＣＫパケットは、ローカルＡＴＭスイッチで折り返している。
【００３０】
なお、図２に示唆するネットワーク構成において、メモリ・メモリ間データ転送ツールを使用したデータ転送実験では、パケット紛失を検出した際に、ファーストリトランスミット・ファーストリカバリアルゴリズムにより送出レートを半減するためのＲａｔｅ−Ｈａｌｖｉｎｇ方式を適用することで、バーストの発生を抑えることとした。しかしながら、デジタル・シネマのリアルタイム転送アプリケーションツールを使用したデータ転送実験では、Ｒａｔｅ−Ｈａｌｖｉｎｇ方式を適用しても、バーストの発生を抑えることが出来なかった。このように、デジタル・シネマのリアルタイム転送アプリケーションツールを使用した場合のトラフィックは、メモリ・メモリ間データ転送ツールを使用した場合と比べて、バーストの発生頻度が高いことが判明した。これは、以下の３点が原因と考えられる。
【００３１】
第１に、デジタル・シネマのリアルタイム転送アプリケーションツールは、最大送信ウインドウサイズ（ｃｗｎｄ）を大きく設定しているので、受信側となるデジタル・シネマ・クライアントＰＣ（３）のＴＣＰで大量のバッファを用意している。
第２に、デジタル・シネマのリアルタイム転送アプリケーションツールの読取プログラムが起動した際に、一度に大量のパケットを読みとることになる。
第３に、デジタル・シネマのリアルタイム転送アプリケーションツールは、最大送信ウインドウサイズ（ｃｗｎｄ）を大きく設定しているので、パケット紛失が発生した際は、複数のパケットが同時に紛失する場合が多い。
【００３２】
また、上記の３点の他にも、ＴＣＰプログラムの実装の違いにより、ＡＣＫの返送数が異なることも一因と考えられる。
【００３３】
なお、メモリ・メモリ間転送ツールとは、送り側は単に、メモリ上のデータを繰り返し送り出すだけであり、受信側は単にデータ受信を繰り返すだけのツールを示唆するものである。本実施例では、図２に示唆するネットワーク構成におけるクライアントＰＣ（１）のメモリと、サーバＰＣ（２）のメモリと、の間で予め指定されたデータ量を転送するツールであり、サーバＰＣ（２）がデータを繰り返し送信し、クライアントＰＣ（１）がデータを繰り返し受信することになる。
【００３４】
また、デジタル・シネマのリアルタイム転送アプリケーションツールとは、受信側が受信したデータを受信側の具備するメモリに一時的に保存するのではなく、受信したデータを直接デコーダに送り出してリアルタイム性を強調したデータ転送を示唆するツールである。本実施例では、図２に示唆するネットワーク構成におけるデジタル・シネマ・サーバＰＣ（４）が送り出したデータをデジタル・シネマ・クライアントＰＣ（３）が受信し、その受信したデータをデジタル・シネマ・クライアントＰＣ（３）と接続されたデジタル・シネマ・デコーダ（５）に直接送信することになる。
【００３５】
（データ転送効率を低下させる問題点）
次に、図２に示唆するネットワーク構成において測定した測定データを基に、データ転送効率を低下させる問題点について説明する。なお、測定データは、図２に示唆するネットワーク構成における測定機（３０、３１）において測定したデータである。
【００３６】
例えば、図２に示唆するネットワーク構成において、日本一周ＰＶＣを使用し、４ギガバイトのデータをクライアントＰＣ（１）のメモリと、サーバＰＣ（２）のメモリと、の間でデータ転送を行った場合のＤＡＴＡシーケンス、および、スループットの時間推移をそれぞれ図３、図４に示唆する。なお、図３は、ＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフである。なお、図３に示唆する通信開始後の□印は、再送パケットの送信シーケンスを示唆するものである。また、図４は、ＲＴＴ毎のＡＣＫにより送達確認された転送レート（スループット）をプロットしたグラフである。なお、図３、図４に示唆する測定データの横軸は、データ通信を開始してからの経過時間（ｓｅｃ）を示唆するものである。
【００３７】
図３、図４に示唆する図から、スループットが２５Ｍｂｐｓ程度から１４０Ｍｂｐｓになるのに約２００秒かかっていること、および、データ転送開始から１００秒、および、３００秒でパケット紛失が発生し、３００秒ではスループットが激減していることがわかる。
【００３８】
なお、図４に示唆するように、スループットが１４０Ｍｂｐｓになるのに約２００秒かかるのは、ＴＣＰはおおむねｒｔｔの２倍の時間毎に、送信ウインドウサイズ（ｃｗｎｄ）を１パケット増加させるが、１４０Ｍｂｐｓのスループットが得られるときの送信ウインドウサイズは、１０５８パケットと大きいためである。
【００３９】
次に、３００秒時点でスループットが激減している前後のＤＡＴＡシーケンス、および、ＡＣＫシーケンスの詳細を図５に示唆する。なお、図５に示唆する測定データの横軸は、データ通信を開始してからの経過時間（ｍｓｅｃ）を示唆するものである。
【００４０】
図５に示唆するように、複数パケットの連続紛失が発生し、タイムアウトが１回、パケット再送が計１４回発生している。送信ウインドウサイズが大きいと、再送パケットが届いた場合に、その再送パケットに続く多くのＤＡＴＡパケットの到着が確認されるため、ＡＣＫのシーケンス番号が一気に増加することになる。図５ではこのような場合が３回発生しており、それぞれ、４１７パケット、３５７パケット、４９２パケット、が１つのＡＣＫで確認されている。送信側は、ＡＣＫのシーケンス番号が一気に増加するときの送信ウインドウサイズ（ｃｗｎｄ）が、大きい値のままである場合には、送信側が送信するパケット数が、シーケンスの番号が一気に増加する値（例えば、図５では、４１７パケット、３５７パケット、４９２パケット）だけ増加するのでＤＡＴＡパケットをバースト的に送り出すことになる。その結果、再び、パケット紛失が発生し、最悪の場合、送信ウインドウサイズ（ｃｗｎｄ）の値が最低値になるまでバーストの発生を繰り返すことになる。
【００４１】
これは、送達未確認パケット数をプロットした図６のグラフから確認できる。なお、図６に示唆する送達未確認パケット数を示唆する測定データの横軸は、データ通信を開始してからの経過時間（ｍｓｅｃ）を示唆するものである。
【００４２】
送達未確認パケット数は、図６に示唆するように、３．５秒間に送信ウインドウサイズ（ｃｗｎｄ）が１１００パケット程度からほぼ０にまで激減していることがわかる。なお、途中、一時的にパケット数が１５００パケット程度まで増加しているが、Ｒａｔｅ−Ｈａｌｖｉｎｇを施しているため、１５００パケット程度でとまっている。なお、Ｒａｔｅ−Ｈａｌｖｉｎｇを施していなければ、パケット数が２０００パケット以上に増加することになる。
【００４３】
このように、上記の実験結果から、ロングファットパイプ経由で大容量のデータ転送を行う際に、データ転送効率を低下させる大きな問題点は、以下の２点であることが判明した。
【００４４】
問題１：送信ウインドウサイズの増加が遅い。
問題２：バーストが発生する。
そこで、本実施例では、以下のような２つの対策を施すこととした。
【００４５】
第１の対策として、送信ウインドウサイズ（ｃｗｎｄ）の増加方式を変更し、送信ウインドウサイズ（ｃｗｎｄ）を、帯域遅延積×（１−ｅ-γt）の型（γ＝α×ＭＴＵ／（Ｗｏｐ×ＲＴＴ）、α＝定数、ＭＴＵ＝最大転送単位、Ｗｏｐ＝帯域遅延積、ｔ＝時間）で最適な帯域遅延積に収束させることとした。
【００４６】
このように、送信ウインドウサイズ（ｃｗｎｄ）が小さい期間は、送信ウインドウサイズを早く増加させることでデータ転送効率を向上させ、送信ウインドウサイズが最適な帯域遅延積の値に近づくにつれて送信ウインドウサイズをゆっくりと増加させ最適な帯域遅延積の値に近い値を維持させることでパケットロスの発生頻度を軽減させ、データ転送効率の低下を削減することになる。
【００４７】
第２の対策として、ＴＣＰの送出レートに上限を設けることとした。なお、上限値は、帯域推定値×（１＋δ）とする。帯域推定値は、ＡＣＫ受信間隔から帯域推定値を算出する。そして、その算出した帯域推定値と、基本周期ｔｉｃｋ（１＋δ）と、を乗算することとする。以下に、第１と第２の対策について詳細に説明する。
【００４８】
（第１の対策）
第１の対策として以下の処理を行うことになる。
第１に、ｒｔｔ時間毎に、ＡＣＫの受信間隔からパケットペア方式により帯域を推定し、その推定した帯域推定値の平滑化平均値を算出する。
第２に、パケットペア方式により推定した帯域推定値の平滑化平均値と、ＴＣＰにより測定しているＲＴＴ測定値と、の積で最適な帯域遅延積（Ｗｏｐ）を算出する。
第３に、ＲＴＴ毎の送信ウインドウサイズの増加値（あるいは削減値）を、次の式（１）により算出する。
【００４９】
（式１）
送信ウインドウサイズの増加＝α×（Ｗｏｐ−ｃｗｎｄ）／Ｗｏｐ
α：定数（パケットサイズ）
ｗｏｐ：帯域遅延積＝帯域推定値の平滑化平均×ＴＣＰのＲＴＴ測定値
ｃｗｎｄ：送信ウインドウサイズ
【００５０】
他には、Ｒａｔｅ−Ｈａｌｖｉｎｇを適用したり、スロースタート時にｓｓｔｈを帯域遅延積（Ｗｏｐ）×１／２に設定したりする。
【００５１】
第１の対策により、帯域遅延積が一定の時は、送信ウインドウサイズ（ｃｗｎｄ）はＷｏｐ×（１−ｅ-γt）の型で最適な送信ウインドウサイズの値となるＷｏｐに収束し、送信ウインドウサイズ（ｃｗｎｄ）＝Ｗｏｐ／２時点での送信ウインドウサイズ（ｃｗｎｄ）の増分は、上記の（式１）によりα／２パケットとなり、既存のＴＣＰ輻輳回避モード動作時のα倍となる。
【００５２】
なお、Ｗｏｐ×（１−ｅ-γt）の型におけるγは、γ＝α×ＭＴＵ／（Ｗｏｐ×ＲＴＴ）で求められる定数を示唆するものであり、ＭＴＵは最大転送単位を示唆するものであり、ｔは時間を示唆するものである。
【００５３】
この第１の対策を実施した後のＤＡＴＡシーケンス、スループット、および、送達未確認パケット数の時間推移をそれぞれ図７、図８に示唆する。なお、測定条件は図３、図４と同様で、日本一周ＰＶＣ（ｒｔｔ＝９０ｍｓ）を使用し、４ギガバイトのデータをメモリ・メモリ間で転送した。なお、図７は、ＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフである。また、図８は、ＲＴＴ毎のＡＣＫにより送達確認された転送レート（スループット）をプロットしたグラフである。なお、図７、図８に示唆する測定データの横軸は、データ通信を開始してからの経過時間（ｓｅｃ）を示唆するものである。
【００５４】
図７に示唆するグラフから、パケット再送が発生していないこと、図８に示唆するグラフから、通信開始直後に、ｓｓｔｈを、最適な帯域遅延積の１／２程度の値に設定し、送信ウインドウサイズがゆっくりではあるが増加し、７０秒後には最適な帯域遅延積に収束していることが読みとれる。
【００５５】
また、第１の対策により、４ギガバイトのデータ転送に要した時間は、図７に示唆するように、４５９秒（図３参照）から１８８秒に短縮されており、平均のスループットは、図８に示唆するように、７３Ｍｂｐｓ（図４参照）から２倍以上の１７８Ｍｂｐｓに向上している。
【００５６】
このように、第１の対策を施すことで、図７、図８に示唆するように、メモリ・メモリ間転送ツールによる、クライアントＰＣ（１）とサーバＰＣ（２）とのメモリ・メモリ間転送では、バースト転送を回避することが可能となった。しかしながら、デジタル・シネマのリアルタイム転送アプリケーションツールによる、デジタル・シネマ・クライアントＰＣ（３）とデジタル・シネマ・サーバＰＣ（４）とのリアルタイム転送では、第１の対策を施してもバースト転送が頻発することが判明した。そこで、第２の対策として、「１ｔｉｃｋ内において送出可能なＴＣＰの送出レートの上限値として、帯域推定値×（１＋δ）と設定する」こととし以下の処理をＴＣＰ出力プログラムに追加した。
【００５７】
（第２の対策）
第１に、ＴＣＰ出力プログラムにおいて、ＤＡＴＡパケットの送出要求があると判断した場合は、第１の対策において推定した帯域推定値の平滑化平均値が正常な値であるか否を判定し、第１の対策処理における帯域推定が正常に動作中か否かを判断する。
【００５８】
第２に、第１の対策処理における帯域推定が正常に動作中であると判断した場合は、ＯＳの基本周期であるｔｉｃｋの値が変化した際に、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートを以下の式（２）で算出する。
【００５９】
（式２）
ＴＣＰの送出レート＝帯域推定値の平滑化平均値×（１＋δ）
【００６０】
なお、ｔｉｃｋの値はＯＳの周期プログラムが書き換えることになり、ＴＣＰ出力プログラムでは、ＤＡＴＡパケットを送り出した際に、そのＤＡＴＡパケット送出時点でのｔｉｃｋの値をメモリに記憶し、次に、ＴＣＰ出力プログラムが起動された際に、メモリに記憶したｔｉｃｋの値と、ＯＳの基本周期であるｔｉｃｋの値と、を比較し、ＯＳの基本周期であるｔｉｃｋの値が変化したか否かを判断することになり、ＯＳの基本周期であるｔｉｃｋの値が変化したと判断した場合は、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートを式（２）で算出することになる。
【００６１】
第３に、１ｔｉｃｋ内の累計送出ＤＡＴＡパケット量が、式（２）で算出した、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートによる送出可能データ量を超えたと判断した場合は、ＤＡＴＡパケットを送出しないこととする。なお、上記送出可能データ量は、式（２）で算出したＴＣＰの送出レートにｔｉｃｋ時間間隔を乗算したデータ量を示唆する。
【００６２】
次に、図９を参照しながら、第２の対策における処理動作について説明する。
まず、ＡＣＫの受信間隔からパケットペア方式により帯域を推定した帯域推定値が正常な値であるか否を判断し（ステップＳ１）、帯域推定値が正常な値であると判断した場合は（ステップＳ１／ＹＥＳ）、メモリに記憶したｔｉｃｋの値と、ＯＳの基本周期であるｔｉｃｋの値と、を比較し、ＯＳの基本周期であるｔｉｃｋの値が、メモリに記憶したｔｉｃｋの値と一致するか否かを判断する（ステップＳ２）。
【００６３】
ＯＳの基本周期であるｔｉｃｋの値が、メモリに記憶したｔｉｃｋの値と一致しないと判断した場合は（ステップＳ２／ＮＯ）、ＯＳの基本周期であるｔｉｃｋの値が変化したと判断し、ＯＳの基本周期であるｔｉｃｋの値をメモリに記憶し、メモリに記憶されているｔｉｃｋの値を書き換えることになる（ステップＳ３）。そして、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートにより送出可能な送出可能データ量を算出することになる（送出可能データ量＝帯域推定値の平滑化平均値×ｔｉｃｋ時間間隔×（１＋δ））。（ステップＳ４）。
【００６４】
次に、これから送出するＤＡＴＡパケット量が、ステップＳ４で算出した送出可能データ量よりも大きいか否かを判断し（ステップＳ５）、ＤＡＴＡパケット量が送出可能データ量よりも大きいと判断した場合は（ステップＳ５／ＹＥＳ）、ＤＡＴＡパケットを送出せずに処理を終了する（ステップＳ６）。また、ステップＳ５において、これから送信するＤＡＴＡパケット量が送出可能データ量よりも小さい、または、等しいと判断した場合は（ステップＳ５／ＮＯ）、ＤＡＴＡパケットを送信し、送出可能データ量から、その送信したＤＡＴＡパケット量を減算し、その減算した値を送出可能データ量として設定し、処理を終了することになる（ステップＳ７）。
【００６５】
また、ステップＳ２において、メモリに記憶したｔｉｃｋの値と一致すると判断した場合は（ステップＳ２／ＹＥＳ）、これから送出するＤＡＴＡパケット量が、上記設定した送出可能データ量よりも大きいか否かを判断することになり（ステップＳ５）、ＴＣＰの送出レートよりも大きいと判断した場合は（ステップＳ５／ＹＥＳ）、ＤＡＴＡパケットを送出せず処理を終了する（ステップＳ６）。また、これから送出するＤＡＴＡパケット量が、上記設定した送出可能データ量よりも小さい、または等しいと判断した場合は（ステップＳ５／ＮＯ）、ＤＡＴＡパケットを送信し、上記設定した送出可能データ量から、その送信したＤＡＴＡパケット量を減算し、その減算した値を送出可能データ量として設定し、処理を終了することになる（ステップＳ７）。このように、基本周期ｔｉｃｋ毎に、１ｔｉｃｋ内において送出可能なＴＣＰの送出レートの上限値を設定し、ＴＣＰコネクション毎に送出可能なデータ量を示すカウンタから送出データ量をパケット送出毎に削減し、カウンタが負になったと判定した場合にパケットを送出しないことで、バースト転送を防止することが可能となる。
【００６６】
次に、図１０〜図１２を参照しながら、第１の対策、および、第２の対策を加えたデジタル・シネマのリアルタイム転送アプリケーションツールによる、デジタル・シネマ・クライアントＰＣ（３）とデジタル・シネマ・サーバＰＣ（４）とのリアルタイム転送のＤＡＴＡシーケンス、再送シーケンス、スループットおよび送達未確認パケット数の時間推移について説明する。なお、図１０は、デジタル・シネマのリアルタイム転送アプリケーションツールにおけるＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフである。また、図１１は、ＲＴＴ毎のＡＣＫにより送達確認された転送レート（スループット）をプロットしたグラフである。また、図１２は、ＲＴＴ毎のＡＣＫにより送達未確認のパケット数をプロットしたグラフである。なお、図１０〜図１２に示唆する測定データの横軸は、データ通信を開始してからの経過時間（ｓｅｃ）を示唆するものである。
【００６７】
図１０のグラフから、データ転送が開始されてから２７０秒の間にパケット紛失等のフローの乱れが、図１０に示唆する（ａ）を除き、５回発生していることがわかる。
図１０に示唆する（ｃ）の時点では、パケット再送を発生した後に、スロースタートに近い動作でスループットが回復した。
図１０に示唆する（ｄ）では、パケット紛失が発生したが、殆ど影響がなかった。
図１０に示唆する（ｅ）のバースト発生では、送信ウインドウサイズの回復が遅れ、フレームスキップが発生した。
なお、図１０に示唆する（ｄ）と（ｅ）とのパケット紛失発生前後のシーケンス番号と、送達未確認パケット数との時間変化を図１３〜図１６に示唆する。なお、図１３は、図１０に示唆する（ｄ）におけるパケット紛失発生前後のＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフであり、図１４は、ＲＴＴ毎のＡＣＫにより送達未確認のパケット数をプロットしたグラフである。また、図１５は、図１０に示唆する（ｅ）におけるパケット紛失発生前後のＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフであり、図１６は、ＲＴＴ毎のＡＣＫにより送達未確認のパケット数をプロットしたグラフである。なお、図１３〜図１６に示唆する測定データの横軸は、データ通信を開始してからの経過時間（ｍｓｅｃ）を示唆するものである。
【００６８】
図１３〜図１６に示唆するグラフから、パケット紛失が発生した後に、送達未確認パケット数の増減が激しく変動し、図１０に示唆する（ｄ）の場合には、すぐに安定したが、図１０に示唆する（ｅ）の場合には、不安定が増加し、バーストが発生する。このとき、複数のパケットが連続して紛失したためタイムアウトが発生し、その後ＡＣＫシーケンスが６５３パケット一気に増加している。
【００６９】
（第１の対策と、第２の対策による効果）
第１の対策、および、第２の対策を加えたデジタル・シネマのリアルタイム転送アプリケーションツールによる、デジタル・シネマ・クライアントＰＣ（３）とデジタル・シネマ・サーバＰＣ（４）とのリアルタイム転送を約２０分間行った際のスループットは、図１７に示唆するように、従来のＴＣＰと比べて約３０％向上し、フレームスキップ率（転送が間に合わず、フレーム転送をスキップした率）は、約１／５０に削減された。
【００７０】
このように、ＴＣＰプログラムに対して、第１の対策である「送信ウインドウサイズ増加方式」と、第２の対策である「最大転送レートに上限を設定する方式」と、を加えることで、デジタル・シネマ転送でスループットが３０％向上した。また、フレームスキップ率が１／５０に削減することができた。
【００７１】
なお、未確認パケット数の変動原因を調べるため、図１０に示唆する（ｃ）、（ｄ）、（ｅ）の３つの時点前後での１ＡＣＫにより確認されるＤＡＴＡパケット数をプロットしたものを図１８〜図２０に示唆する。なお、図１８は、図１０に示唆する（ｃ）の時点の「スロースタートで回復」の場合のＤＡＴＡパケット数をプロットしたものであり、図１９は、図１０に示唆する（ｄ）の時点の「殆ど影響なし」の場合のＤＡＴＡパケット数をプロットしたものであり、図２０は、図１０に示唆する（ｅ）の時点の「バースト発生」の場合のＤＡＴＡパケット数をプロットしたものである。
【００７２】
図１８〜図２０に示唆するように、パケット紛失発生後、１ＡＣＫにより確認されるパケット数が不安定になっていることがわかる。
【００７３】
図１０に示唆する（ｄ）の「殆ど影響なし」の場合は、図１９に示唆するように、比較的早く安定状態に戻ったが、図１０に示唆する（ｃ）の「スロースタートで回復」の場合と（ｅ）の「バースト発生」の場合は、不安定性が増加し、複数のパケット紛失発生などを引き起こしている。
【００７４】
なお、１ＡＣＫにより確認されるパケット数は、ＴＣＰのＤｅｌａｙｅｄ−ＡＣＫ機能の実装により異なる。メモリ・メモリ間データ転送の測定データからクライアントがＦｒｅｅＢＳＤの場合と、Ｌｉｎｕｘの場合と、のそれぞれのデータをランダムに抽出し、ＤＡＴＡパケット数：ＡＣＫパケット数の比率を比較したところ、クライアントＯＳがＦｒｅｅＢＳＤの場合は、１．２８：１である。また、Ｌｉｎｕｘの場合は、３：１である。これにより、Ｌｉｎｕｘの場合のほうが１ＡＣＫで確認されるＤＡＴＡパケット数が多いことが判明した。なお、デジタル・シネマ転送の測定データでは４．９〜９．５：１程度であった。
【００７５】
なお、上記実施例におけるデータ転送制御装置は、上述したデータ転送制御処理を実行するデータ転送制御部を具備することになる。このデータ転送制御部は、専用のハードウエアにより実現されるものであってもよく、また、そのデータ転送制御部はメモリおよびＣＰＵ（中央処理装置）により構成され、データ転送制御処理を実現するためのプログラムをメモリに読み込み、その読み込んだプログラムを実行することで上記データ転送制御処理を実現することも可能である。
【００７６】
また、上記データ転送制御処理の各処理工程を実現するためのプログラムをコンピュータ読取可能な記録媒体に記録し、この記録媒体に記録されたプログラムを情報処理装置に読み込ませてデータ転送制御処理を実行することも可能である。なお、情報処理装置とは、ＯＳや周辺機器等のハードウエアを含むものである。
【００７７】
なお、上述する実施例は、本発明の好適な実施例であり、上記実施例のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【産業上の利用可能性】
【００７８】
本発明にかかるデータ転送制御装置、データ転送制御方法およびデータ転送制御プログラムは、ギガビットネットワーク上で想定される高度アプリケーションの形態として、デジタル・シネマなどに適用可能である。
【００７９】
デジタル・シネマとしては、高速ネットワークを介したデジタルデータによる映像配信を行うシステムに適用可能であり、このデジタル・シネマのシステムにより、映画館用のフィルムプリントの作成が不要となることはもとより、暗号化によるセキュリティ強化、上映品質の均一化など、多くのメリットがある。また、動画像を撮影可能な撮像手段を具備するシステムを構築することでイベントのリアルタイム中継などにも適用可能となる。
【図面の簡単な説明】
【００８０】
【図１】本発明にかかる送信ウインドウサイズの時間変化を示唆する図である。
【図２】本発明にかかるネットワーク構成を示す図である。
【図３】図２に示唆するネットワーク構成におけるＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフ図である（ｒｔｔ＝９０ｍｓ）。
【図４】ＲＴＴ毎のＡＣＫにより送達確認された転送レート（スループット）をプロットしたグラフ図である（ｒｔｔ＝９０ｍｓ）。
【図５】３００秒時点でスループットが激減している前後のＤＡＴＡシーケンス、および、ＡＣＫシーケンスの詳細を示唆するグラフ図である。
【図６】送達未確認パケット数をプロットしたグラフ図である。
【図７】第１の対策を実施した後のＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフ図である（ｒｔｔ＝９０ｍｓ）。
【図８】第１の対策を実施した後のＲＴＴ毎のＡＣＫにより送達確認された転送レート（スループット）をプロットしたグラフ図である（ｒｔｔ＝９０ｍｓ）。
【図９】１ｔｉｃｋ内において送出可能なＴＣＰの送出レートの上限値を、帯域推定値×（１＋δ）と設定した場合における処理動作を示唆するフローチャートである。
【図１０】デジタル・シネマのリアルタイム転送アプリケーションツールにおけるＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフ図である（ｒｔｔ＝４５ｍｓ）。
【図１１】ＲＴＴ毎のＡＣＫにより送達確認された転送レート（スループット）をプロットしたグラフ図である（ｒｔｔ＝４５ｍｓ）。
【図１２】ＲＴＴ毎のＡＣＫにより送達未確認のパケット数をプロットしたグラフ図である。
【図１３】図１０に示唆するｄ（殆ど影響なし）におけるパケット紛失発生前後のＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフ図である。
【図１４】図１０に示唆するｄ（殆ど影響なし）におけるＲＴＴ毎のＡＣＫにより送達未確認のパケット数をプロットしたグラフ図である。
【図１５】図１０に示唆するｅ（バースト発生時）におけるパケット紛失発生前後のＤＡＴＡパケットの送信シーケンス（ｓｅｑｕｅｎｃｅ）、および、再送シーケンスを示唆するグラフ図である。
【図１６】図１０に示唆するｅ（バースト発生時）におけるＲＴＴ毎のＡＣＫにより送達未確認のパケット数をプロットしたグラフ図である。
【図１７】従来のＴＣＰと、本実施例の対策１と対策２による改良ＴＣＰと、の試験結果を示唆する図である。
【図１８】図１０に示唆するｃ（スロースタートで回復）の場合の１ＡＣＫ確認ＤＡＴＡパケット数をプロットしたグラフ図である。
【図１９】図１０に示唆するｄ（殆ど影響なし）の場合の１ＡＣＫ確認ＤＡＴＡパケット数をプロットしたグラフ図である。
【図２０】図１０に示唆するｅ（バースト発生）の場合の１ＡＣＫ確認ＤＡＴＡパケット数をプロットしたグラフ図である。
【符号の説明】
【００８１】
１    クライアントＰＣ
２    サーバＰＣ
３    デジタル・シネマ・クライアントＰＣ
４    デジタル・シネマ・サーバＰＣ
５    デジタル・シネマ・デコーダ
１０、１１、１２、１３    ルータＰＣ
２０、２１、２２    ＨＵＢ
３０、３１    測定器
【図１】
2005244517.tif 000003
【図２】
2005244517.tif 000004
【図３】
2005244517.tif 000005
【図４】
2005244517.tif 000006
【図５】
2005244517.tif 000007
【図６】
2005244517.tif 000008
【図７】
2005244517.tif 000009
【図８】
2005244517.tif 000010
【図９】
2005244517.tif 000011
【図１０】
2005244517.tif 000012
【図１１】
2005244517.tif 000013
【図１２】
2005244517.tif 000014
【図１３】
2005244517.tif 000015
【図１４】
2005244517.tif 000016
【図１５】
2005244517.tif 000017
【図１６】
2005244517.tif 000018
【図１７】
2005244517.tif 000019
【図１８】
2005244517.tif 000020
【図１９】
2005244517.tif 000021
【図２０】
2005244517.tif 000022