JP2009206733A - エッジノードおよび帯域制御方法 - Google Patents

Abstract

【課題】パケット廃棄や転送タイムアウトにより低下する輻輳ウィンドウのサイズを早期に向上させ、保証された帯域を効率よく利用可能にしたエッジノードを提供する。
【解決手段】帯域保証ネットワークにてデータ送信端末からデータ受信端末へのサービス対象フローに割り当てられた保証帯域の情報を保持する帯域情報保持部と、サービス対象フローの伝播遅延時間を計測する伝播遅延時間算出部と、上記保証帯域の情報と伝播遅延時間とから、サービス対象フローのデータが保証帯域以内の帯域となるウィンドウサイズを算出するウィンドウサイズ算出部と、ウィンドウサイズをデータ送信端末の帯域制御に使用させるためにデータ送信端末に通知する広告ウィンドウサイズ書き込み部と、データ送信レートを監視する輻輳ウィンドウ低下判断部と、データ送信レートが低下すると、データ送信端末に転送されるＡＣＫパケットを分割するＡＣＫ分割部と、を有する。
【選択図】図２

Description

本発明は、端末間でネットワークを介してデータを送受信する際のフロー制御を行うエッジノードおよび帯域制御方法に関する。

パソコンなどの端末の間ではインターネットなどのコンピュータネットワークを介した通信が行われる。この通信によってファイル等のデータが転送される。この種のデータ転送システムでは、トランスポート層のプロトコルとして、標準的なトランスポートプロトコルであるＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が用いられることが多い。

一般的なＴＣＰでは広告ウィンドウと輻輳ウィンドウという２つのウィンドウが定義されている。広告ウィンドウのサイズはデータ受信側で受信バッファの状態に依存して決定される。輻輳ウィンドウのサイズはデータ送信側でパケット廃棄の状況に応じて決定される。フロー制御に用いられるウィンドウサイズには広告ウィンドウと輻輳ウィンドウのうちいずれか小さい方が選択される。ウィンドウサイズは、応答確認のためのパケットであるＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）パケットがデータ送信側に到着したときに更新される。

上述のフロー制御によるデータ転送においては、大容量のデータを高速に転送することが要求されることがある。これに対してＴＣＰのウィンドウサイズを一定に制御することでスループットを向上させる検討がなされている（非特許文献１）。
"エッジルータにおけるＴＣＰフローレート制御方式の検討"，電子情報通信学会総合大会，２００７年３月 "有線・無線混在ネットワークのためのＴＣＰ動的ＡＣＫ分割手法の解析的評価"，電子情報通信学会総合大会，２００６年３月

ＴＣＰでは、輻輳ウィンドウのサイズをパケット廃棄にしたがって自律的に変化させる帯域制御が行われる。しかし、保証された帯域以上のトラヒックがネットワークに流入するのを防ぐためにネットワークの入り口で流入制限を行っている帯域保証ネットワークにおけるデータ転送では、スループットが鋸歯状に変動し、保証された帯域を十分に活用できないという課題があった。

この課題の対策として、上述したＴＣＰプロトコルに変更を加えることなく、広告ウィンドウを書き換えることで、保証された帯域に合わせた一定のスループットでデータを送信する技術がある（非特許文献１）。しかし、この技術は輻輳ウィンドウよりも広告ウィンドウのサイズが大きいという前提の下で用いられる制御であり、例えばユーザネットワーク内でパケット廃棄が発生すると、輻輳ウィンドウのサイズの低下に伴ってウィンドウサイズが低い値に更新され、その結果、スループットが低下し、保証する帯域を有効に使いきれないという問題があった。

輻輳ウィンドウのサイズが低下する問題の対処方法として、ＡＣＫパケットをデータ受信端末で分割する方式が検討されている（非特許文献２）。しかし、不必要にデータ受信端末でＡＣＫパケットを分割してしまうと、キャリアのネットワーク内に過剰なＡＣＫパケットが流入し、他のフローを逼迫させる可能性がある。

本発明は上述したような技術が有する問題点を解決するためになされたものであり、パケット廃棄や転送タイムアウトにより低下する輻輳ウィンドウのサイズを早期に向上させ、保証された帯域を効率よく利用可能にしたエッジノードおよび帯域制御方法を提供することを目的とする。

