輻輳制御装置及び輻輳制御方法
【課題】効果を安定的・効率的に生じさせることができると共に、通信速度が大きく低下するフロー数を常に最小限にすることができる輻輳制御装置及び輻輳制御方法を提供する。
【解決手段】この輻輳制御装置１は、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段７と、先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段３と、ウィンドウサイズ情報検出手段３により検出されたウィンドウサイズ情報の中から最大のウィンドウサイズを含むフローを選択するフロー選択手段４と、フロー選択手段４により選択されたフローの先頭パケットを除く他のパケットを廃棄するパケット廃棄手段６と、各手段を制御する制御部（制御手段）５と、を備え、輻輳制御装置１は、インターフェース２を介してネットワーク８によりエッジノード９と接続されている。
【解決手段】この輻輳制御装置１は、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段７と、先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段３と、ウィンドウサイズ情報検出手段３により検出されたウィンドウサイズ情報の中から最大のウィンドウサイズを含むフローを選択するフロー選択手段４と、フロー選択手段４により選択されたフローの先頭パケットを除く他のパケットを廃棄するパケット廃棄手段６と、各手段を制御する制御部（制御手段）５と、を備え、輻輳制御装置１は、インターフェース２を介してネットワーク８によりエッジノード９と接続されている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、輻輳制御装置及び輻輳制御方法に関し、さらに詳しくは、ＴＣＰ同期現象を効率的に回避する輻輳制御装置及び輻輳制御方法に関するものである。
【背景技術】
【０００２】
近年、低コストのＴＣＰ／ＩＰに基づく汎用通信機器は、インターネットのみならず、企業内の閉域ネットワークへも適用が進んでいる。そして、ネットワークに様々なアプリケーションが取り込まれるに従って、輻輳への対策はますます重要となってきている。輻輳防止のための基本的な対策は、輻輳を発生させないように、ネットワーク設備の増強を行うことであるが、経済的な理由から増強の時期を遅らせざるを得ない場合、あるいは冗長化・負担分散化された通信経路で障害が発生した場合等には、トラフィックの集中するノードで輻輳が発生する可能性が高い。このため、輻輳の発生時においても、効率的に輻輳制御を行えるような対策を行う必要がある。
そこで、大部分のアプリケーションで転送用プロトコルとして用いられているＴＣＰは、設備容量内にトラフィックを抑制するために、通信速度を抑制する輻輳制御の機能を備えている。即ち、通信経路内のノードにおいて輻輳が発生してパケットが廃棄された場合、送信元のＴＣＰがそれを検出し、一度に送信できるパケット数を決めるウィンドウサイズを減少させることにより、ネットワークへのパケット送出速度を抑制して輻輳を解消するものである。
【０００３】
一方、ルータやスイッチの多くは、バッファにおいてＴａｉｌ Ｄｒｏｐ方式を採用している。Ｔａｉｌ Ｄｒｏｐ方式では、到着順にパケットをバッファに蓄積するが、輻輳によりバッファが一杯になった場合は、到着するパケットを廃棄する。このとき、到着するパケットを無作為に廃棄するため、複数のフローにわたってパケットがほぼ連続的に廃棄される（ここで、フローとは、送信側と受信側を１対１でつないでいる通信コネクションのことをいう）。そのため、複数のフローで同時にＴＣＰの輻輳制御機能が働き、そろってウィンドウサイズを半分（もしくは１パケット）まで減少させることから、一時的に通信効率が大きく低下する。また、この状態から、一斉にウィンドウサイズを増加させることとなるが、このときバッファ内のパケット量が減少しており、これに伴い、ＲＴＴ（Round Trip Time）も低下していることから、ウィンドウサイズの増加は急激となる。このため、再び輻輳に陥り、パケット廃棄が発生する。この現象はＴＣＰ同期と呼ばれ、通信効率の低下を招くという問題がある。
【０００４】
このようなＴＣＰ同期を解決する方法として特許文献１には、輻輳の発生により、バッファに到達するパケットを廃棄しなければならなくなったとき、無作為な廃棄ではなく、例えば、フローＡ、Ｂのパケットのみを集中的に廃棄する（フローはパケットヘッダ情報より識別できる）。なお、廃棄するフローの選択基準は、ちょうど到達したパケットのフロー、或いは、到着レートの大きなフロー、ランダムなフローとする等である。これにより、フローＣ、Ｄのパケットがバッファに入り、そのままバッファを通過する。
フローＡ、Ｂはパケットが廃棄された後、そろってウィンドウサイズを減少させるため、これらは速度が低下するものの、それを埋め合わせるように、フローＣ、Ｄは速度を増加させるので、全体として通信効率の低下は起こらない。また、フローＡ、Ｂはその後、そろってウィンドウサイズを増加させることとなるが、このときバッファ内のパケット量は減少しておらず、ＲＴＴも低下していないため、ウィンドウサイズの増加は緩やかになる。加えて、そろって増加するフロー数も少ないため、再び輻輳に陥ることは無い。このため、ＴＣＰ同期が発生せず、通信効率の低下が回避できる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１１−１４６０１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、特許文献１に開示されている従来技術にも課題がある。即ち、従来の方法は、特定のフローにパケット廃棄を集中させることで、その他のフローがパケット廃棄されずに済むようになり、ＴＣＰ同期の回避という効果を生むというものであり、そのため、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることが、効果を安定的、効率的に生じさせるために必要である。このことは、パケット廃棄するフローについては、ＲＴＯ（Retransmission Time Out）の動作となり、通信速度が大きく低下してしまうという観点からも必要であるが、このような機能を持っていない。そのため、その時々で効果がばらついて安定せず、効果が低いときには、通信速度が大きく低下してフローも無駄に多く発生してしまうという課題があった。
本発明は、かかる課題に鑑みてなされたものであり、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加して、輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズの情報を検出して、この情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択して、このフローのパケットを連続的に廃棄することにより、効果を安定的・効率的に生じさせることができると共に、通信速度が大きく低下するフロー数を常に最小限にすることができる輻輳制御装置及び輻輳制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明はかかる課題を解決するために、請求項１は、ＴＣＰ同期現象を回避する輻輳制御装置であって、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段と、前記先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段と、該ウィンドウサイズ情報検出手段により検出されたウィンドウサイズ情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択するフロー選択手段と、該フロー選択手段により選択されたフローのパケットを連続的に廃棄するパケット廃棄手段と、前記各手段を制御する制御手段と、を備えたことを特徴とする。
ＴＣＰでは、送信側が、受信側からの確認応答パケットの返信を待たずに、一度に送付するパケット数は、ウィンドウサイズ分だけである。そのため、一つのフローにつき、廃棄されるパケット数は、最大でもウィンドウサイズ分である。この廃棄されるパケット数は、到達するウィンドウサイズ分のパケット群の中のどの位置から廃棄を開始するかによって異なってくる。すなわち、パケット群の最初の方であれば、最大でウィンドウサイズ分のパケット数が廃棄されるが、パケット群の最後の方であれば、最小で１パケットとなる。即ち、一つのフローにつき、最大限のパケット数を廃棄するためには、到達するウィンドウサイズ分のパケット群の中で、なるべく最初の方のパケットから廃棄する必要がある。そこで本発明では、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加して、輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズの情報を検出して、この情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択して、このフローのパケットを連続的に廃棄する。これにより、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる。
【０００８】
請求項２は、前記制御手段は、送信側のＴＣＰで前記ウィンドウサイズの情報を付加することができない場合、エッジノードにて前記送信側に対しては擬似ＡＣＫを返信し、受信側に対しては新たなＴＣＰを張り直すようにした上で、新たに張り直すＴＣＰにおいて先頭パケットに該ウィンドウサイズの情報を付加することを特徴とする。
様々な都合により、送信側のＴＣＰでウィンドウサイズの情報を付加することができない場合がある。そのような場合、新たに張り直すＴＣＰにおいて先頭パケットにウィンドウサイズの情報を付加する。これにより、送信側のＴＣＰでウィンドウサイズの情報を付加することができない場合でも、新たなＴＣＰでウィンドウサイズの情報を付加することができる。
【０００９】
請求項３は、前記制御手段は、前記ウィンドウサイズ情報検出手段によりウィンドウサイズの情報を検出したことを認識すると、該ウィンドウサイズの情報を消去することを特徴とする。
輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズ情報を検出するが、そのウィンドウサイズ情報を付加したまま送信すると、受信側で不具合が出ないとも限らない。そこで本発明では、検出した後は消去することで、受信側に何ら影響を与えないようにする。
【００１０】
請求項４は、ウィンドウサイズ付加手段、ウィンドウサイズ情報検出手段、フロー選択手段、パケット廃棄手段、及び制御手段を備えた輻輳制御装置の輻輳制御方法であって、前記ウィンドウサイズ付加手段が、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するステップと、前記ウィンドウサイズ情報検出手段が、前記先頭パケットに付加されたウィンドウサイズの情報を検出するステップと、前記フロー選択手段が、前記ウィンドウサイズ情報検出手段により解析されたウィンドウサイズの情報の中から最大のウィンドウサイズを含むフローを選択するステップと、前記パケット廃棄手段が、前記フロー選択手段により選択されたフローの先頭パケット以外のパケットを廃棄するステップと、前記制御手段が、前記各手段を制御するステップと、を備えたことを特徴とする。
請求項１と同様の作用効果を奏する。
【発明の効果】
【００１１】
本発明によれば、効果を安定的・効率的に生じさせることができると共に、通信速度が大きく低下するフロー数を常に最小限にすることができる。
また、送信側・受信側のＴＣＰには何ら変更を加えず、ネットワーク中のノードの機能だけで対処することができるため、運用面や経済面における様々な現実的事情により、送信側・受信側のＴＣＰを変更できない場合にも適用でき、実導入面で有利である。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に係る輻輳制御装置の機能を示すブロック図である。
【図２】ネットワーク図の一例を示す図である。
【図３】（ａ）は従来方法によるパケット廃棄を説明する図、（ｂ）は本発明によるパケット廃棄を説明する図である。
【発明を実施するための形態】
【００１３】
以下、本発明を図に示した実施形態を用いて詳細に説明する。但し、この実施形態に記載される構成要素、種類、組み合わせ、形状、その相対配置などは特定的な記載がない限り、この発明の範囲をそれのみに限定する主旨ではなく単なる説明例に過ぎない。
【００１４】
図１は本発明の一実施形態に係る輻輳制御装置の機能を示すブロック図である。この輻輳制御装置１は、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段７と、先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段３と、ウィンドウサイズ情報検出手段３により検出されたウィンドウサイズ情報の中から最大のウィンドウサイズを含むフローを選択するフロー選択手段４と、フロー選択手段４により選択されたフローの先頭パケットを除く他のパケットを廃棄するパケット廃棄手段６と、各手段を制御する制御部（制御手段）５と、を備え、輻輳制御装置１は、インターフェース２を介してネットワーク８によりエッジノード９と接続されている。尚、本実施形態の場合は、輻輳制御装置１は輻輳中のコアノード１１内に備えられ、エッジノード９にも同様な構成の輻輳制御装置１が備えられている。従って、どこに備えられているかにより、機能する手段と機能しない手段がある。
即ち、ＴＣＰでは、送信側が、受信側からの確認応答パケット（以下、ＡＣＫという）の返信を待たずに、一度に送付するパケット数は、ウィンドウサイズ分だけである。そのため、一つのフローにつき、廃棄されるパケット数は、最大でもウィンドウサイズ分である。この廃棄されるパケット数は、到達するウィンドウサイズ分のパケット群の中のどの位置から廃棄を開始するかによって異なってくる。すなわち、パケット群の最初の方であれば、最大でウィンドウサイズ分のパケット数が廃棄されるが、パケット群の最後の方であれば、最小で１パケットとなる。即ち、一つのフローにつき、最大限のパケット数を廃棄するためには、到達するウィンドウサイズ分のパケット群の中で、なるべく最初の方のパケットから廃棄する必要がある。そこで本発明では、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加して、輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズの情報を検出して、この情報の中から最大のウィンドウサイズを含むフローを選択して、このフローの先頭パケットを除いた全てのパケットを廃棄する。これにより、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる（詳細は図３で説明する）。
【００１５】
図２はネットワーク図の一例を示す図である。送信端１０の回線を集約しているノードをエッジノード９、それ以外を輻輳中のノード１１とする。エッジノード９はネットワーク８中に複数存在する。エッジノード９は、送信端１０からパケットを受け取ると、すぐに確認応答（ＡＣＫ）パケットを送信端１０に返信する。一方、エッジノード９が受け取ったパケットは、輻輳中のノード１１へ送られ、図示しない受信端へ到着すると、受信端から確認応答（ＡＣＫ）パケットを受け取る。つまり、エッジノード９でＴＣＰコネクションが張りなおされる形となる。このとき、エッジノード９から見て、送信端１０側のネットワークはＲＴＴ（Round Trip Time）が小さいので通信速度は速く、逆に輻輳中のノード１１側のネットワークはＲＴＴが大きいので通信速度は遅い。そのため、この速度差によってエッジノード９のバッファには自然にパケットが蓄積される。これは、送信端１０が持っていた送信データがエッジノード９のバッファに引っ張り出されるイメージとなる。このような原理上、バッファにパケットが蓄積されていても、通信遅延は発生していない。また、このバッファは、ＴＣＰコネクションで繋がったパケットを蓄積するものではないので、たとえ保持時間が長い場合でも、タイムアウトでＴＣＰが切断されることはない。
【００１６】
図３は本発明の輻輳制御装置の動作を説明するために、従来方法との比較で例示した図である。図３（ａ）は従来方法によるパケット廃棄を説明する図、図３（ｂ）は本発明によるパケット廃棄を説明する図である。
特定のフローにパケット廃棄を集中させることで、その他のフローがパケット廃棄されずに済むようになり、ＴＣＰ同期の回避という効果を生むというものである。そのため、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることが、効果を安定的、効率的に生じさせるために必要である。このことは、パケット廃棄するフローについては、ＲＴＯ（Retransmission Time Out）の動作となり、通信速度が大きく低下してしまうという観点からも必要である（ＲＴＯとは、ウィンドウサイズ内で複数のパケット廃棄が発生した場合に、輻輳の度合いが大きいと判断し、送信側にて数秒間待ってからウィンドウサイズを１パケットまで減少させて再送を開始するというＴＣＰの動作である）。しかし、従来の方法は、このような機能を持っていない。そのため、その時々で効果がばらついて安定せず、効果が低いときには、通信速度が大きく低下するフローも無駄に多く発生してしまうという課題があった。
【００１７】
図３（ａ）を用いて更に詳細に説明すると、フローＡ〜Ｄごとに所定のウィンドウサイズでパケットが到着した場合について説明する。図の右側が輻輳中のノードへのパケット到着順が先で、左側が後である。ここで廃棄パケット数が２の場合について説明する。ウィンドウサイズがＰ１−１〜Ｐ１−５のパケット群では、Ｐ１−１〜Ｐ１−３がフローＡであり、Ｐ１−４〜Ｐ１−５までがフローＢである。同じく、ウィンドウサイズがＰ２−１〜Ｐ２−１２のパケット群では、Ｐ２−１〜Ｐ２−６がフローＢであり、Ｐ２−７〜Ｐ２−１２までがフローＣである。同じく、ウィンドウサイズがＰ３−１〜Ｐ３−２のパケット群では、Ｐ３−１〜Ｐ３−２がフローＣである。同じく、ウィンドウサイズがＰ４−１〜Ｐ４−８のパケット群では、Ｐ４−１〜Ｐ４−８がフローＤである。ここで、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１がウィンドウサイズの最初のパケットとすると、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１には何ら情報が付加されておらず、ノードで識別することができない。その結果、フローＡのパケットＰ１−２、Ｐ１−３、及びフローＢのＰ２−２〜Ｐ２−６までが廃棄パケットとなると、廃棄パケット数が７で、廃棄フロー数は２となる。
それに対して本発明では、一つのフローにつき、最大限のパケットを廃棄することに取り組む。これにより、最小限のフロー数で、必要な廃棄パケット数を確保することができる。よって、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる。
【００１８】
以下、詳細に説明する。
ＴＣＰ通信では、送信側が受信側からの確認応答パケット（以下、ＡＣＫという）の返信を待たずに、一度に送付するパケット数は、ウィンドウサイズ分だけである。そのため、一つのフローにつき、廃棄されるパケット数は、最大でもウィンドウサイズ分である。この廃棄されるパケット数は、到達するウィンドウサイズ分のパケット群の中のどの位置から廃棄を開始するかによって異なってくる。即ち、パケット群の最初の方であれば、最大でウィンドウサイズ分のパケット数が廃棄されるが、パケット群の最後の方であれば、最小で１パケットとなる。
立ち返って、一つのフローにつき、最大限のパケット数を廃棄するためには、到達するウィンドウサイズ分のパケット群の中で、なるべく最初の方のパケットから廃棄する必要がある。しかし、ネットワーク中のノードは、到達したパケットがウィンドウサイズ分のパケット群の中で、どの位置にあるかを判別する機能を持っていない（パケットの順番はシーケンス番号から判別できるものの、ウィンドウサイズの端がどこなのか判別できない）。
【００１９】
そこで、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加することとする。ここで、現時点のウィンドウサイズとする理由は、ウィンドウサイズはパケット廃棄に伴い、ＴＣＰによって決められた最大値を上限として増減するため、その時々で、およびフロー毎で異なるためである。ウィンドウサイズは、パケット数で表してもよいし、バイト数で表してもよいが、ここでは前者として説明する。
この情報を付加するには、例えば、ＴＣＰヘッダのウィンドウサイズ・フィールドや、ＩＰヘッダのオプション・フィールドなどを利用すればよい（前者は、通常、ＡＣＫで用いられている。つまり、受信側から送信側に対して、現状の受信バッファの空き容量を通知し、スライディング・ウィンドウ方式でパケットを受け取るために用いられている。後者は、通常、使用されていない）。
また、様々な都合により、送信側のＴＣＰで情報を付加することができない場合は、例えば、エッジノード９にて、送信側に対しては疑似ＡＣＫを返信し、受信側に対しては新たにＴＣＰを張り直すようにした上で、新たに張り直すＴＣＰで先頭パケットにこの情報を付加すればよい。
【００２０】
一方、輻輳中のノード１１では、先頭パケットに付加されたウィンドウサイズの情報を検出する。なお、検出した後は消去することで、受信側に何ら影響を与えないようにしてもよい。そして、検出したウィンドウサイズ（ここでは、パケット数で表されている）を初期値とする変数Ｎをフロー毎に管理テーブルで管理する。変数Ｎは、次々とそのフローのパケットが到達する度に、１ずつ減じていき、最後の到達パケットで１となるようにする。輻輳中のノードは、この変数Ｎを管理することにより、現時点での到達パケットがウィンドウサイズ分のパケット群の中で、どの位置にあって、あとどのくらいのパケットが送付されてくるかをフロー毎に知ることができる。
ここで、バッファが一杯になり、パケットを廃棄しなければならなくなったとする。本発明では、到着するパケットから廃棄するのではなく、現時点でバッファに蓄積されているパケットの中から、より変数Ｎが大きいパケットを含むフローを選択し、廃棄していく。以上により、一つのフローにつき、最大限のパケットを廃棄することができるようになる。この結果、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる。
【００２１】
図３（ｂ）を用いて更に詳細に説明すると、フローＡ〜Ｄごとに所定のウィンドウサイズでパケットが到着した場合について説明する。図の右側が輻輳中のノードへのパケット到着順が先で、左側が後である。ここで廃棄パケット数が２の場合について説明する。フローとウィンドウサイズの関係は図３（ａ）と同様であるので説明を省略する。ここで、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１がウィンドウサイズの最初のパケットとすると、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１にはウィンドウサイズの情報が付加されており、ノードで識別することができる。その結果、フローＤのパケットＰ４−２〜Ｐ４−８までが廃棄パケットとなると、廃棄パケット数が７で、廃棄フロー数は１となり、図３と比較して、廃棄パケット数は同じであるが、廃棄フロー数を減少させることができる。
【符号の説明】
【００２２】
１ 輻輳制御装置、２ インターフェース、３ ウィンドウサイズ情報検出手段、４ フロー選択手段、５ 制御部、６ パケット廃棄手段、７ ウィンドウサイズ付加手段、８ ネットワーク、９ エッジノード、１０ 送信端、１１ 輻輳中のノード
【技術分野】
【０００１】
本発明は、輻輳制御装置及び輻輳制御方法に関し、さらに詳しくは、ＴＣＰ同期現象を効率的に回避する輻輳制御装置及び輻輳制御方法に関するものである。
【背景技術】
【０００２】
近年、低コストのＴＣＰ／ＩＰに基づく汎用通信機器は、インターネットのみならず、企業内の閉域ネットワークへも適用が進んでいる。そして、ネットワークに様々なアプリケーションが取り込まれるに従って、輻輳への対策はますます重要となってきている。輻輳防止のための基本的な対策は、輻輳を発生させないように、ネットワーク設備の増強を行うことであるが、経済的な理由から増強の時期を遅らせざるを得ない場合、あるいは冗長化・負担分散化された通信経路で障害が発生した場合等には、トラフィックの集中するノードで輻輳が発生する可能性が高い。このため、輻輳の発生時においても、効率的に輻輳制御を行えるような対策を行う必要がある。
そこで、大部分のアプリケーションで転送用プロトコルとして用いられているＴＣＰは、設備容量内にトラフィックを抑制するために、通信速度を抑制する輻輳制御の機能を備えている。即ち、通信経路内のノードにおいて輻輳が発生してパケットが廃棄された場合、送信元のＴＣＰがそれを検出し、一度に送信できるパケット数を決めるウィンドウサイズを減少させることにより、ネットワークへのパケット送出速度を抑制して輻輳を解消するものである。
【０００３】
一方、ルータやスイッチの多くは、バッファにおいてＴａｉｌ Ｄｒｏｐ方式を採用している。Ｔａｉｌ Ｄｒｏｐ方式では、到着順にパケットをバッファに蓄積するが、輻輳によりバッファが一杯になった場合は、到着するパケットを廃棄する。このとき、到着するパケットを無作為に廃棄するため、複数のフローにわたってパケットがほぼ連続的に廃棄される（ここで、フローとは、送信側と受信側を１対１でつないでいる通信コネクションのことをいう）。そのため、複数のフローで同時にＴＣＰの輻輳制御機能が働き、そろってウィンドウサイズを半分（もしくは１パケット）まで減少させることから、一時的に通信効率が大きく低下する。また、この状態から、一斉にウィンドウサイズを増加させることとなるが、このときバッファ内のパケット量が減少しており、これに伴い、ＲＴＴ（Round Trip Time）も低下していることから、ウィンドウサイズの増加は急激となる。このため、再び輻輳に陥り、パケット廃棄が発生する。この現象はＴＣＰ同期と呼ばれ、通信効率の低下を招くという問題がある。
【０００４】
このようなＴＣＰ同期を解決する方法として特許文献１には、輻輳の発生により、バッファに到達するパケットを廃棄しなければならなくなったとき、無作為な廃棄ではなく、例えば、フローＡ、Ｂのパケットのみを集中的に廃棄する（フローはパケットヘッダ情報より識別できる）。なお、廃棄するフローの選択基準は、ちょうど到達したパケットのフロー、或いは、到着レートの大きなフロー、ランダムなフローとする等である。これにより、フローＣ、Ｄのパケットがバッファに入り、そのままバッファを通過する。
フローＡ、Ｂはパケットが廃棄された後、そろってウィンドウサイズを減少させるため、これらは速度が低下するものの、それを埋め合わせるように、フローＣ、Ｄは速度を増加させるので、全体として通信効率の低下は起こらない。また、フローＡ、Ｂはその後、そろってウィンドウサイズを増加させることとなるが、このときバッファ内のパケット量は減少しておらず、ＲＴＴも低下していないため、ウィンドウサイズの増加は緩やかになる。加えて、そろって増加するフロー数も少ないため、再び輻輳に陥ることは無い。このため、ＴＣＰ同期が発生せず、通信効率の低下が回避できる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平１１−１４６０１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、特許文献１に開示されている従来技術にも課題がある。即ち、従来の方法は、特定のフローにパケット廃棄を集中させることで、その他のフローがパケット廃棄されずに済むようになり、ＴＣＰ同期の回避という効果を生むというものであり、そのため、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることが、効果を安定的、効率的に生じさせるために必要である。このことは、パケット廃棄するフローについては、ＲＴＯ（Retransmission Time Out）の動作となり、通信速度が大きく低下してしまうという観点からも必要であるが、このような機能を持っていない。そのため、その時々で効果がばらついて安定せず、効果が低いときには、通信速度が大きく低下してフローも無駄に多く発生してしまうという課題があった。
本発明は、かかる課題に鑑みてなされたものであり、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加して、輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズの情報を検出して、この情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択して、このフローのパケットを連続的に廃棄することにより、効果を安定的・効率的に生じさせることができると共に、通信速度が大きく低下するフロー数を常に最小限にすることができる輻輳制御装置及び輻輳制御方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明はかかる課題を解決するために、請求項１は、ＴＣＰ同期現象を回避する輻輳制御装置であって、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段と、前記先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段と、該ウィンドウサイズ情報検出手段により検出されたウィンドウサイズ情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択するフロー選択手段と、該フロー選択手段により選択されたフローのパケットを連続的に廃棄するパケット廃棄手段と、前記各手段を制御する制御手段と、を備えたことを特徴とする。
ＴＣＰでは、送信側が、受信側からの確認応答パケットの返信を待たずに、一度に送付するパケット数は、ウィンドウサイズ分だけである。そのため、一つのフローにつき、廃棄されるパケット数は、最大でもウィンドウサイズ分である。この廃棄されるパケット数は、到達するウィンドウサイズ分のパケット群の中のどの位置から廃棄を開始するかによって異なってくる。すなわち、パケット群の最初の方であれば、最大でウィンドウサイズ分のパケット数が廃棄されるが、パケット群の最後の方であれば、最小で１パケットとなる。即ち、一つのフローにつき、最大限のパケット数を廃棄するためには、到達するウィンドウサイズ分のパケット群の中で、なるべく最初の方のパケットから廃棄する必要がある。そこで本発明では、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加して、輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズの情報を検出して、この情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択して、このフローのパケットを連続的に廃棄する。これにより、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる。
【０００８】
請求項２は、前記制御手段は、送信側のＴＣＰで前記ウィンドウサイズの情報を付加することができない場合、エッジノードにて前記送信側に対しては擬似ＡＣＫを返信し、受信側に対しては新たなＴＣＰを張り直すようにした上で、新たに張り直すＴＣＰにおいて先頭パケットに該ウィンドウサイズの情報を付加することを特徴とする。
様々な都合により、送信側のＴＣＰでウィンドウサイズの情報を付加することができない場合がある。そのような場合、新たに張り直すＴＣＰにおいて先頭パケットにウィンドウサイズの情報を付加する。これにより、送信側のＴＣＰでウィンドウサイズの情報を付加することができない場合でも、新たなＴＣＰでウィンドウサイズの情報を付加することができる。
【０００９】
請求項３は、前記制御手段は、前記ウィンドウサイズ情報検出手段によりウィンドウサイズの情報を検出したことを認識すると、該ウィンドウサイズの情報を消去することを特徴とする。
輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズ情報を検出するが、そのウィンドウサイズ情報を付加したまま送信すると、受信側で不具合が出ないとも限らない。そこで本発明では、検出した後は消去することで、受信側に何ら影響を与えないようにする。
【００１０】
請求項４は、ウィンドウサイズ付加手段、ウィンドウサイズ情報検出手段、フロー選択手段、パケット廃棄手段、及び制御手段を備えた輻輳制御装置の輻輳制御方法であって、前記ウィンドウサイズ付加手段が、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するステップと、前記ウィンドウサイズ情報検出手段が、前記先頭パケットに付加されたウィンドウサイズの情報を検出するステップと、前記フロー選択手段が、前記ウィンドウサイズ情報検出手段により解析されたウィンドウサイズの情報の中から最大のウィンドウサイズを含むフローを選択するステップと、前記パケット廃棄手段が、前記フロー選択手段により選択されたフローの先頭パケット以外のパケットを廃棄するステップと、前記制御手段が、前記各手段を制御するステップと、を備えたことを特徴とする。
請求項１と同様の作用効果を奏する。
【発明の効果】
【００１１】
本発明によれば、効果を安定的・効率的に生じさせることができると共に、通信速度が大きく低下するフロー数を常に最小限にすることができる。
また、送信側・受信側のＴＣＰには何ら変更を加えず、ネットワーク中のノードの機能だけで対処することができるため、運用面や経済面における様々な現実的事情により、送信側・受信側のＴＣＰを変更できない場合にも適用でき、実導入面で有利である。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に係る輻輳制御装置の機能を示すブロック図である。
【図２】ネットワーク図の一例を示す図である。
【図３】（ａ）は従来方法によるパケット廃棄を説明する図、（ｂ）は本発明によるパケット廃棄を説明する図である。
【発明を実施するための形態】
【００１３】
以下、本発明を図に示した実施形態を用いて詳細に説明する。但し、この実施形態に記載される構成要素、種類、組み合わせ、形状、その相対配置などは特定的な記載がない限り、この発明の範囲をそれのみに限定する主旨ではなく単なる説明例に過ぎない。
【００１４】
図１は本発明の一実施形態に係る輻輳制御装置の機能を示すブロック図である。この輻輳制御装置１は、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段７と、先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段３と、ウィンドウサイズ情報検出手段３により検出されたウィンドウサイズ情報の中から最大のウィンドウサイズを含むフローを選択するフロー選択手段４と、フロー選択手段４により選択されたフローの先頭パケットを除く他のパケットを廃棄するパケット廃棄手段６と、各手段を制御する制御部（制御手段）５と、を備え、輻輳制御装置１は、インターフェース２を介してネットワーク８によりエッジノード９と接続されている。尚、本実施形態の場合は、輻輳制御装置１は輻輳中のコアノード１１内に備えられ、エッジノード９にも同様な構成の輻輳制御装置１が備えられている。従って、どこに備えられているかにより、機能する手段と機能しない手段がある。
即ち、ＴＣＰでは、送信側が、受信側からの確認応答パケット（以下、ＡＣＫという）の返信を待たずに、一度に送付するパケット数は、ウィンドウサイズ分だけである。そのため、一つのフローにつき、廃棄されるパケット数は、最大でもウィンドウサイズ分である。この廃棄されるパケット数は、到達するウィンドウサイズ分のパケット群の中のどの位置から廃棄を開始するかによって異なってくる。すなわち、パケット群の最初の方であれば、最大でウィンドウサイズ分のパケット数が廃棄されるが、パケット群の最後の方であれば、最小で１パケットとなる。即ち、一つのフローにつき、最大限のパケット数を廃棄するためには、到達するウィンドウサイズ分のパケット群の中で、なるべく最初の方のパケットから廃棄する必要がある。そこで本発明では、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加して、輻輳中のノードでは、先頭パケットに付加されたウィンドウサイズの情報を検出して、この情報の中から最大のウィンドウサイズを含むフローを選択して、このフローの先頭パケットを除いた全てのパケットを廃棄する。これにより、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる（詳細は図３で説明する）。
【００１５】
図２はネットワーク図の一例を示す図である。送信端１０の回線を集約しているノードをエッジノード９、それ以外を輻輳中のノード１１とする。エッジノード９はネットワーク８中に複数存在する。エッジノード９は、送信端１０からパケットを受け取ると、すぐに確認応答（ＡＣＫ）パケットを送信端１０に返信する。一方、エッジノード９が受け取ったパケットは、輻輳中のノード１１へ送られ、図示しない受信端へ到着すると、受信端から確認応答（ＡＣＫ）パケットを受け取る。つまり、エッジノード９でＴＣＰコネクションが張りなおされる形となる。このとき、エッジノード９から見て、送信端１０側のネットワークはＲＴＴ（Round Trip Time）が小さいので通信速度は速く、逆に輻輳中のノード１１側のネットワークはＲＴＴが大きいので通信速度は遅い。そのため、この速度差によってエッジノード９のバッファには自然にパケットが蓄積される。これは、送信端１０が持っていた送信データがエッジノード９のバッファに引っ張り出されるイメージとなる。このような原理上、バッファにパケットが蓄積されていても、通信遅延は発生していない。また、このバッファは、ＴＣＰコネクションで繋がったパケットを蓄積するものではないので、たとえ保持時間が長い場合でも、タイムアウトでＴＣＰが切断されることはない。
【００１６】
図３は本発明の輻輳制御装置の動作を説明するために、従来方法との比較で例示した図である。図３（ａ）は従来方法によるパケット廃棄を説明する図、図３（ｂ）は本発明によるパケット廃棄を説明する図である。
特定のフローにパケット廃棄を集中させることで、その他のフローがパケット廃棄されずに済むようになり、ＴＣＰ同期の回避という効果を生むというものである。そのため、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることが、効果を安定的、効率的に生じさせるために必要である。このことは、パケット廃棄するフローについては、ＲＴＯ（Retransmission Time Out）の動作となり、通信速度が大きく低下してしまうという観点からも必要である（ＲＴＯとは、ウィンドウサイズ内で複数のパケット廃棄が発生した場合に、輻輳の度合いが大きいと判断し、送信側にて数秒間待ってからウィンドウサイズを１パケットまで減少させて再送を開始するというＴＣＰの動作である）。しかし、従来の方法は、このような機能を持っていない。そのため、その時々で効果がばらついて安定せず、効果が低いときには、通信速度が大きく低下するフローも無駄に多く発生してしまうという課題があった。
【００１７】
図３（ａ）を用いて更に詳細に説明すると、フローＡ〜Ｄごとに所定のウィンドウサイズでパケットが到着した場合について説明する。図の右側が輻輳中のノードへのパケット到着順が先で、左側が後である。ここで廃棄パケット数が２の場合について説明する。ウィンドウサイズがＰ１−１〜Ｐ１−５のパケット群では、Ｐ１−１〜Ｐ１−３がフローＡであり、Ｐ１−４〜Ｐ１−５までがフローＢである。同じく、ウィンドウサイズがＰ２−１〜Ｐ２−１２のパケット群では、Ｐ２−１〜Ｐ２−６がフローＢであり、Ｐ２−７〜Ｐ２−１２までがフローＣである。同じく、ウィンドウサイズがＰ３−１〜Ｐ３−２のパケット群では、Ｐ３−１〜Ｐ３−２がフローＣである。同じく、ウィンドウサイズがＰ４−１〜Ｐ４−８のパケット群では、Ｐ４−１〜Ｐ４−８がフローＤである。ここで、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１がウィンドウサイズの最初のパケットとすると、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１には何ら情報が付加されておらず、ノードで識別することができない。その結果、フローＡのパケットＰ１−２、Ｐ１−３、及びフローＢのＰ２−２〜Ｐ２−６までが廃棄パケットとなると、廃棄パケット数が７で、廃棄フロー数は２となる。
それに対して本発明では、一つのフローにつき、最大限のパケットを廃棄することに取り組む。これにより、最小限のフロー数で、必要な廃棄パケット数を確保することができる。よって、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる。
【００１８】
以下、詳細に説明する。
ＴＣＰ通信では、送信側が受信側からの確認応答パケット（以下、ＡＣＫという）の返信を待たずに、一度に送付するパケット数は、ウィンドウサイズ分だけである。そのため、一つのフローにつき、廃棄されるパケット数は、最大でもウィンドウサイズ分である。この廃棄されるパケット数は、到達するウィンドウサイズ分のパケット群の中のどの位置から廃棄を開始するかによって異なってくる。即ち、パケット群の最初の方であれば、最大でウィンドウサイズ分のパケット数が廃棄されるが、パケット群の最後の方であれば、最小で１パケットとなる。
立ち返って、一つのフローにつき、最大限のパケット数を廃棄するためには、到達するウィンドウサイズ分のパケット群の中で、なるべく最初の方のパケットから廃棄する必要がある。しかし、ネットワーク中のノードは、到達したパケットがウィンドウサイズ分のパケット群の中で、どの位置にあるかを判別する機能を持っていない（パケットの順番はシーケンス番号から判別できるものの、ウィンドウサイズの端がどこなのか判別できない）。
【００１９】
そこで、送信側のＴＣＰにおいて、ウィンドウサイズ分のパケット群の中で、先頭パケットに、現時点のウィンドウサイズを情報として付加することとする。ここで、現時点のウィンドウサイズとする理由は、ウィンドウサイズはパケット廃棄に伴い、ＴＣＰによって決められた最大値を上限として増減するため、その時々で、およびフロー毎で異なるためである。ウィンドウサイズは、パケット数で表してもよいし、バイト数で表してもよいが、ここでは前者として説明する。
この情報を付加するには、例えば、ＴＣＰヘッダのウィンドウサイズ・フィールドや、ＩＰヘッダのオプション・フィールドなどを利用すればよい（前者は、通常、ＡＣＫで用いられている。つまり、受信側から送信側に対して、現状の受信バッファの空き容量を通知し、スライディング・ウィンドウ方式でパケットを受け取るために用いられている。後者は、通常、使用されていない）。
また、様々な都合により、送信側のＴＣＰで情報を付加することができない場合は、例えば、エッジノード９にて、送信側に対しては疑似ＡＣＫを返信し、受信側に対しては新たにＴＣＰを張り直すようにした上で、新たに張り直すＴＣＰで先頭パケットにこの情報を付加すればよい。
【００２０】
一方、輻輳中のノード１１では、先頭パケットに付加されたウィンドウサイズの情報を検出する。なお、検出した後は消去することで、受信側に何ら影響を与えないようにしてもよい。そして、検出したウィンドウサイズ（ここでは、パケット数で表されている）を初期値とする変数Ｎをフロー毎に管理テーブルで管理する。変数Ｎは、次々とそのフローのパケットが到達する度に、１ずつ減じていき、最後の到達パケットで１となるようにする。輻輳中のノードは、この変数Ｎを管理することにより、現時点での到達パケットがウィンドウサイズ分のパケット群の中で、どの位置にあって、あとどのくらいのパケットが送付されてくるかをフロー毎に知ることができる。
ここで、バッファが一杯になり、パケットを廃棄しなければならなくなったとする。本発明では、到着するパケットから廃棄するのではなく、現時点でバッファに蓄積されているパケットの中から、より変数Ｎが大きいパケットを含むフローを選択し、廃棄していく。以上により、一つのフローにつき、最大限のパケットを廃棄することができるようになる。この結果、パケット廃棄するフロー数を最小限とし、パケット廃棄しないフロー数を最大限とすることができる。
【００２１】
図３（ｂ）を用いて更に詳細に説明すると、フローＡ〜Ｄごとに所定のウィンドウサイズでパケットが到着した場合について説明する。図の右側が輻輳中のノードへのパケット到着順が先で、左側が後である。ここで廃棄パケット数が２の場合について説明する。フローとウィンドウサイズの関係は図３（ａ）と同様であるので説明を省略する。ここで、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１がウィンドウサイズの最初のパケットとすると、パケットＰ１−１、Ｐ２−１、Ｐ３−１、Ｐ４−１にはウィンドウサイズの情報が付加されており、ノードで識別することができる。その結果、フローＤのパケットＰ４−２〜Ｐ４−８までが廃棄パケットとなると、廃棄パケット数が７で、廃棄フロー数は１となり、図３と比較して、廃棄パケット数は同じであるが、廃棄フロー数を減少させることができる。
【符号の説明】
【００２２】
１ 輻輳制御装置、２ インターフェース、３ ウィンドウサイズ情報検出手段、４ フロー選択手段、５ 制御部、６ パケット廃棄手段、７ ウィンドウサイズ付加手段、８ ネットワーク、９ エッジノード、１０ 送信端、１１ 輻輳中のノード
【特許請求の範囲】
【請求項１】
ＴＣＰ同期現象を回避する輻輳制御装置であって、
ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段と、
前記先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段と、
該ウィンドウサイズ情報検出手段により検出されたウィンドウサイズ情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択するフロー選択手段と、
該フロー選択手段により選択されたフローのパケットを連続的に廃棄するパケット廃棄手段と、
前記各手段を制御する制御手段と、を備えたことを特徴とする輻輳制御装置。
【請求項２】
前記制御手段は、送信側のＴＣＰで前記ウィンドウサイズの情報を付加することができない場合、エッジノードにて前記送信側に対しては擬似ＡＣＫを返信し、受信側に対しては新たなＴＣＰを張り直すようにした上で、新たに張り直すＴＣＰにおいて先頭パケットに該ウィンドウサイズの情報を付加することを特徴とする請求項１に記載の輻輳制御装置。
【請求項３】
前記制御手段は、前記ウィンドウサイズ情報検出手段によりウィンドウサイズの情報を検出したことを認識すると、該ウィンドウサイズの情報を消去することを特徴とする請求項１又は２に記載の輻輳制御装置。
【請求項４】
ウィンドウサイズ付加手段、ウィンドウサイズ情報検出手段、フロー選択手段、パケット廃棄手段、及び制御手段を備えた輻輳制御装置の輻輳制御方法であって、
前記ウィンドウサイズ付加手段が、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するステップと、
前記ウィンドウサイズ情報検出手段が、前記先頭パケットに付加されたウィンドウサイズの情報を検出するステップと、
前記フロー選択手段が、前記ウィンドウサイズ情報検出手段により解析されたウィンドウサイズの情報の中から最大のウィンドウサイズを含むフローを選択するステップと、
前記パケット廃棄手段が、前記フロー選択手段により選択されたフローの先頭パケット以外のパケットを廃棄するステップと、
前記制御手段が、前記各手段を制御するステップと、
を備えたことを特徴とする輻輳制御装置の輻輳制御方法。
【請求項１】
ＴＣＰ同期現象を回避する輻輳制御装置であって、
ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するウィンドウサイズ付加手段と、
前記先頭パケットに付加されたウィンドウサイズの情報を検出するウィンドウサイズ情報検出手段と、
該ウィンドウサイズ情報検出手段により検出されたウィンドウサイズ情報を用いて、ウィンドウサイズ分のパケット群のうち、なるべく先頭に近いパケットを含むフローを選択するフロー選択手段と、
該フロー選択手段により選択されたフローのパケットを連続的に廃棄するパケット廃棄手段と、
前記各手段を制御する制御手段と、を備えたことを特徴とする輻輳制御装置。
【請求項２】
前記制御手段は、送信側のＴＣＰで前記ウィンドウサイズの情報を付加することができない場合、エッジノードにて前記送信側に対しては擬似ＡＣＫを返信し、受信側に対しては新たなＴＣＰを張り直すようにした上で、新たに張り直すＴＣＰにおいて先頭パケットに該ウィンドウサイズの情報を付加することを特徴とする請求項１に記載の輻輳制御装置。
【請求項３】
前記制御手段は、前記ウィンドウサイズ情報検出手段によりウィンドウサイズの情報を検出したことを認識すると、該ウィンドウサイズの情報を消去することを特徴とする請求項１又は２に記載の輻輳制御装置。
【請求項４】
ウィンドウサイズ付加手段、ウィンドウサイズ情報検出手段、フロー選択手段、パケット廃棄手段、及び制御手段を備えた輻輳制御装置の輻輳制御方法であって、
前記ウィンドウサイズ付加手段が、ウィンドウサイズ分のパケット群の中で、先頭のパケットに現時点のウィンドウサイズを情報として付加するステップと、
前記ウィンドウサイズ情報検出手段が、前記先頭パケットに付加されたウィンドウサイズの情報を検出するステップと、
前記フロー選択手段が、前記ウィンドウサイズ情報検出手段により解析されたウィンドウサイズの情報の中から最大のウィンドウサイズを含むフローを選択するステップと、
前記パケット廃棄手段が、前記フロー選択手段により選択されたフローの先頭パケット以外のパケットを廃棄するステップと、
前記制御手段が、前記各手段を制御するステップと、
を備えたことを特徴とする輻輳制御装置の輻輳制御方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１１−２２３１８６（Ｐ２０１１−２２３１８６Ａ）
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願番号】特願２０１０−８８４７６（Ｐ２０１０−８８４７６）
【出願日】平成２２年４月７日（２０１０．４．７）
【出願人】（０００２１１３０７）中国電力株式会社 (6,505)
【Ｆターム（参考）】
【公開日】平成２３年１１月４日（２０１１．１１．４）
【国際特許分類】
【出願日】平成２２年４月７日（２０１０．４．７）
【出願人】（０００２１１３０７）中国電力株式会社 (6,505)
【Ｆターム（参考）】
[ Back to top ]