上記目的を達成するための本発明のエッジノードは、データ送信端末からデータ受信端末にデータ送信される帯域が保証された帯域保証ネットワークにおいて前記データ送信端末と前記データ受信端末の間に設けられたエッジノードであって、
前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのサービス対象フローに割り当てられた保証帯域の情報を保持する帯域情報保持部と、
前記サービス対象フローの伝播遅延時間を計測する伝播遅延時間算出部と、
前記帯域情報保持部に保持されている前記サービス対象フローの保証帯域の情報と、前記伝播遅延時間算出部で計測された伝播遅延時間とから、前記サービス対象フローのデータが前記保証帯域以内の帯域となるウィンドウサイズを算出するウィンドウサイズ算出部と、
前記ウィンドウサイズ算出部で算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用させるために前記データ送信端末に通知する広告ウィンドウサイズ書き込み部と、
前記データ送信端末におけるデータ送信レートを監視する輻輳ウィンドウ低下判断部と、
前記輻輳ウィンドウ低下判定部が前記データ送信レートの低下を認識すると、前記データ送信端末に転送される、前記サービス対象フローのＡＣＫパケットを分割するＡＣＫ分割部と、
を有する構成である。

また、本発明の帯域制御方法は、データ送信端末からデータ受信端末にデータ送信される帯域が保証された帯域保証ネットワークにおいて前記データ送信端末から前記データ受信端末へのデータ送信の帯域を制御するための帯域制御方法であって、
前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのサービス対象フローに割り当てられた保証帯域の情報を保持し、
前記サービス対象フローの前記帯域保証ネットワークにおける伝播遅延時間を計測し、該伝播遅延時間と前記保証帯域の情報から、前記サービス対象フローのデータが前記保証帯域以内の帯域となるウィンドウサイズを算出し、
算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用し、
前記データ送信端末におけるデータ送信レートを監視し、
前記データ送信端末における前記データ送信レートが低下すると、前記サービス対象フローのＡＣＫパケットを分割するものである。

本発明によれば、帯域保証サービス運用時にデータ送信端末のプロトコルスタックの変更を必要とすることなく、パケット廃棄や転送タイムアウトにより輻輳ウィンドウのサイズが低下した場合でも保証帯域内で安定的にスループットを制御でき、保証帯域を効率よく利用できる。

本実施形態では、データの送信側となるデータ送信端末と、データの受信側となるデータ受信端末との間は、帯域保証ネットワークによって帯域が保証されている構成である。そのため、保証帯域以下でデータを送出している限りパケットの廃棄が生じないことが想定される。それゆえ、データが保証帯域以下で送出されるように広告ウィンドウのサイズを調節すればパケットの廃棄を防ぐことができる。パケットの廃棄が生じなければ輻輳ウィンドウのサイズが小さくならないので常に広告ウィンドウのサイズがＴＣＰウィンドウサイズに採用されることになる。その結果、スループットが鋸歯状に変動しなくなり保証帯域の効率的な利用が可能となる。

そこで、本実施形態では、データ送信端末とデータ受信端末の間でエッジノードがデータ送信側とデータ受信側の間の伝播遅延時間と、帯域保証ネットワークによる保証帯域とから、データが保証帯域以内で送出されるようなウィンドウサイズ（以下、ＢＧＷＮＤ）を算出し、データ受信端末からデータ送信端末へのＡＣＫパケットに記載される広告ウィンドウのサイズを、算出したウィンドウサイズの値に書き換える。

これにより、データ送信端末からデータ受信端末へ送信するデータのレートを保証帯域内で安定的に制御できるので、保証帯域を効率よく利用することができる。

さらに、エッジノードが認識したデータ送信端末の輻輳ウィンドウのサイズの低下にしたがって、ＡＣＫパケットを分割することで、ユーザネットワーク等で発生するパケット廃棄や転送タイムアウトにより発生するスループットの低下を改善し、保証帯域を効率よく利用して高いスループットを保つことが可能となる。

以下に、本実施形態について図面を参照して詳細に説明する。

図１は本実施形態によるデータ送信システムの一構成例を示すブロック図である。

図１を参照すると、本実施形態のデータ送信システムは、エッジノード１１，１２および帯域管理サーバ（ＲＡＣＳ：Ｒｅｓｏｕｒｃｅ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂｓｙｓｔｅｍ）１３を有している。

データ送信端末１４はエッジノード１１に接続され、データ受信端末１５はエッジノード１２に接続されている。エッジノード１１とエッジノード１２は帯域保証ネットワーク１６を介して接続され、そのネットワーク経由でデータを送受信することが可能である。これによりデータ送信端末１４からのデータがエッジノード１１とエッジノード１２を介してデータ受信端末１５に転送される。

帯域管理サーバ１３は帯域保証ネットワーク１６の全リンクの帯域情報を集中的に管理する装置である。帯域情報にはリンクに割り当てられた保証帯域の情報が含まれている。帯域管理サーバ１３は管理している各リンクの帯域情報をエッジノード１１，１２に通知する。帯域管理サーバ１３による帯域管理によって、データ送信端末１４からデータ受信端末１５へのリンクは帯域保証ネットワーク１６でその保証帯域が確保される。その結果、データ送信端末１４が保証帯域以下でデータを送出する限り、保証帯域ネットワーク１６内でのパケット廃棄は発生しない。

次に、本実施形態のエッジノードについて説明する。

図２は本実施形態のエッジノードの一構成例を示すブロック図である。エッジノード１１，１２は同様な構成であるため、ここではエッジノード１１の場合で説明する。

図２を参照すると、エッジノード１１は、データ受信部２１、フロー識別・振り分け部２２、伝搬遅延時間算出部２３、データ送信部２４、帯域情報保持部２５、フロー情報保持部２６、ウィンドウサイズ算出部２７、広告ウィンドウサイズ書き込み部２８、ＡＣＫ分割部２９、および輻輳ウィンドウ低下判断部３０を有している。

データ受信部２１は、データパケットやＡＣＫパケットなどのパケットを受信し、フロー識別・振り分け部２２に送る。

フロー識別・振り分け部２２は、帯域情報保持部２５に帯域情報とともに保持されているユーザ情報を元に、帯域を保証したデータ転送のサービスの対象となるフロー（以下では、サービス対象フローと称する）と、帯域を保証したデータ転送のサービスの対象とならないフロー（以下では、サービス非対象フローと称する）とを識別する。ユーザ情報には、サービス対象であるか否かの情報が含まれている。

また、フロー識別・振り分け部２２は、サービス対象フローのＡＣＫパケットを出力線２２ａを介して広告ウィンドウサイズ書き込み部２８へ、サービス対象フローの分割対象のＡＣＫパケットを出力線２２ｂを介してＡＣＫ分割部２９へ、サービス非対象フローのパケットおよびサービス対象フローのデータパケットを出力線２２ｃを介してデータ送信部２４へと振り分ける。

伝搬遅延時間算出部２３は、データ送信端末１４とデータ受信端末１５の間の往復伝播遅延時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）１７を計測する。

データ送信部２４はフロー識別・振り分け部２２からのパケットと、広告ウィンドウサイズ書き込み部２８からのパケットとを、帯域保証ネットワーク１６を介してエッジノード１２またはデータ送信端末１４へ送信する。なお、データ受信部２１およびデータ送信部２４を合わせて、外部とデータを送受信するための通信部としてもよい。

帯域情報保持部２５は、帯域管理サーバ１３から通知されたサービス対象ユーザの帯域情報とユーザ情報（宛先・送信元ＩＰアドレス、宛先・送信元ポート番号）とを対応付けて保持する。帯域情報には、リンクに割り当てられた保証帯域の情報が含まれている。リンクは、ユーザ情報により識別することが可能となる。

フロー情報保持部２６は、フロー識別・振り分け部２２で識別されるサービス対象フローのコネクション情報と、伝搬遅延時間算出部２３で算出された往復伝播遅延時間とを対応付けて保持する。なお、帯域情報保持部２５およびフロー情報保持部２６は、例えば、ハードディスクや半導体メモリである。

ウィンドウサイズ算出部２７は、フロー情報保持部２６に保持されているデータ送信端末とデータ受信端末間の往復伝搬遅延時間１７と、帯域情報保持部２５に保持されている帯域情報の保証帯域とを用いて、データの送出帯域が保証帯域以内となるようなウィンドウサイズを算出する。

広告ウィンドウサイズ書き込み部２８は、データ受信端末１５からデータ送信端末１４へのＡＣＫパケットのウィンドウフィールドに、ウィンドウサイズ算出部２７で算出されたウィンドウサイズの値を書き込み、そのＡＣＫパケットをデータ送信部２４に送る。

ＡＣＫ分割部２９は、フロー識別・振り分け部２２から転送されたＡＣＫパケットに対してＡＣＫ分割を行い、分割したＡＣＫを広告ウィンドウサイズ書き込み部２８に転送する。

輻輳ウィンドウ低下判断部３０は、フロー識別・振り分け部２２からの要求にしたがって重複ＡＣＫパケット（以下では、重複ＡＣＫと称する）のカウント、および、転送タイムアウトの計測を行って輻輳ウィンドウのサイズを監視し、輻輳ウィンドウのサイズの低下を認めると、フロー識別・振り分け部２２にＡＣＫ分割を要求する。

輻輳ウィンドウ低下判断部３０には、重複ＡＣＫをカウントするための重複ＡＣＫ計測テーブルと、転送タイムアウトであるか否かを判断するための情報を記録するための転送タイマ計測テーブルが格納されている。重複ＡＣＫ計測テーブルには、輻輳ウィンドウのサイズが低下したか否かの判定基準となる重複閾値の情報が予め登録されている。また、重複ＡＣＫ計測テーブルには、送信したＡＣＫパケットのＡＣＫナンバと、重複ＡＣＫを受け取った回数である重複ＡＣＫカウンタが記録される。転送タイマ計測テーブルには、転送タイムアウトであるか否かの判定基準となる転送タイムアウト閾値の情報が予め登録されている。

なお、フロー識別・振り分け部２２、伝搬遅延時間算出部２３、ウィンドウサイズ算出部２７、広告ウィンドウサイズ書き込み部２８、ＡＣＫ分割部２９および輻輳ウィンドウ低下判断部３０について、それぞれ専用の回路を設けてもよいが、エッジノード１１にＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）（不図示）を設け、それらの処理のうちの一部または全部をＣＰＵに実行させてもよい。この場合プログラムを格納するためのメモリ（不図示）もエッジノードに設ける。

次に、図２に示したフロー識別・振り分け部２２によるパケット振り分け処理を詳細に説明する。

図３はフロー識別・振り分け部によるパケット振り分け処理を説明するための図である。

データ送信端末１４とデータ受信端末１５間でコネクションが確立されると、データの転送が開始される。エッジノード１１のフロー識別・振り分け部２２は、データ受信端末１５からのＡＣＫパケットを受信すると、サービス対象フローのＡＣＫパケットか否か判定をする。サービス対象フローのＡＣＫパケットであれば、フロー識別・振り分け部２２は、分割対象のＡＣＫか否か判定する。

上記判定でＡＣＫパケットが分割非対象ＡＣＫである場合、フロー識別・振り分け部２２は、分割非対象ＡＣＫを出力線２２ａを介して広告ウィンドウサイズ書き込み部２８に送る。上記判定でＡＣＫパケットがサービス対象フローのＡＣＫパケットであり、かつ、フロー識別・振り分け部２２が輻輳ウィンドウ低下判断部３０からＡＣＫ分割要求を受けている場合、フロー識別・振り分け部２２は、そのＡＣＫパケットを出力線２２ｂを介してＡＣＫ分割部２９に送る。一方、受け取るパケットがサービス非加入ユーザによるパケットであるサービス非加入ユーザパケットやデータパケットであれば、フロー識別・振り分け部２２はそれらのパケットを出力線２２ｃを介してデータ送信部２４に送る。

次に、往復伝播遅延時間を計測する際の動作手順を説明する。図４は、往復伝播遅延時間を計測するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

図４を参照すると、データ送信端末１４側のエッジノード１１において、フロー識別・振り分け部２２がＳＹＮ（同期）パケットを観測すると（ステップ１０１）、サービス対象フローのユーザ情報と共に往復伝搬遅延時間１７の計測開始要求を伝搬遅延時間算出部２３に送る（ステップ１０２）。これにより伝搬遅延時間算出部２３は往復伝搬遅延時間１７の計測を開始する。その後、フロー識別・振り分け部２２は、ＳＹＮパケットに対するＳＹＮ／ＡＣＫパケットを観測する（ステップ１０３）。

続いて、フロー識別・振り分け部２２は、ＳＹＮ／ＡＣＫに対するＡＣＫパケットを観測すると（ステップ１０４）、ユーザ情報と共に往復伝搬遅延時間１７の計測終了要求を伝搬遅延時間算出部２３に送る（ステップ１０５）。これにより伝搬遅延時間算出部２３は往復伝搬遅延時間１７の計測を終了する。伝搬遅延時間算出部２３は、往復伝搬遅延時間１７の計測を終えると、計測した往復伝搬遅延時間１７をユーザ情報と共に往復伝搬遅延時間報告としてフロー情報保持部２６に通知する（ステップ１０６）。

次に、ウィンドウサイズを算出する際の動作手順を説明する。図５は、ウィンドウサイズを算出するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

フロー情報保持部２６が往復伝播遅延時間算出部２３から往復伝播遅延時間報告を受信すると（ステップ２０１）、ウィンドウサイズ算出部２７に対して、往復伝搬遅延時間１７およびユーザ情報と共に、帯域保証ウィンドウ計算要求をウィンドウサイズ算出部２７に対して通知する（ステップ２０２）。ウィンドウサイズ算出部２７は、帯域保証ウィンドウ計算要求の通知を受けると、一緒に受け取ったユーザ情報を基にして、帯域情報保持部２５に対してユーザ情報に対応する保証帯域の情報を要求する（ステップ２０３）。

帯域情報保持部２５は、ウィンドウサイズ算出部２７からの要求に応じて保証帯域の情報を返送する（ステップ２０４）。ウィンドウサイズ算出部２７は、往復伝搬遅延時間１７と保証帯域の情報を受信すると、それらの情報を基にして、データ送信端末１４が保証帯域以内でデータを送出可能なウィンドウサイズを算出する（ステップ２０５）。このとき保証帯域と一致するレートでデータが送出されるようなウィンドウサイズ（ＢＧＷＮＤに相当）が好適である。

このウィンドウサイズは、例えば、次の式（１）により求めることができる。ＭＳＳは最大セグメントサイズであり、ＨｅａｄｅｒはＬａｙｅｒ２，３，４のヘッダサイズの和である。

次に、ＡＣＫパケットにウィンドウサイズを書き込む際の動作手順を説明する。図６は、ＡＣＫパケットに広告ウィンドウサイズを書き込むときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

図６を参照すると、まずウィンドウサイズ算出部２７がサービス対象フローのウィンドウサイズを算出する（ステップ３０１）。続いて、ウィンドウサイズ算出部２７は算出したウィンドウサイズと、そのサービス対象フローのユーザ情報を広告ウィンドウサイズ書き込み部２８に通知する（ステップ３０２）。広告ウィンドウサイズ書き込み部２８は、ウィンドウサイズ算出部２７から通知されたウィンドウサイズの値を、フロー識別・振り分け部２２から受け取るＡＣＫパケットのウィンドウフィールドに書き込む（ステップ３０３）。広告ウィンドウサイズ書き込み部２８で広告ウィンドウサイズが書き込まれたＡＣＫパケットはデータ送信部２４に送られる。続いて、ウィンドウサイズ算出部２７は算出したウィンドウサイズと、そのサービス対象フローのユーザ情報をＡＣＫ分割部２９に通知する（ステップ３０４）。

次に、輻輳ウィンドウ低下判断部３０が転送タイムアウトを認識した際の動作手順を説明する。図７は、輻輳ウィンドウ低下判断部３０が転送タイムアウトを認識し、ＡＣＫ分割要求をフロー識別・振り分け部２２に通知する際のエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

図７を参照すると、まずフロー識別・振り分け部２２にサービス対象ユーザのデータパケットが到着すると（ステップ４０１）、フロー識別・振り分け部２２は、輻輳ウィンドウ低下判断部３０に対してユーザ情報と転送タイマ計測要求を通知する（ステップ４０２）。輻輳ウィンドウ低下判断部３０は、フロー識別・振り分け部２２からステップ４０２の通知を受けると、転送タイマの計測を開始し、転送タイマ計測開始時刻とユーザ情報を輻輳ウィンドウ低下判断部３０内に存在する転送タイマ計測テーブルに書き込む（ステップ４０３）。

続いて、フロー識別・振り分け部２２にサービス対象ユーザのＡＣＫパケットが到着すると（ステップ４０４）、フロー識別・振り分け部２２は、輻輳ウィンドウ低下判断部３０に対してユーザ情報と転送タイマ計測停止要求を通知する（ステップ４０５）。輻輳ウィンドウ低下判断部３０は、フロー識別・振り分け部２２からステップ４０５の通知を受けると、転送タイマの計測を終了し、転送タイマ計測終了時刻とユーザ情報を輻輳ウィンドウ低下判断部３０内に存在する転送タイマ計測テーブルに書き込む（ステップ４０６）。

そして、輻輳ウィンドウ低下判断部３０は、転送タイマ計測を終了すると、転送タイマ計測終了時刻と転送タイマ計測開始時刻の差をとり、転送タイムアウト閾値と比較することで転送タイムアウトが発生したかを認識する（ステップ４０７）。輻輳ウィンドウ低下判断部３０は、ステップ４０７の判定で転送タイムアウトが発生したと認識した場合、輻輳ウィンドウのサイズが低下したと認識し、フロー識別・振り分け部２２に対してＡＣＫ分割要求を通知する（ステップ４０８）。

なお、データパケットとＡＣＫパケットとの対応付けは、データパケットのシーケンスナンバとＡＣＫパケットのＡＣＫナンバで行う。通常、データパケットのシーケンスナンバにＭＳＳを足した数字のＡＣＫナンバのＡＣＫパケットが、そのデータパケットに対応する応答確認のためのパケットとなる。また、データパケットとＡＣＫパケットとの対応付けは、この場合に限らず、例えば、ウィンドウサイズに対応して複数のデータパケットを連続して送信した場合には、複数のデータパケットのうちの最初のデータパケットと最後のデータパケットに対応するＡＣＫパケットとで対応付けをしてもよい。

次に、輻輳ウィンドウ低下判断部３０が重複ＡＣＫを認識した際の動作手順を説明する。図８は、輻輳ウィンドウ低下判断部３０が重複ＡＣＫを認識し、ＡＣＫ分割要求をフロー識別・振り分け部２２に通知する際のエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

図８を参照すると、まずフロー識別・振り分け部２２にサービス対象ユーザのＡＣＫパケットが到着すると（ステップ５０１）、フロー識別・振り分け部２２は、輻輳ウィンドウ低下判断部３０に対して重複ＡＣＫ計測要求としてユーザ情報とそのＡＣＫパケットのＡＣＫナンバを送信する（ステップ５０２）。輻輳ウィンドウ低下判断部３０は、フロー識別・振り分け部２２からステップ５０２の通知を受けると、ＡＣＫナンバとユーザ情報にしたがって輻輳ウィンドウ低下判断部３０内に存在する重複ＡＣＫ計測テーブル内を参照し、フロー識別・振り分け部２２から通知されたＡＣＫが重複ＡＣＫであるか否かを確認する（ステップ５０３）。

重複ＡＣＫ計測テーブルを参照した結果、フロー識別・振り分け部２２から通知されたＡＣＫが重複ＡＣＫではない場合、輻輳ウィンドウ低下判断部３０は、重複ＡＣＫ計測テーブル内の重複ＡＣＫカウンタをクリアする（ステップ５０４）。一方、フロー識別・振り分け部２２から通知されたＡＣＫが重複ＡＣＫである場合、重複ＡＣＫ計測テーブル内の重複ＡＣＫカウンタに１を加える（ステップ５０５）。ステップ５０５の後、重複ＡＣＫカウンタが重複閾値を超えているか否かを判定し（ステップ５０６）、重複ＡＣＫカウンタが重複閾値を超えている場合、輻輳ウィンドウのサイズが低下したと認識し、フロー識別・振り分け部２２に対して、ユーザ情報と共にＡＣＫ分割要求を通知する（ステップ５０７）。

なお、重複閾値は、１以上の整数であればよく、予め設定しておいてもよく、ネットワークの状況に応じて更新するようにしてもよい。

次に、ＡＣＫ分割部２９がＡＣＫを分割する際の動作手順を説明する。図９は、ＡＣＫ分割部２９がＡＣＫを分割する際のエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

図９を参照すると、まずフロー識別・振り分け部２２は、ＡＣＫ分割要求を受け取った際に（ステップ６０１）、ＡＣＫ分割要求に伴って通知されたユーザ情報にしたがって、ユーザ情報に該当するＡＣＫパケットをＡＣＫ分割部２９に転送する（ステップ６０２）。ＡＣＫ分割部２９はＡＣＫパケットを受け取ると、そのＡＣＫパケットを分割する（ステップ６０３）。その際、１つのＡＣＫパケットの分割数を次のようにして決める。

ＡＣＫパケットを分割しすぎると、輻輳がアクセス網内で発生し逆に輻輳ウィンドウを低下させてしまう可能性がある。そのため、ＡＣＫパケットによって占有される帯域が保証帯域よりも小さくなるようにする。１つのＡＣＫパケットあたりの分割数としては、データパケットとＡＣＫパケットのサイズ比（２５：１）を参考に最大２５分割とするのが最良である。以下では、分割したＡＣＫパケットのそれぞれを分割ＡＣＫパケットと称する。

ＡＣＫ分割部２９は、フロー識別・振り分け部２２からＡＣＫの分割の要求を受けると、データ送信端末１４宛に続けて転送する２つのＡＣＫパケットの間に相当する分割ＡＣＫパケットを、２４個以下で複数生成する。以下に、具体例を説明する。

ＡＣＫナンバ「１０００」のＡＣＫパケットが重複ＡＣＫであるとすると、データ送信端末１４では輻輳ウィンドウのサイズが低下する。その後にＡＣＫナンバ「２０００」のＡＣＫパケットが到達すると、ＡＣＫ分割部２９は、ＡＣＫナンバ「１０００」と「２０００」の間のＡＣＫナンバをそれぞれ有する分割ＡＣＫパケットを生成する。ＡＣＫナンバが「１００１」、・・・、「１０２４」の分割ＡＣＫパケットが生成されれば、ＡＣＫナンバ「１０００」と「２０００」の間が２５分割されたことになる。ただし、各分割ＡＣＫパケットについて、ＡＣＫナンバ以外の情報は、元のＡＣＫナンバ「２０００」のＡＣＫパケットの情報を複写する。

ＡＣＫ分割部２９は、上述のようにして生成した分割ＡＣＫパケットをＡＣＫナンバの一番小さいものから順に広告ウィンドウ書き込み部２８に渡す。分割ＡＣＫパケットのＡＣＫパケットは広告ウィンドウ書き込み部２８およびデータ送信部２４を介してＡＣＫナンバの小さい方から順にデータ送信端末１４に届けられ、最後にＡＣＫナンバ「２０００」のＡＣＫパケットがデータ送信端末１４に届けられる。データ送信端末１４は、一度、輻輳ウィンドウのサイズを低下させてしまっているが、ＡＣＫナンバ「１０００」と「２０００」の間の分割ＡＣＫパケットを多く受け取ることで、輻輳ウィンドウのサイズを早期に向上させようとする。

データ送信端末１４の輻輳ウィンドウのサイズをスループット最大限まで回復させるには、ステップ６０３におけるＡＣＫ分割処理が１回だけでは不充分であることも考えられる。そこで、スループットが最大限まで回復するまで、ＡＣＫパケットの分割数をカウントし、次のようにしてＡＣＫパケットの分割を行う。

分割ＡＣＫパケットの数の総和をＡＣＫ分割数と称すると、ＡＣＫ分割数Ｎは、ウィンドウサイズ算出部２７から通知されたＢＧＷＮＤをもとにした式（２）を満たす値のうち最大整数にするのが最良である。

ＡＣＫ分割部２９は、ＡＣＫ分割数Ｎが式（２）を満たす最大整数になるまでステップ６０３のＡＣＫ分割処理を繰り返し（ステップ６０５）、ＡＣＫ分割数Ｎが式（２）を満たす最大整数に達すると、フロー識別・振り分け部２２に対して、ＡＣＫパケットを自分に転送しなくてよい旨の転送解除要求を通知する（ステップ６０６）。

以下に、具体例を用いて説明する。ＡＣＫ分割部２９は、ステップ６０３でＡＣＫナンバ「１０００」と「２０００」の間を２５分割して２４個の分割ＡＣＫパケットを生成すると、ＡＣＫ分割数Ｎが式（２）を満たしているか否かを判定する（ステップ６０５）。満たしていれば、分割ＡＣＫパケットの数を記録し、生成した分割ＡＣＫパケットを広告ウィンドウ書き込み部２８に渡す。続いて、ＡＣＫ「３０００」のＡＣＫパケットが到達すると、ステップＡＣＫナンバ「２０００」と「３０００」の間を２５分割して２４個の分割ＡＣＫパケットを生成し、ステップ６０５の判定で「Ｎｏ」であれば、既に記録した分割ＡＣＫパケットの数に２４個を加算し、生成した分割ＡＣＫパケットを広告ウィンドウ書き込み部２８に渡す。

ステップ６０３を繰り返し、ＡＣＫ分割部２９は、ステップ６０５で、ＡＣＫ分割数Ｎの値が式（２）の右辺の値を超えていると、右辺の値以下で最大整数を求め、２５分割の分割数を減らしてＡＣＫ分割数Ｎが式（２）を満たす分割数を求める。求めた分割数で生成した分割ＡＣＫパケットを広告ウィンドウ書き込み部２８に渡すとともに、フロー識別・振り分け部２２に対して、ＡＣＫパケットの転送解除要求を通知する（ステップ６０６）。

このようにして、データ送信端末側の輻輳ウィンドウのサイズが一度低下してしまっても、保証される帯域値までスループットをより早く回復させることができる。保証される帯域値を知らない装置がＡＣＫ分割処理を行う際、保証される帯域までスループットを上昇させるのに適したＡＣＫ数がわからないという問題あるが、本実施形態では、スループットを回復できるまでのＡＣＫ分割数を求めているため、その問題が起きることを防ぐことができる。

本実施形態によるデータ通信システムの一構成例を示すブロック図である。 本実施形態のエッジノードの一構成例を示すブロック図である。 フロー識別・振り分け部によるパケット振り分けを説明するための図である。 往復伝搬遅延時間を計測する時のエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。 ウィンドウサイズを算出するときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。 ＡＣＫパケットに広告ウィンドウサイズを書き込むときのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。 輻輳ウィンドウ低下判断部による転送タイムアウト発生の判断からＡＣＫ分割要求までのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。 輻輳ウィンドウ低下判断部による重複ＡＣＫ発生の判断からＡＣＫ分割要求までのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。 ＡＣＫ分割部にＡＣＫ分割からＡＣＫ分割停止でのエッジノード内のブロック間の信号のやりとりを示すシーケンス図である。

符号の説明

１１，１２ エッジノード
１３ 帯域管理サーバ
１４ データ送信端末
１５ データ受信端末
１６ 帯域保証ネットワーク
１７ 往復伝搬遅延時間
２１ データ受信部
２２ フロー識別・振り分け部
２３ 伝搬遅延時間算出部
２４ データ送信部
２５ 帯域情報保持部
２６ フロー情報保持部
２７ ウィンドウサイズ算出部
２８ 広告ウィンドウサイズ書き込み部
２９ ＡＣＫ分割部
３０ 輻輳ウィンドウ低下判断部

Claims (9)

1. データ送信端末からデータ受信端末にデータ送信される帯域が保証された帯域保証ネットワークにおいて前記データ送信端末と前記データ受信端末の間に設けられたエッジノードであって、
   前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのサービス対象フローに割り当てられた保証帯域の情報を保持する帯域情報保持部と、
   前記サービス対象フローの伝播遅延時間を計測する伝播遅延時間算出部と、
   前記帯域情報保持部に保持されている前記サービス対象フローの保証帯域の情報と、前記伝播遅延時間算出部で計測された伝播遅延時間とから、前記サービス対象フローのデータが前記保証帯域以内の帯域となるウィンドウサイズを算出するウィンドウサイズ算出部と、
   前記ウィンドウサイズ算出部で算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用させるために前記データ送信端末に通知する広告ウィンドウサイズ書き込み部と、
   前記データ送信端末におけるデータ送信レートを監視する輻輳ウィンドウ低下判断部と、
   前記輻輳ウィンドウ低下判定部が前記データ送信レートの低下を認識すると、前記データ送信端末に転送される、前記サービス対象フローのＡＣＫパケットを分割するＡＣＫ分割部と、
   を有するエッジノード。
2. 前記輻輳ウィンドウ低下判断部は、
   前記サービス対象フローのＡＣＫパケットの重複受信回数が予め設定された閾値に達すること、または、前記サービス対象フローのデータパケットの受信時刻と該サービス対象フローのＡＣＫパケットの受信時刻との間の時間が予め設定された閾値を超えることにより、前記データ送信端末における前記データ送信レートの低下を認識する、請求項１記載のエッジノード。
3. 前記ＡＣＫ分割部は、
   前記輻輳ウィンドウ低下判断部で前記データ送信レートの低下が認識されると、前記ウィンドウサイズ算出部で算出された前記ウィンドウサイズにしたがって、前記サービス対象フローのＡＣＫパケットを分割したときのパケットである分割ＡＣＫパケットの数の上限値を算出する、請求項１または２に記載のエッジノード。
4. 前記ＡＣＫ分割部は、
   前記上限値を超えないように生成した前記分割ＡＣＫパケットに対して、前記データ受信端末より受け取った前記ＡＣＫパケットのうち最後に受け取ったＡＣＫパケットのＡＣＫナンバよりも大きく、かつ、それぞれ異なるＡＣＫナンバを付与する、請求項３に記載のエッジノード。
5. 前記サービス対象フローを識別してフローを振り分けるフロー識別・振り分け部と、
   前記サービス対象フローのコネクション情報および前記伝播遅延時間を記憶するフロー情報保持部と、をさらに有する請求項１から４のいずれか１項記載のエッジノード。
6. データ送信端末からデータ受信端末にデータ送信される帯域が保証された帯域保証ネットワークにおいて前記データ送信端末から前記データ受信端末へのデータ送信の帯域を制御するための帯域制御方法であって、
   前記帯域保証ネットワークにて前記データ送信端末から前記データ受信端末へのサービス対象フローに割り当てられた保証帯域の情報を保持し、
   前記サービス対象フローの前記帯域保証ネットワークにおける伝播遅延時間を計測し、該伝播遅延時間と前記保証帯域の情報から、前記サービス対象フローのデータが前記保証帯域以内の帯域となるウィンドウサイズを算出し、
   算出された前記ウィンドウサイズを前記データ送信端末の帯域制御に使用し、
   前記データ送信端末におけるデータ送信レートを監視し、
   前記データ送信端末における前記データ送信レートが低下すると、前記サービス対象フローのＡＣＫパケットを分割する、帯域制御方法。
7. 前記データ送信端末における前記データ送信レートが低下したとの判定は、
   前記サービス対象フローのＡＣＫパケットの重複受信回数が予め設定された閾値に達すること、または、前記サービス対象フローのデータパケットの受信時刻と該サービス対象フローのＡＣＫパケットの受信時刻との間の時間が予め設定された閾値を超えることにより行う、請求項６記載の帯域制御方法。
8. 前記サービス対象フローのＡＣＫパケットを分割する際、前記ウィンドウサイズ算出部で算出された前記ウィンドウサイズにしたがって、前記サービス対象フローのＡＣＫパケットを分割したときのパケットである分割ＡＣＫパケットの数の上限値を算出する、請求項６または７に記載の帯域制御方法。
9. 前記サービス対象フローのＡＣＫパケットを分割する際、前記上限値を超えないように生成した前記分割ＡＣＫパケットに対して、前記データ受信端末より受け取った前記ＡＣＫパケットのうち最後に受け取ったＡＣＫパケットのＡＣＫナンバよりも大きく、かつ、それぞれ異なるＡＣＫナンバを付与する、請求項８に記載の帯域制御方法。

Images