(57)【特許請求の範囲】
【請求項１】
ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスにおいて、
ネットワークのローディングを監視し、前記ネットワークのローディングに基づいて確認応答パケットのプロセッシングを制御するための制御信号を生成するための確認応答制御装置と、
前記確認応答制御装置に連結されており、前記確認応答制御装置から受信した確認応答パケットを記憶するための確認応答パケットバッファと、
前記確認応答制御装置及び前記確認応答パケットバッファに連結されており、前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットをリリースするスケジューラであって、キューイング戦略に基づいて、リリースする確認応答パケットを選定するスケジューラと、
を備え、
前記キューイング戦略は、集合体確認応答パケットバッファリングが使用される場合、ヘッド・オブ・ライン確認応答パケットを送信する段階を含んでいることを特徴とする、確認応答歩調合せデバイス。
【請求項２】
ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスにおいて、
ネットワークのローディングを監視し、前記ネットワークのローディングに基づいて確認応答パケットのプロセッシングを制御するための制御信号を生成するための確認応答制御装置と、
前記確認応答制御装置に連結されており、前記確認応答制御装置から受信した確認応答パケットを記憶するための確認応答パケットバッファと、
前記確認応答制御装置及び前記確認応答パケットバッファに連結されており、前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットをリリースするスケジューラであって、キューイング戦略に基づいて、リリースする確認応答パケットを選定するスケジューラと、
を備え、
前記キューイング戦略は、クラス毎又はフロー毎確認応答パケットバッファリングが使用される場合、リリースに向けて確認応答パケットバッファ内の確認応答パケットを選択するための加重ラウンドロビン（ＷＲＲ）プロセスを含んでおり、該加重ラウンドロビン（ＷＲＲ）プロセスは、より小さい最大セグメントサイズ（ＭＳＳ）フローに対するバイアスを小さくするために、リリースに向けて、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例して、確認応答パケットの選択に重み付けするために重みを使用することを特徴とする、確認応答歩調合せデバイス。
【請求項３】
ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスにおいて、
ネットワークのローディングを監視し、前記ネットワークのローディングに基づいて確認応答パケットのプロセッシングを制御するための制御信号を生成するための確認応答制御装置と、
前記確認応答制御装置に連結されており、前記確認応答制御装置から受信した確認応答パケットを記憶するための確認応答パケットバッファと、
前記確認応答制御装置及び前記確認応答パケットバッファに連結されており、前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットをリリースするスケジューラであって、キューイング戦略に基づいて、リリースする確認応答パケットを選定するスケジューラと、
を備え、
前記キューイング戦略は、クラス毎又はフロー毎確認応答パケットバッファリングが使用される場合、リリースに向けて確認応答パケットバッファ内の確認応答パケットを選択するための公平キューイング（ＦＱ）プロセスを含んでいることを特徴とする確認応答歩調合せデバイス。
【請求項４】
前記確認応答制御装置は、確認応答パケット到着プロセッサとデータパケット出発プロセッサを使って確認応答パケットのプロセッシングを制御するための信号を生成する確認応答パケット歩調合せプロセッサを更に備えていることを特徴とする請求項１乃至３のいずれか一項に記載の確認応答歩調合せデバイス。
【請求項５】
前記確認応答パケット到着プロセッサは、ネットワークの輻輳レベルをチェックし、確認応答パケットを確認応答パケットバッファに保留すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確認応答パケットを直接ソースに送るべきかを決めることにより、確認応答パケットバッファに対する確認応答パケットのプロセッシングを制御することを特徴とする請求項４に記載の確認応答歩調合せデバイス。
【請求項６】
前記確認応答パケット到着プロセッサは、ネットワークが輻輳しているかどうかを判定し、確認応答パケットバッファが空であるかどうかを判定し、ネットワークが輻輳しているか、又は確認応答パケットバッファが空でなければ、確認応答パケットをバッファに記憶し、確認応答パケットバッファが空でありネットワークが輻輳していなければ、確認応答パケットをソースに送ることにより、確認応答パケットを確認応答パケットバッファに保留すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確認応答パケットを直接ソースに送るべきかを決めることを特徴とする請求項４に記載の確認応答歩調合せデバイス。
【請求項７】
前記確認応答パケットは、確認応答パケットが輻輳中に確認応答パケットバッファ内にバッファされるべき１番目のパケットである場合には、確認応答パケットバッファに記憶され、前記スケジューラによりゲートアウトされることを特徴とする請求項６に記載の確認応答歩調合せデバイス。
【請求項８】
前記確認応答制御装置は、確認応答パケットが輻輳中に確認応答パケットバッファ内にバッファされるべき１番目の確認応答パケットである場合には、確認応答パケットバッファからゲートされる確認応答パケット相互間のスペーシングを増加させることを特徴とする請求項７に記載の確認応答歩調合せデバイス。
【請求項９】
前記確認応答制御装置は、パケットカウンタ変数を第１の所定値にセットすることにより、確認応答パケット相互間のスペーシングを増加させることを特徴とする請求項８に記載の確認応答歩調合せデバイス。
【請求項１０】
前記パケットカウンタ変数は、データパケットがネットワークを出発する際に減分されることを特徴とする請求項９に記載の確認応答歩調合せデバイス。
【請求項１１】
前記スケジューラは、パケットカウンタ変数が減分されてゼロになったらバッファされている確認応答パケットをリリースし、そうすると確認応答制御装置がパケットカウンタ変数をリセットすることを特徴とする請求項１０に記載の確認応答歩調合せデバイス。
【請求項１２】
ネットワークの前記輻輳レベルは、データパケットバッファの容量を表すキュー長を分析することにより求められることを特徴とする請求項５に記載の確認応答歩調合せデバイス。
【請求項１３】
前記ネットワークは、前記キュー長が低い閾値よりも小さい場合には輻輳していないとして表示されることを特徴とする請求項１２に記載の確認応答歩調合せデバイス。
【請求項１４】
前記ネットワークは、前記キュー長が高い閾値よりも大きい場合には輻輳しているとして表示されることを特徴とする請求項１２に記載の確認応答歩調合せデバイス。
【請求項１５】
前記データパケット出発プロセッサは、ネットワークの輻輳レベルを監視し、確認応答パケットを確認応答パケットバッファからソースへ何時ゲートさせるかを決めることにより、確認応答パケットバッファからの確認応答パケットのリリースを制御することを特徴とする請求項４に記載の確認応答歩調合せデバイス。
【請求項１６】
前記データパケット出発プロセッサは、確認応答パケットが送信を待ちながら確認応答パケットバッファ内に在るか否か、並びに確認応答制御装置によりセットされたパケットカウンタ変数がゼロの値を有しているか否かをチェックし、パケットカウンタ変数がゼロの値を有しているときに確認応答パケットバッファ内のバッファされた確認応答パケットをソースにリリースすることにより、確認応答パケットを確認応答パケットバッファからソースへ何時ゲートさせるかを決めることを特徴とする請求項１５に記載の確認応答歩調合せデバイス。
【請求項１７】
前記データパケット出発プロセッサは、ネットワーク内に依然として輻輳が存在している場合、確認応答パケットバッファからの確認応答パケットのリリースの間のスペーシングを増やすことを特徴とする請求項１６に記載の確認応答歩調合せデバイス。
【請求項１８】
確認応答パケットのリリースの間の前記スペーシングは、パケットカウンタ変数を第１の所定値にリセットすることにより増やされることを特徴とする請求項１７に記載の確認応答歩調合せデバイス。
【請求項１９】
前記データパケット出発プロセッサは、パケットカウンタ変数がゼロでない場合、パケットカウンタ変数を減分することを特徴とする請求項１８に記載の確認応答歩調合せデバイス。
【請求項２０】
前記データパケット出発プロセッサは、パケットカウンタ変数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方を防止するために、パケットカウンタ変数を第２の所定値にリセットすることを特徴とする請求項１９に記載の確認応答歩調合せデバイス。
【請求項２１】
前記データパケット出発プロセッサは、ネットワーク内の輻輳が収まっている場合、確認応答パケットバッファからの確認応答パケットのリリースの間のスペーシングを減少させることを特徴とする請求項１６に記載の確認応答歩調合せデバイス。
【請求項２２】
前記データパケット出発プロセッサは、パケットカウンタ変数を第１の所定値よりも小さい第２の所定値にリセットすることにより、確認応答パケットのリリースの間のスペーシングを減少させることを特徴とする請求項２１に記載の確認応答歩調合せデバイス。
【請求項２３】
前記データパケット出発プロセッサは、パケットカウンタ変数の値がゼロでない場合、パケットカウンタ変数を減分することを特徴とする請求項２２に記載の確認応答歩調合せデバイス。
【請求項２４】
前記データパケット出発プロセッサは、パケットカウンタ変数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方を防止するために、パケットカウンタ変数を第２の所定値にリセットすることを特徴とする請求項２３に記載の確認応答歩調合せデバイス。
【請求項２５】
ネットワークの前記輻輳レベルは、データパケットバッファの容量を表すキュー長を分析することにより求められることを特徴とする請求項１６に記載の確認応答歩調合せデバイス。
【請求項２６】
前記ネットワークは、前記キュー長が低い閾値よりも小さい場合には輻輳していないとして表示されることを特徴とする請求項２５に記載の確認応答歩調合せデバイス。
【請求項２７】
前記ネットワークは、前記キュー長が高い閾値よりも大きい場合には輻輳しているとして表示されることを特徴とする請求項２５に記載の確認応答歩調合せデバイス。
【請求項２８】
前記確認応答パケットバッファは、確認応答パケットを集合体ベースでバッファすることを特徴とする請求項１に記載の確認応答歩調合せデバイス。
【請求項２９】
前記確認応答パケットバッファは、フロータイプにより確認応答パケットをバッファし、前記スケジューラは、バッファされた確認応答パケットに関するフローのタイプを考慮に入れて確認応答バッファ内の確認応答パケットをリリースすることを特徴とする請求項２又は３に記載の確認応答歩調合せデバイス。
【請求項３０】
アクセスノード・デバイスにおいて、
データパケットをソースから受信し、そのデータパケットを順方向データリンクに送るためのリンク層エンティティであって、データパケットがリンク層エンティティを出発して順方向のデータリンクへと送られるまで受信されたデータパケットをデータパケットバッファに記憶するリンク層エンティティと、
前記リンク層エンティティに連結されている、ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスと
を備えており、前記確認応答歩調合せデバイスが、
前記リンク層エンティティの輻輳を監視し、前記リンク層エンティティに輻輳が起きているか否かに基づいて確認応答パケットのプロセッシングを制御するための信号を生成するための確認応答制御装置と、
前記確認応答制御装置に連結されている、前記確認応答制御装置から受信した確認応答パケットを記憶するための確認応答パケットバッファと、
前記確認応答制御装置及び前記確認応答パケットバッファに連結されている、前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットを前記ソースへとリリースするスケジューラであって、キューイング戦略に基づいてリリースする確認応答パケットを選定するスケジューラと
を更に備えており、
前記キューイング戦略は、集合体確認応答パケットバッファリングが使用される場合、ヘッド・オブ・ライン確認応答パケットを送信する段階を含んでいることを特徴とする、アクセスノード・デバイス。
【請求項３１】
アクセスノード・デバイスにおいて、
データパケットをソースから受信し、そのデータパケットを順方向データリンクに送るためのリンク層エンティティであって、データパケットがリンク層エンティティを出発して順方向のデータリンクへと送られるまで受信されたデータパケットをデータパケットバッファに記憶するリンク層エンティティと、
前記リンク層エンティティに連結されている、ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスと
を備えており、前記確認応答歩調合せデバイスが、
前記リンク層エンティティの輻輳を監視し、前記リンク層エンティティに輻輳が起きているか否かに基づいて確認応答パケットのプロセッシングを制御するための信号を生成するための確認応答制御装置と、
前記確認応答制御装置に連結されている、前記確認応答制御装置から受信した確認応答パケットを記憶するための確認応答パケットバッファと、
前記確認応答制御装置及び前記確認応答パケットバッファに連結されている、前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットを前記ソースへとリリースするスケジューラであって、キューイング戦略に基づいてリリースする確認応答パケットを選定するスケジューラと
を更に備えており、
前記キューイング戦略は、クラス毎又はフロー毎確認応答パケットバッファリングが使用される場合、リリースに向けて確認応答パケットバッファ内の確認応答パケットを選択するための加重ラウンドロビン（ＷＲＲ）プロセスを含んでおり、該加重ラウンドロビン（ＷＲＲ）プロセスは、より小さい最大セグメントサイズ（ＭＳＳ）フローに対するバイアスを小さくするため、リリースに向けて、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例して、確認応答パケットの選択に重み付けするために重みを使用することを特徴とするアクセスノード・デバイス。
【請求項３２】
アクセスノード・デバイスにおいて、
データパケットをソースから受信し、そのデータパケットを順方向データリンクに送るためのリンク層エンティティであって、データパケットがリンク層エンティティを出発して順方向のデータリンクへと送られるまで受信されたデータパケットをデータパケットバッファに記憶するリンク層エンティティと、
前記リンク層エンティティに連結されている、ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスと
を備えており、前記確認応答歩調合せデバイスが、
前記リンク層エンティティの輻輳を監視し、前記リンク層エンティティに輻輳が起きているか否かに基づいて確認応答パケットのプロセッシングを制御するための信号を生成するための確認応答制御装置と、
前記確認応答制御装置に連結されている、前記確認応答制御装置から受信した確認応答パケットを記憶するための確認応答パケットバッファと、
前記確認応答制御装置及び前記確認応答パケットバッファに連結されている、前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットを前記ソースへとリリースするスケジューラであって、キューイング戦略に基づいて、リリースする確認応答パケットを選定するスケジューラと
を更に備えており、
前記キューイング戦略は、クラス毎又はフロー毎確認応答パケットバッファリングが使用される場合、リリースに向けて確認応答パケットバッファ内の確認応答パケットを選択するための公平キューイング（ＦＱ）プロセスを含んでいることを特徴とするアクセスノード・デバイス。
【請求項３３】
前記確認応答制御装置は、確認応答パケット到着プロセッサとデータパケット出発プロセッサとを使って、確認応答パケットのプロセッシングを制御するための制御信号を生成する確認応答パケット歩調合せプロセッサを更に備えていることを特徴とする請求項３０乃至３２のいずれか一項に記載のアクセスノード・デバイス。
【請求項３４】
前記確認応答パケット到着プロセッサは、リンク層エンティティの輻輳をチェックし、確認応答パケットを確認応答パケットバッファに保留すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確認応答パケットを直接ソースに送るべきかを決めることにより、確認応答パケットバッファに対する確認応答パケットのプロセッシングを制御することを特徴とする請求項３３に記載のアクセスノード・デバイス。
【請求項３５】
前記確認応答パケット到着プロセッサが、リンク層エンティティが輻輳しているかどうかを判定し、確認応答パケットバッファが空であるかどうかを判定し、リンク層エンティティが輻輳しているか、又は確認応答パケットバッファが空でない場合には、確認応答パケットをバッファに記憶し、確認応答パケットバッファが空であり、リンク層エンティティが輻輳していない場合には、確認応答パケットをソースに送ることにより、確認応答パケットを確認応答パケットバッファ内に保留すべきか、又は確認応答パケットを確認応答パケットバッファ内にバッファせずに確認応答パケットを直接ソースに送るべきかを決めることを特徴とする請求項３３に記載のアクセスノード・デバイス。
【請求項３６】
前記確認応答パケットは、確認応答パケットが輻輳中に確認応答パケットバッファ内にバッファされるべき１番目の確認応答パケットである場合には、確認応答パケットバッファに記憶され、スケジューラによりゲートアウトされることを特徴とする請求項３５に記載のアクセスノード・デバイス。
【請求項３７】
前記確認応答制御装置は、確認応答パケットが輻輳中に確認応答パケットバッファ内にバッファされるべき１番目の確認応答パケットである場合には、確認応答パケットバッファからゲートされる確認応答パケット相互間のスペーシングを増やすことを特徴とする請求項３６に記載のアクセスノード・デバイス。
【請求項３８】
前記データパケット出発プロセッサは、リンク層エンティティの輻輳が収まっている場合、確認応答パケットバッファからの確認応答パケットのリリースの間のスペーシングを減少させることを特徴とする請求項３３に記載のアクセスノード・デバイス。
【請求項３９】
ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットのための確認応答歩調合せを提供するための方法において、
ネットワークのローディングを監視する段階と、
ネットワークのローディングに基づいて確認応答パケットのプロセッシングを制御するための制御信号を生成する段階と、
確認応答制御装置から受信した確認応答パケットを確認応答パケットバッファに記憶する段階と、
制御信号に基づいて確認応答パケットをリリースする段階であって、キューイング戦略に基づいてリリースするために確認応答パケットを選定する段階を更に含む段階と、
から成り、
前記キューイング戦略は、集合体確認応答パケットバッファリングが使用される場合、ヘッド・オブ・ライン確認応答パケットを送信する段階を含んでいる、
ことを特徴とする方法。
【請求項４０】
ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットのための確認応答歩調合せを提供するための方法において、
ネットワークのローディングを監視する段階と、
ネットワークのローディングに基づいて確認応答パケットのプロセッシングを制御するための制御信号を生成する段階と、
確認応答制御装置から受信した確認応答パケットを確認応答パケットバッファに記憶する段階と、
制御信号に基づいて確認応答パケットをリリースする段階であって、キューイング戦略に基づいてリリースするために確認応答パケットを選定する段階を更に含む段階と、
から成り、 前記キューイング戦略は、クラス毎又はフロー毎確認応答パケットバッファリングが使用される場合、リリースに向けて確認応答パケットバッファ内の確認応答パケットを選択するための加重ラウンドロビン（ＷＲＲ）プロセスを含んでおり、該加重ラウンドロビン（ＷＲＲ）プロセスは、より小さい最大セグメントサイズ（ＭＳＳ）フローに対するバイアスを小さくするため、リリースに向けて、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例して、確認応答パケットの選択に重み付けするために重みを使用する、
ことを特徴とする方法。
【請求項４１】
ソースからのデータパケットの受信に応えてソースに送信されるべき確認応答パケットのための確認応答歩調合せを提供するための方法において、
ネットワークのローディングを監視する段階と、
ネットワークのローディングに基づいて確認応答パケットのプロセッシングを制御するための制御信号を生成する段階と、
確認応答制御装置から受信した確認応答パケットを確認応答パケットバッファに記憶する段階と、
制御信号に基づいて確認応答パケットをリリースする段階であって、キューイング戦略に基づいてリリースするために確認応答パケットを選定する段階を更に含む段階と、
から成り、
前記キューイング戦略は、クラス毎又はフロー毎確認応答パケットバッファリングが使用される場合、リリースに向けて確認応答パケットバッファ内の確認応答パケットを選択するための公平キューイング（ＦＱ）プロセスを含んでいる、
ことを特徴とする方法。
【請求項４２】
前記確認応答パケットのプロセッシングを制御するための制御信号を生成する段階は、確認応答パケット到着プロセスとデータパケット出発プロセスを含んでいることを特徴とする請求項３９乃至４１のいずれか一項に記載の方法。
【請求項４３】
前記確認応答パケット到着プロセスは、ネットワークの輻輳レベルをチェックし、確認応答パケットを確認応答パケットバッファに保留すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確認応答パケットを直接ソースに送るべきかを決めることにより、確認応答パケットバッファに対する確認応答パケットのプロセッシングを制御することを特徴とする請求項４２に記載の方法。
【請求項４４】
前記確認応答パケットを確認応答パケットバッファに保留すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確認応答パケットを直接ソースに送るべきかを決める段階は、ネットワークが輻輳しているかどうかを判定する段階と、確認応答パケットバッファが空であるかどうかを判定する段階と、ネットワークが輻輳しているか、又は確認応答パケットバッファが空でない場合、確認応答パケットをバッファに記憶する段階と、確認応答パケットバッファが空であり、ネットワークが輻輳していない場合、確認応答パケットをソースに送る段階と、を更に含んでいることを特徴とする請求項４２に記載の方法。
【請求項４５】
前記確認応答パケットは、確認応答パケットが確認応答パケットバッファ内にバッファされるべき１番目のパケットである場合には、確認応答パケットバッファ内に記憶され、ゲートアウトされることを特徴とする請求項４４に記載の方法。
【請求項４６】
確認応答パケットが確認応答パケットバッファ内にバッファされるべき１番目のパケットである場合には、確認応答パケットバッファからゲートされる確認応答パケット相互間のスペーシングを増加させる段階を更に含んでいることを特徴とする請求項４５に記載の方法。
【請求項４７】
前記スペーシングを増加させる段階は、パケットカウンタ変数を第１の所定値にセットする段階を更に含んでいることを特徴とする請求項４６に記載の方法。
【請求項４８】
データパケットがネットワークを出発する際にパケットカウンタ変数を減分する段階を更に含んでいることを特徴とする請求項４７に記載の方法。
【請求項４９】
前記パケットカウンタ変数が減分されてゼロになると、バッファされている確認応答パケットをリリースする段階と、前記パケットカウンタ変数をリセットする段階とを更に含んでいることを特徴とする請求項４８に記載の方法。
【請求項５０】
ネットワークの前記輻輳レベルは、データパケットバッファの容量を表すキュー長を分析することにより求められることを特徴とする請求項４３に記載の方法。
【請求項５１】
前記キュー長が低い閾値よりも小さいときには、前記ネットワークが輻輳していないと表示する段階を更に含んでいることを特徴とする請求項５０に記載の方法。
【請求項５２】
前記キュー長が高い閾値よりも大きいときには、前記ネットワークが輻輳していると表示する段階を更に含んでいることを特徴とする請求項５０に記載の方法。
【請求項５３】
前記リリースする段階は、ネットワークの輻輳レベルを監視する段階と、確認応答パケットを確認応答パケットバッファからソースへ何時ゲートさせるかを決定する段階を更に含んでいることを特徴とする請求項４２に記載の方法。
【請求項５４】
前記決定する段階は、確認応答パケットが送信を待ちながら確認応答パケットバッファ内に在るか否か、並びに確認応答制御装置によりセットされたパケットカウンタ変数がゼロの値を有しているか否かをチェックする段階と、パケットカウンタ変数がゼロの値を有している場合、確認応答パケットバッファ内のバッファされた確認応答パケットをソースにリリースする段階とを更に含んでいることを特徴とする請求項５３に記載の方法。
【請求項５５】
前記データパケット出発プロセスは、ネットワーク内に依然として輻輳が存在している場合、確認応答パケットバッファからの確認応答パケットのリリースの間のスペーシングを増加する段階を更に含んでいることを特徴とする請求項５４に記載の方法。
【請求項５６】
前記増加する段階は、パケットカウンタ変数を第１の所定値にリセットする段階を更に含んでいることを特徴とする請求項５５に記載の方法。
【請求項５７】
前記データパケット出発プロセスは、パケットカウンタ変数がゼロでない場合、パケットカウンタ変数を減分する段階を更に含んでいることを特徴とする請求項５６に記載の方法。
【請求項５８】
前記データパケット出発プロセスは、パケットカウンタ変数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方を防止するために、パケットカウンタ変数を第２の所定値にリセットする段階を更に含んでいることを特徴とする請求項５７に記載の方法。
【請求項５９】
前記データパケット出発プロセスは、ネットワーク内の輻輳が収まっている場合、確認応答パケットバッファからの確認応答パケットのリリースの間のスペーシングを減少させる段階を更に含んでいることを特徴とする請求項５４に記載の方法。
【請求項６０】
前記データパケット出発プロセスは、パケットカウンタ変数を第１の所定値よりも小さい第２の所定値にリセットすることにより、確認応答パケットのリリースの間のスペーシングを減少させる段階を更に含んでいることを特徴とする請求項５９に記載の方法。
【請求項６１】
前記データパケット出発プロセスは、パケットカウンタ変数の値がゼロでない場合、パケットカウンタ変数を減分する段階を更に含んでいることを特徴とする請求項６０に記載の方法。
【請求項６２】
前記データパケット出発プロセスは、パケットカウンタ変数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方を防止するために、パケットカウンタ変数を第２の所定値にリセットする段階を更に含んでいることを特徴とする請求項６１に記載の方法。
【請求項６３】
前記ネットワークの輻輳レベルを判定する段階は、データパケットバッファに関する容量を表すキュー長を分析する段階を更に含んでいることを特徴とする請求項５４に記載の方法。
【請求項６４】
前記キュー長が低い閾値よりも小さい場合には、ネットワークが輻輳していないと表示する段階を更に含んでいることを特徴とする請求項６３に記載の方法。
【請求項６５】
前記キュー長が高い閾値よりも大きい場合には、ネットワークが輻輳していると表示する段階を更に含んでいることを特徴とする請求項６３に記載の方法。
【請求項６６】
前記記憶する段階は、確認応答パケットを集合体ベースでバッファする段階を更に含んでいることを特徴とする請求項３９に記載の方法。
【請求項６７】
前記記憶する段階は、フロータイプにより確認応答パケットをバッファする段階を更に含んでおり、前記リリースする段階は、バッファされた確認応答パケットに関するフローのタイプを考慮することにより、確認応答バッファ内の確認応答パケットのリリースをスケジュールする段階を更に含んでいることを特徴とする請求項４０又は４１に記載の方法。
【発明の詳細な説明】
【０００１】
（発明の技術的分野）
本発明は、概括的にはネットワークに、より厳密にはＴＣＰ接続のためのエンハンスド確認応答歩調合せデバイス及び方法に関する。
【０００２】
（発明の背景）
今日、管理機関のコンピュータネットワークは、循環システムになってきている。管理機関は、デスクトップ・ワークステーション、サーバ、及びホストを、ローカルエリアネットワーク（ＬＡＮ）集団へと合体させてきた。これらのローカルエリアネットワークは、他のローカルエリアネットワーク及びワイドエリアネットワーク（ＷＡＮ）に接続されている。日々のオペレーションにおいて、ネットワークのどこに位置しているかに関係なく、対になったシステムが必要なときに必ず通信できるようになっていることが必要となってきた。
【０００３】
ネットワークコンピューティングの初期の頃には、所有者のネットワークプロトコルが標準であった。しかしながら、国際標準化機構（ＩＳＯ）により導入されたオープンシステム相互接続基準モデルは見事なまでに網間接続の度合いを高めたので、エンドユーザーのアプリケーションがネットワークのシステム間で概ね非常に良好に作動することができるようになっている。インプリメンテーションは、多数のコンピュータベンダー、ハードウェアコンポーネントベンダー、及び独立したソフトウェア会社からのボランティアにより手にはいるようになった書面標準に基づいている。
【０００４】
ここ１０年の間にＬＡＮは激増した。これにより、どのように輻輳を最小限にし処理能力を最適化するかという問題が再浮上し、ネットワーク管理者はこの問題を解決せねばならなくなっている。初期の解決策は、ローカルエリアネットワークを、より少ない母集団を担う多数の小規模ネットワークに単純に分割するというものであった。各セグメントはブリッジにより接続され、トラフィックが各セグメントに対して局所的に差別して扱われるようになっている、単一のローカルエリアネットワークを形成していた。
【０００５】
新しいネットワークタイプの展開とワイドエリアネットワークは、ルータの必要性を生み出した。例えば、インターネットはゲートウェイにより接続されたネットワークのセットであるが、これは時にはルータと称されることもある。ルータは、同報通信ドメイン上でより多くの制御を提供し、同報通信トラフィックを制限し、そしてセキュリティを強化するために、フィルタリングとファイアウォールの能力を追加した。ルータは埋め込み型知能によりネットワークを通る最良の経路を選定することができる。追加されたこの知能により、ルータは可能な場合、目的地までの冗長経路を構築することもできる。それでもやはり、埋め込み型知能により与えられた最良経路の選定能力には複雑性が加わるので、ルータのポート費用が増し、実質的には待ち時間というオーバーヘッドが生じた。分散したクライアント／サーバ・データトラフィック、拡大したユーザー母集団、及びより複雑なアプリケーションを備えた共有媒体ネットワークが、新しい帯域幅ボトルネックを生み出した。このような輻輳により、ネットワーク応答時間は予測不可能となり、遅れに敏感なアプリケーションをサポートできなくなり、ネットワークの故障頻度が上がった。
【０００６】
現在のネットワークにおける輻輳制御は、益々重要な問題になりつつある。ワールドワイドウェブ（ＷＷＷ）のようなインターネットアプリケーションの爆発的な成長は現在の技術をその限界へと追いやっており、転送を迅速に行い、輻輳を改善する制御機構の必要性が表面化している。その結果、多数の機器ベンダーとサービスプロバイダは、関連する複雑な通信サービス品質（ＱＯＳ）管理問題に対して適切な解決策を提供しようとアドバンスド・ネットワーキング技術に走っている。例としては非同期転送モード（ＡＴＭ）ネットワークがあり、ＩＰネットワークサービスも新たに出てきている。それにもかかわらず、これらのより新しい対応策内で、現存する遺産のＩＰプロトコルのホストをサポートすることがなお必要とされている。厳密には、至る所に存在するＴＣＰトランスポート層プロトコルは、ＩＰネットワーク内では長きにわたり使われてきており、ウェブブラウザ、ファイル／ｅメール転送サービス等により広く使われてきた。
【０００７】
伝送制御プロトコル（ＴＣＰ）は、ＴＣＰ／ＩＰプロトコルファミリーの一部であり、インターネットの成功と共に、世界的に最も重要なデータ通信プロトコルの１つとしてのその地位を得ている。ＴＣＰはＴＣＰ／ＩＰプロトコルを使用しているデバイス間に信頼できるデータ通信を提供する。ＴＣＰは、データをデータグラムと呼ばれるデータパケットにパッキングするため、及びネットワークを横断して伝送するために使用されるＩＰの上位で動作する。
【０００８】
インターネットプロトコル（ＩＰ）は、ネットワークを横断してデータをルート付けるネットワーク層プロトコルである。インターネットプロトコルは、異なるベンダーにより構築されたホストとルーターの使用に適応し、成長するネットワーク型式の成長の多様性を範囲に入れ、サービスに干渉することなくネットワークを成長させ、セッション及びメッセージ指向型サービスの上位層をサポートするように設計された。ＩＰネットワーク層は、ローカルエリアネットワークの「島」を統合できるようにしている。
【０００９】
しかしながら、ＩＰはフロー制御も再伝送機構も含んでいない。これが、ＴＣＰがＩＰの上位で使用される理由である。特に、ＴＣＰは失われたデータパケットを検知するため、確認応答を使用する。ＴＣＰ／ＩＰネットワークは、おそらく今日では全ネットワークの中で最も重要であり、上記のＡＴＭ等幾つかの（物理的）ネットワークの上位で動作する。これら下層のネットワークは、ネットワークとトラフィックの状態についてある情報を提供するが、それは輻輳に関するフィードバックを提供するために使用されることになる。
【００１０】
輻輳を管理するに当たり、ＴＣＰは、送信者のウインドウサイズを調節するために反応性輻輳制御に連結されたスライディングウインドウ機構を使用する。このプロトコルは、遠隔の受信者端末から送られてきた返送確認応答（ＡＣＫ）パケット次第でその伝送行為を調整する。
【００１１】
しかしながら、ＴＣＰの問題は、輻輳制御機構が比較的低速なことである。ほとんどのＴＣＰインプリメンテーションは、タイムアウトを測定するのに非常に粗いタイマーを使用しており、即ち２００−５００ｍｓの細分性である。更に、ほとんどのＴＣＰインプリメンテーションは、輻輳を検知するのに、ＡＣＫディレイ又はパケット・ドロップに依存している。その結果、ソースウインドウが過剰に縮小されると、ＴＣＰソースが強制的に自身の伝送ウインドウを再始動させられるので、大量の帯域幅が浪費されることになる。更に、多くの研究により、ＴＣＰはＡＴＭネットワーク上では、特により大型のＷＡＮタイプの伝播ディレイについては、あまり良好に作動しないことが分かっている。
【００１２】
ＴＣＰに関する上記欠点に立ち向かうためには、ＴＣＰフィードバックループに、より迅速な輻輳表示機構をどうにかして組み入れることにより、ネットワーク輻輳の機会を最小限にすることが必要である。しかしながら、現在のバージョンとの互換性を保証し、そして市場の受け入れを促進するために、このような試みは、実際のＴＣＰプロトコル又はそのインプリメンテーションに対する変更を避けねばならない。
【００１３】
これらの方針に沿って、様々なＡＣＫ歩調合せスキームが提示されてきた。これらＡＣＫ歩調合せスキームは、基本的には、輻輳の期間中にソース放出を制限するために、ＴＣＰ  ＡＣＫパケットのスペーシングを調整する。ＡＣＫ歩調合せは、ＡＴＭ、ギガバイトＩＰ（即ち光ＷＤＭ）のような高速（サブ）ネットワーク又はサテライトの境界にうまく適合している。本質的には、この技術はアクセスノードのＴＣＰトラフィック適合化を行なう。このような技法は、アドバンスドＡＴＭデータサービス、即ち下層のＡＢＲフロー制御又は接続毎のキューイングにとって特に有益である、というのも輻輳はＡＴＭの周辺部、即ちアクセスノードに生まれる傾向があるからである。ある輻輳距離により示されるように順方向リンクが混み合っていれば、ＡＣＫパケットは適当に遅れてソースに送信される。
【００１４】
他の著者は、性能を改善するために、ＡＣＫパケット自体のフィールド、即ち受信者ウインドウサイズを修正することを提案している。しかしながら、このようなスキームは、正確な往復移動遅れの測定を必要条件とするか、さもなければタイトなバッファ制御を保守することができなくなるかの何れかである。更に、ＡＣＫパケットフィールドの書き直しは、再計算を必要とし合計費用が高くつくことになる。
【００１５】
ＡＣＫ歩調合せはＴＣＰソースの挙動を制御する効果的な方法ではあっても、提案されたスキームの多くは複雑すぎるか、及び／又はネットワークパラメータ設定に対し過敏であるかの何れかである。研究によってＴＣＰの処理能力と公平性レベルは多くの高速ネットワークシナリオでは低くなることが示されているので、その性能を強化するために効率がよく実用的なスキームを考案することが必要である。プロトコルの機能そのものを改正することもオプションであるが、短期から中期のタイムフレームにおいては実現可能な代替案とは言いかねる。この方針によれば、ＡＣＫ歩調合せ方法は意義深い利益を与えることができる。
【００１６】
ＡＣＫ歩調合せのためのより強固で包括的なスキームが必要とされている。
【００１７】
高い処理能力と精密なレベルの帯域幅公平性を提供するＡＣＫ歩調合せも必要とされている。
【００１８】
更に、ＴＣＰバッファリング遅れを大幅に低減し、広範なネットワークシナリオに適応可能なＡＣＫ歩調合せへの必要性も表面化している。
【００１９】
又更に、ＴＣＰプロトコルを修正することなく、より迅速な輻輳表示を提供するＡＣＫ歩調合せへの必要性も表面化している。
【００２０】
（発明の概要）
上記先行技術における限界を克服するため、そして本明細書を読み、理解する際に明らかになるであろう他の限界を克服するために、本発明はＴＣＰ接続のためのエンハンスド確認応答歩調合せデバイス及び方法を開示する。
【００２１】
本発明は、ＡＣＫ歩調合せのためのより強靭で包括的なスキームを提供することにより上記問題を解決する。本発明によるＡＣＫ歩調合せは、高い処理能力と精密なレベルの帯域幅公平性を提供する。更に、ＡＣＫ歩調合せは、ＴＣＰバッファリング遅れを大幅に低減し、広範なネットワークシナリオに適用することができる。こうして、本ＡＣＫ歩調合せは、ＴＣＰプロトコルを修正することなくより迅速な輻輳表示を提供する。
【００２２】
本発明の原理によるシステムは、ソースからデータパケットを受信しデータパケットを順方向データリンクへ送るためのリンク層エンティティであって、受信したデータパケットを、データパケットがリンク層エンティティを離れて順方向データリンクへと送られるまでデータパケットバッファに記憶するリンク層エンティティと、リンク層エンティティに連結されていて、ソースからのデータパケットの受信に応えてソースに送られるＡＣＫパケットを歩調合せするための確認応答歩調合せデバイスとを含んでいる。確認応答歩調合せデバイスは、リンク層エンティティの輻輳を監視し、リンク層エンティティに輻輳が起きているかどうかに基づいて確認応答パケットのプロセシングを制御するための制御信号を生成するための確認応答制御装置と、確認応答制御装置に連結されている、確認応答制御装置から受信された確認応答パケットを記憶するための確認応答パケットバッファと、確認応答制御装置と確認応答バッファに連結されている、確認応答制御装置により生成された制御信号に基づいてソースに確認応答パケットをリリースするスケジューラを更に含んでいる。
【００２３】
本発明の原理による他のシステムの実施例は、代わりの又は随意的な他の態様を含んでいる。本発明のこのような態様の１つは、キューイング戦略に基づいてスケジューラがＡＣＫパケットを選定してリリースすることである。
【００２４】
本発明の別の態様は、キューイング戦略が、集合体ＡＣＫパケットバッファリングが使用される場合には、ヘッド・オブ・ラインＡＣＫパケットを送信する段階を含んでいることである。
【００２５】
本発明の別の態様は、キューイング戦略が、クラス毎又はフロー毎ＡＣＫパケットバッファリングが使用されている場合には、リリースに向けてＡＣＫパケットバッファ中のＡＣＫパケットを選択するための加重ラウンドロビン（ＷＲＲ）プロセスを含んでいることである。
【００２６】
本発明の別の態様は、加重ラウンドロビン（ＷＲＲ）が、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例してリリースするために、ＡＣＫパケットの選択に加重するための重みを使用して、より小さなＭＳＳフローに対する偏りを少なくすることである。
【００２７】
本発明の別の態様は、キューイング戦略が、クラス毎又はフロー毎ＡＣＫパケットバッファリングが使用される場合には、リリースに際しＡＣＫパケットバッファ内のあるＡＣＫパケットを選択するための公平なキューイング（ＦＱ）プロセスを含んでいることである。
【００２８】
本発明の別の態様は、確認応答制御装置が、ＡＣＫパケット到着プロセッサとデータパケット出発プロセッサを使って確認応答パケットのプロセッシングを制御するための制御信号を生成するＡＣＫパケット歩調合せプロセッサを更に含んでいることである。
【００２９】
本発明の別の態様は、ＡＣＫパケット到着プロセッサが、リンク層エンティティの輻輳をチェックし、ＡＣＫパケットをＡＣＫパケットバッファに保留するか又はＡＣＫパケットをＡＣＫパケットバッファにバッファせずにＡＣＫパケットを直接ソースに送るべきかを決定することにより、ＡＣＫパケットバッファに対するＡＣＫパケットのプロセッシングを制御することである。
【００３０】
本発明の別の態様は、ＡＣＫパケット到着プロセッサが、リンク層エンティティが混み合っているかどうかを判定し、ＡＣＫパケットバッファが空であるかどうかを判定し、リンク層エンティティが混み合っているか又はＡＣＫパケットバッファが空である場合はＡＣＫパケットをバッファに記憶し、ＡＣＫパケットバッファが空でありリンク層エンティティが混み合っていない場合はＡＣＫパケットを送ることにより、ＡＣＫパケットをＡＣＫパケットバッファに保留するか又はＡＣＫパケットをＡＣＫパケットバッファにバッファせずにＡＣＫパケットを直接ソースに送るべきかを決定することである。
【００３１】
本発明の別の態様は、ＡＣＫパケットは、そのＡＣＫパケットが輻輳中にＡＣＫパケットバッファにバッファされるべき第１のＡＣＫパケットである場合は、スケジューラによりＡＣＫパケットバッファに記憶され、ゲートアウトされることである。
【００３２】
本発明の別の態様は、そのＡＣＫパケットが輻輳中にＡＣＫパケットバッファにバッファされるべき第１のＡＣＫパケットである場合は、ＡＣＫ制御装置がＡＣＫパケットバッファからゲートされたＡＣＫパケット相互間のスペーシングを大きくすることである。
【００３３】
本発明の別の態様は、リンク層エンティティの輻輳がおさまった場合は、データパケット出発プロセッサが、ＡＣＫパケットバッファからのＡＣＫパケットのリリースの間隔を小さくすることである。
【００３４】
以上及び他の様々な利点、並びに本発明を特徴付ける新規な特性は、本願に附随しその一部を成す請求項目により厳密に指摘される。しかしながら、本発明、その利点、及びその使用により得られる目的をより深く理解するためには、本願の別の一部を成す図面並びに附随の説明事項を参照すべきであり、そこには本発明による装置の具体例を図示し説明している。
【００３５】
(好適な実施例の詳細な説明)
これより図面を参照するが、全体を通して類似符号は対応している部分を表すものである。
【００３６】
代表的実施例を以下に記述する中で、本願の一部を成す附随図面を参照することになるが、当図面は本発明が具現化されている特定の実施例の説明に役立つように示すものである。本発明の範囲を逸脱することなく、構造的変更を加えた他の実施例も使用できるものと理解して頂きたい。
【００３７】
本発明は、ＴＣＰ接続のためのエンハンスド確認応答歩調合せデバイスを提供する。高い処理能力と精密なレベルの帯域幅公平性を可能にするＡＣＫ歩調合せのためのより強靭で包括的なスキームが提供される。更に、ＡＣＫ歩調合せは、ＴＣＰバッファリング遅れを大幅に低減し、広範なネットワークシナリオに適用することができる。こうして、本発明によるＡＣＫ歩調合せは、ＴＣＰプロトコルを修正することなく、より迅速な輻輳表示を提供する。
【００３８】
図１は、アプリケーション層１１０、プレゼンテーション層１２０、セッション層１３０、トランスポート層１４０、ネットワーク層１５０、データリンク層１６０、物理層１７０から成る７つの層を含んでいるＯＳＩモデル１００を示している。ＯＳＩモデル１００は、国際標準化機構（ＩＳＯ）により開発され、本願にも援用しているが「ＯＳＩ基準モデル」という標題でＩＳＯ７４９８に記述されている。
【００３９】
ＯＳＩモデルの各層は、特定のデータ通信タスク、即ち自身に先行する層への及び先行する層のためのサービス（例：ネットワーク層はトランスポート層のためのサービスを提供する）を行なう。プロセスは、郵便システムを介して送られる前に一連の封筒に手紙を入れることに似ている。後続の各封筒は、トランザクションを処理するのに必要なプロセッシング又はオーバーヘッド情報の別の層を追加する。全体として、封筒は全て、手紙が正しい宛先に確実に到着し、受信されたメッセージが送信されたメッセージと同一であることを保証することを助ける。一旦、全パケットがその宛先に受信されると、手紙自体が書かれたとおりに現れるまで、封筒は１つずつ開封される。
【００４０】
しかしながら、データ通信トランザクションでは、各エンドユーザーは封筒に気づかず、封筒は自身の機能を目に見えないように行なう。例えば、銀行の自動金銭出納トランザクションは多層ＯＳＩシステムを通して追跡可能である。ある１つの多層ＯＳＩシステム（オープンシステムＡ）は、トランザクションを試みている人に対するインターフェースであるアプリケーション層を提供し、一方別の多層ＯＳＩシステム（オープンシステムＢ）は、銀行のホストコンピュータのアプリケーションソフトウェアとインターフェースするアプリケーション層を提供する。オープンシステムＡ及びＢの対応している層はピア層と呼ばれ、ピアプロトコルを介して通信する。これらのピアプロトコルはユーザーアプリケーションのための通信サポートを提供し、口座の引き落とし、現金支払い、又は口座の貸し付け等、トランザクション関連のタスクを実行する。
【００４１】
２つのオープンシステム（オープンシステムＡ及びオープンシステムＢ）の間の実際のデータフローは、しかしながら、一方のオープンシステム（オープンシステムＡ即ちソース）のトップ１８０からボトム１８２へと通信ラインを横断して流れ、次に他方のオープンシステム（オープンシステムＢ即ち宛先）のボトム１８２からトップ１８０へと流れる。ユーザーアプリケーションのデータが同一のシステム内の１つの層から次の層へと下向きに流れる都度、より多くのプロセッシング情報が追加される。その情報が移動して他のシステムのピア層により処理されるときに、それは実行されるべき種々のタスク（エラー補正、フロー制御等）を生じさせる。
【００４２】
ＩＳＯは７層を特定的に定義しており、これよりそれらの層の概要について、実際にデータがソースを離れて流れる順に従って説明する。
【００４３】
層７即ちアプリケーション層１１０は、ユーザーアプリケーションが（銀行の現金自動支払機からお金をおろす等）ＯＳＩアプリケーション層とインターフェースすることに備えている。このＯＳＩアプリケーション層１１０は、他方のオープンシステム、即ち銀行のホストコンピュータ、に対応するピア層を有している。
【００４４】
層６即ちプレゼンテーション層１２０は、ユーザー情報（当座預金口座から現金で５０ドルを引き落とすためのリクエスト）を宛先のオープンシステムが理解できるフォーマット（即ち１と０の構文又はシーケンス）で確認する。
【００４５】
層５即ちセッション層１３０は、オープンシステム間のデータの同期性の制御（即ち、ソースの層５を通過するビット構成が確実に宛先の層５を通過するビット構成と同じになるようにする）を提供する。
【００４６】
層４即ちトランスポート層１４０は、端末対端末接続が２つのオープンシステム間に設定されていることを保証し、多くの場合信頼できる（即ち、宛先の層４は、接続のためのリクエストであること、いわば、それがソースの層４から受信されたこと確認する）。
【００４７】
層３即ちネットワーク層１５０は、ネットワークを通してのデータの経過指定と中継を提供する（他の事とともに、出て行く側の層３でアドレスは封筒上に置かれ、その後宛先の層３に読まれる）。
【００４８】
層２即ちデータリンク層１６０は、メッセージが一方のオープンシステムのこの層を下向きに通過し、他方のオープンシステムのピア層を上向きに通過するようなデータのフロー制御を含んでいる。
【００４９】
層１即ち物理的インターフェース層１７０は、データ通信機器が機械的且つ電気的に接続される方法と、データがそれら物理的接続を横断してソースの層１から宛先の層１まで移動する手段を含んでいる。
【００５０】
図２は、インターネットプロトコル・ネットワーク層２０２をＯＳＩ７層モデル２０４に当てはめた場合の比較２００を示している。図２では、トランスポート層２１０はアプリケーションにデータ接続サービスを提供するが、データがエラーやもれがない状態でシーケンスで届けられることを保証する機構を含んでいてもよい。ＴＣＰ／ＩＰモデル２１２のトランスポート層２１０は、セグメントをＩＰ層２０２に渡すことにより送信し、ＩＰ層２０２はセグメントを宛先まで経路づける。トランスポート層２１０は、ＩＰ２０２から入ってくるセグメントを受け入れ、どのアプリケーションが受取人なのかを判断し、データを当該アプリケーションへそれが送信された順序で渡す。
【００５１】
こうして、インターネットプロトコル２０２はネットワーク層機能を実行し、システム間の経路づけを行なう。データは、１つのリンクを横断することもあれば、インターネット内の幾つかのリンクをまたいで中継されることもある。データはデータグラムと呼ばれる単位で運ばれるが、このデータグラムには層３、２２０のアドレス指定情報を保有しているＩＰヘッダが含まれている。ルータは、データグラムをその宛先に向かわせるためにＩＰヘッダ内の宛先アドレスを調べる。すべてのデータグラムは独立して経路が決められ、ＩＰ層２０２は、データグラムの信頼できる即ちシーケンスでの配達を保証しないので、ＩＰ層２０２はコネクションレスと呼ばれる。ＩＰ層２０２は、特定のデータグラムがどのアプリケーション対アプリケーションの対話に属しているかに構わず、自身のトラフィックを経路決めする。
【００５２】
ＴＣＰ層２１０は、ＴＣＰ／ＩＰプロトコルを使用しているデバイス間に信頼できるデータ接続を提供する。ＴＣＰ層２１０は、データをデータグラムと呼ばれるデータパケットにパッキングし、物理層２３０を介して下層のネットワークを横断して伝送するために使用されるＩＰ層２０２の上位で動作する。
【００５３】
しかしながら、ＩＰプロトコルは、フロー制御又は伝送機構を何ら保有していない。そのような理由から、ＴＣＰ層２１０は普通はＩＰ層２０２の上で使用される訳である。反対に、ＴＣＰプロトコルは、失われたデータパケットを検知するための確認応答を提供する。
【００５４】
図３は、パケットのストリーム３００と、ＴＣＰスライディングウインドウ３１０を示している。ＴＣＰソースの主な特徴の１つは、ＴＣＰソースが、バイトを、そしてその結果、受信者からの確認応答が受信される前に送信することのできるＩＰパケットを確定することになるスライディングウインドウ３１０を使用することである。これは、ソースの有効伝送速度が調整できるようにする。
【００５５】
ＴＣＰソースがスライディングウインドウ３１０のサイズを増やすときには、その平均伝送速度も速くなる。スライディングウインドウ３１０はオクテット１２−１９の上にある。１１までのオクテットは送信されており、スライディングウインドウ３１０はそれらを通り越している。スライディングウインドウ３１０の内部にはオクテットグループ３２０、３２２がある。第１のオクテットグループ３２０は、既に送信３３０された１２から１６までのオクテットである。スライディングウインドウ３１０内のオクテットの第２グループ３２２は、まだ送信されていないオクテット１７−１９である。オクテットの第２グループ３２２は即座に送信することができる３４０。最後にオクテット２０以降３５０は、送信され得ない３６０。オクテット１２が確認応答し、スライディングウインドウが順方向にスライドして、始めてオクテット２０が送信できるようになる。こうして、ＴＣＰは、ＴＣＰスライディングウインドウ３１０を使って、失われたデータパケットの再伝送とフロー制御を提供する。スライディングウインドウ３１０は、実際には、受信者により送信されるウインドウ告示の輻輳ウインドウの最小限のものである。
【００５６】
図４はＴＣＰネットワークシステム４００を示しており、受信者４１０は、ソース４３０からデータ４４０を受信するとともに、確認応答４２０をソース４３０に提供する。受信者４１０は、ソース４３０に受信者４１０の入ってくるデータ４４０に対する対処能力を通知するためのウインドウ告示データ４５０も含んでいる、確認応答パケット４２０を送信する。こうして、受信者４１０は、フロー制御の用途に適するウインドウサイズ４５０を告示することができる。実際、ウインドウ告示４５０は、受信者４１０が、あとどれほど多くのデータのオクテットを受け入れる準備ができているかを規定する。ソース４３０により保守されている輻輳ウインドウ４６０がそれよりも小さい場合以外は、ソース４３０はこの告示に従って自身のスライディングウインドウを調節することになっている。
【００５７】
第２のウインドウ、即ち輻輳ウインドウ４６０は、スライディングウインドウのサイズを落すためにＴＣＰソース４３０で内部的に使用される。これはタイマーが時限切れになった場合に生じ、データパッケットは送信済みだが一定時間内に確認応答が到着していないということを教える。これはデータパケットが、最も高い可能性としてはネットワークの輻輳により、紛失されたことを意味する。輻輳状態を更に悪化させないために、ＴＣＰソース４３０はスライディングスウインドウのサイズを落すことにより伝送速度を下げる。これらウインドウの関係は、
Ｔw＝ＭＩＮ（ウインドウ告示，輻輳ウインドウ）
と表すことができ、ここにＴwは送信ウインドウ、即ちスライディングウインドウを指す。
【００５８】
原則的に、輻輳ウインドウ４６０と、下層のネットワークにより提供される告示ウインドウ４５０に含まれているフィードバック情報とは、同じ目的、即ちネットワークの負荷及び輻輳に従ってＴＣＰソース４３０の伝送速度を調節することに使用することができる。しかしながら、輻輳ウインドウ４６０と告示ウインドウ４５０に含まれているフィードバック情報との間のある１つの重大な相違点は、輻輳ウインドウ４６０が端末対端末ベースで動作し、タイムアウトが相対的に長いせいで、通常、変更に対する反応がかなり遅いということである。このようなわけで輻輳ウインドウ４６０は何れの詳細な情報を与えることもできない。ＴＣＰソース４１０は、パケットが捨てられたことを知るのみであり、ネットワークの状況について正確な全体像を与えることはしない。一方、告示ウインドウ４５０に含まれているフィードバック情報は、より正確で、変化している状況に対しより素早く反応する。
【００５９】
下層のネットワークは、ＴＣＰソース４１０の伝送速度を制御するために、確認応答パケット４２０で運ばれる受信者のウインドウ告示４５０を使うことができる。これは、デバイス若しくはここでフィードバック・インフォメーション・コンバータ（ＦＩＣ）と呼ばれるネットワーク機能性を加えることにより実現される。
【００６０】
こうして、ＴＣＰはスライディングウインドウ・プロトコルを使用し、ソース４３０は自身のウインドウサイズを、受信者４１０からの返信ＡＣＫパケット４２０に基づいて調節する。ウインドウ４６０の成長速度はこれら返信パケット４２０の速度に比例することになる。従って、返信ＡＣＫストリーム４２０のタイミングを修正することにより、ソースウインドウ４６０が制御され得ることは自明であろう。ＡＣＫ歩調合せ方法が依拠しているのはこの基本的原理である。厳密には、これらの方法は、混み合ったネットワーク要素、例えばアクセスノード及びＩＰルータなどにおいて、ソース４３０による過剰放出を制限するために、返信ＡＣＫパケット４２０を適度に遅延させる。これが正しく行なわれた場合、ＡＣＫ歩調合せは、ＴＣＰタイムアウトを縮小し、キューが大きくなるのを制限し、それにより全体的な接続の良好性を向上させる。
【００６１】
ＴＣＰトラフィックプロフィールの大きな非対称性のおかげで、ＡＣＫ歩調合せは現実的にはＴＣＰソース側４３０にしか必要でなくなる。これは、必要とされるＡＣＫ歩調合せの機能性が大規模ウェブ−サーバ／ファイル−ホストに限って必要であることを示唆しているので、特筆に価すべき点である。従って、より大規模で多様なユーザーアクセスベースにとって高価なアップグレードは不要となる。しかしながら、ＡＣＫ歩調合せはネットワーク内部の速度制御を良好にする点を強調したい。これは、本質的にネットワークをかなり一定の帯域幅にまとめ、輻輳が基本的にはアクセスノードで起きるようにする。
【００６２】
アドバンスドＡＴＭが持っている能力、例えばＶＢＲ−ｎｒｔ、ＡＢＲ、及びＧＦＲはこれらの条件を現実的に実現する。更には、高速ＩＰルータでの速度保証が実現されることは、ＡＣＫ歩調合せに対して好ましい状況を生み出すことにもなると期待される。
【００６３】
しかしながら、先に説明したように、現在のＡＣＫ歩調合せ方法の多くは、インプリメンテーションに対して特別に修正可能であるわけではない。例えば、高速ＴＣＰ（Ｆ−ＴＣＰ）は、順方向の下層データ「クリアリング」速度を知る必要があった。これは、リンク能力、又はＡＴＭ利用可能ビット速度（ＡＢＲ）サービスカテゴリーの場合の接続許容セル速度（ＡＣＲ）の何れかに当たる。ＡＣＫパケット４２０のための計算された遅れはこの速度に基づいている。
【００６４】
明らかなように、このようなスキームはより進化した情報処理方法を必要としており、下層の速度が広い範囲で変動する場合には問題が生じる。更には、遠隔のＴＣＰクライアント４１０によるＡＣＫパケット４２０の放出に遅れがある場合には、感度の問題を生じさせ、このようなスキームの性能を著しく劣化させることになりかねない。また、これらスキームは、返信ＡＣＫパケット４２０を集積的な方法、即ち先入れ先出し（ＦＩＦＯ）方式でバッファするだけなので、明示的な公平性規定を提供することができない。別のＡＣＫ歩調合せ方法、即ちＡＣＫバケットスキームは、フロー毎状態をあまりに多く必要としすぎるので、実質的に各ＴＣＰフローのウインドウ挙動を「追跡する」ことになる。
【００６５】
図５は、本発明によるエンハンスドＡＣＫ歩調合せデバイス５００を示している。ＡＣＫ歩調合せデバイス５００は、輻輳レベルを推測するに当たってはキューの長さ情報に依存するもので、追加の（高価な）タイマー機構を一切必要としない。図５に示すＡＣＫ歩調合せデバイス５００は、非常に包括的であるので、広範囲のネットワークに合うように仕立てることができる。
【００６６】
図５にはＡＣＫ制御装置５１０が設けられている。ＡＣＫ制御装置５１０は、オーバーロード（即ち輻輳）とアンダーロード両方の期間中、ＡＣＫスケジューラ装置５２０のオペレーションと共に、ＡＣＫパケットのプロセッシングを制御する。ＡＣＫ制御装置５１０は、下層のリンク層エンティティ５２８及びデータパケットバッファ５３０からの、トラフィック測定及びデータ伝送通知５２２に依存している。輻輳期間中は、返信ＡＣＫパケット５３２は、適当な分類細分性（集合体、クラス毎、フロー毎）を使ってＡＣＫバッファ５３４に記憶され、適切に選定された速度でゲートアウトされる。厳密には、混み合っている期間中のＡＣＫパケットの放出は、バッファ５３４が妥当な時間内に空にされるように行なわれる。輻輳が収まるとＡＣＫ放出速度は上げられ、帯域幅の利用が改善されることになる。ＡＣＫ制御装置５１０は、全てのケースにおいて、ＡＣＫスケジューラ装置５２０を起動させてバッファ５３４内のＡＣＫパケット５２０を放出させる点に留意されたい。
【００６７】
ＴＣＰは拡張可能なプロトコルなので、受信者ウインドウに制限がない場合には常に伝送クォータを増すよう試みる。これは、大きな（嵩高な）ファイル転送の場合に、通常のＴＣＰプロトコルは、ウインドウサイズを増大させ、パケットを紛失し、次に速度を落す、ということを繰り返すことを意味する。システム中のデータのボリュームが増大するにつれ、ＡＣＫパケット５３２の数も増える。
【００６８】
この点に、ＡＣＫ歩調合せの非常に明敏な含意がある。つまり、通常のＴＣＰプロトコルにおけるデータパケット５４０の成長は、ＡＣＫパケット５３２の成長に「置き換え」られる。これはＡＣＫバッファ「ドリフト」現象と称される。このドリフトの速度は、ゆっくりした開始体制でＴＣＰ接続とＡＣＫ歩調合せする場合には線形（即ち速い）となり、輻輳回避体制でＴＣＰ接続とＡＣＫ歩調合せする場合には略線形となる。
【００６９】
この問題に取り組む方法としては２つ考えられる。より単純なアプローチとしては、ＡＣＫバッファ５３４にＡＣＫパケット５３２用の十分な能力を設け、ＡＣＫバッファ５３４を使い果たす稀な事象においてはドロップ・フロム・フロント戦略を採用することである。通常、前置きのＡＣＫ数は、到着パケット５４０用のシーケンス数よりもシーケンス数が小さいという傾向が強い。ＡＣＫパケット５３２は小さく（４０バイト）ほとんどのファイル転送は無限ではないので、このバッファリングアプローチは非常に合理的である。例えば、ＲＡＭの６４ｋＢのＡＣＫバッファ５３４は、大凡１，７００のＡＣＫパケット５３２を保留することができるが、これは１５５Ｍｂ／ｓＷＡＮリンクにとっては適量を超えるものである。
【００７０】
別のアプローチは、２つの変数を使ってＴＣＰシーケンス数を追跡する、即ちフロー毎に後入れ後出し値を求めるということである。このアプローチでは必要なメモリの量が小さくてすむが、ＡＣＫ数の再書き込み（即ち合計の再計算）が必要になる。また、ＡＣＫパケット５３２が順不同に到着する場合は、特別な考慮が必要である。更には、受信者ウインドウサイズ及びＵＲＧ／ＲＳＴフラグのような、ＡＣＫパケット５３２内にある他のフィールドが、非冗長情報も保有しているという可能性が高く、これがまた問題を複雑にしている。
【００７１】
こうして、ＡＣＫバッファリングのアプローチは、インプリメンテーションの観点から実現の可能性がより高い。ＡＣＫバッファリングアプローチは、最小限の追加的拘束条件を出すが、ＴＣＰパケット５３２の何れのフィールドもいじることはない。
【００７２】
図５に示すように、データフローの順方向で、リンク層エンティティ５２８は広範な下層技術の代表となる。例として、専用リンク又はＡＴＭ  ＶＣ、又はＩＰフロークラスが挙げられる。更には、リンク層エンティティ５２８は、１つのＴＣＰフロー、例えばＡＴＭ  ＶＣ等の専用であるか、又はＴＣＰフローのグループ（トラフィック集合体）の中で共用されているか、の何れであってもよい。同様に、逆方向のＡＣＫ歩調合せは、異なるレベルで行なわれる。例えば、フロー毎のキューイングが順方向に実行される場合、フロー毎のＡＣＫ歩調合わせは逆方向にも必要とされ、即ちフローデータ毎／フロー毎ＡＣＫである。
【００７３】
しかしながら、集合体又はクラスベースのＡＣＫ歩調合せが順方向に行なわれる場合、同じように逆方向（集合体データ／集合体ＡＣＫ、クラス毎データ／クラス毎ＡＣＫ）に行なわれるのが望ましいであろう。他の場合としては、より単純で集約的なキューイングを順方向に行い、逆方向にはより進化したフロー毎ＡＣＫバッファリングを行なうように決めることもできる。このアプローチは、順方向の高速フロー毎バッファリング及びスケジューリング技術を必要とせずに、同一のリンク層エンティティ５３０に集約されたフロー内の公平性を改善する。入ってくるＡＣＫパケット５３２については、依然フロー毎ＡＣＫ計算が必要ではあるものの、それはネットワークのエッジに限られることで、そこではＡＣＫパケット５３２はより大きいＩＰパケットサイズに相応しいことから、処理速度の要件も著しく緩和されている。スケジューラ割付、即ち重みを、フローのＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例するように選定することにより、より小さなＭＳＳフローに対するバイアスは（ある程度まで）小さくできる。
【００７４】
差別化されたサービスアーキテクチャへの標準化に対する続行中の努力には、後者の原理がかなりうまくなじむ。つまり、フロー毎計算／オーバーヘッドは、ネットワークのアクセス部分、即ちＡＣＫ歩調合わせが行なわれる部分に限られるので、バックボーン内の複雑性が低減されることになる。ほとんどのアクセスノードはバックボーンデバイスよりも接続数がずっと少ないので、このアプローチはこれから出現するネットワークにおいて実現の可能性が非常に高い。
【００７５】
上記の説明に鑑みると、ＡＣＫスケジューラ５２０は、公平性を改善するために多様なパケットスケジューリング方法を取り入れている、かなり包括的なものであると規定することができる。例えば、集約（ＦＩＦＯ）ＡＣＫバッファリングの最も単純な形態では、スケジューラ５２０は、ヘッド・オブ・ライン（ＨＯＬ）ＡＣＫを送りさえすればよい。より進化したクラス毎又はフロー毎ＡＣＫバッファリング戦略では、重みつきラウンドロビン（ＷＲＲ）又は公平キューイング（ＦＱ）スケジューラが、送信に対し次に適するＡＣＫを「選定」するためにインプリメントすることができる。
【００７６】
ＡＣＫ制御装置５１０は、ソースに対するＡＣＫパケットの歩調合せを制御するためのＡＣＫ歩調合せプロセッサ５１２を含んでいる。ＡＣＫ歩調合せプロセッサは、２つの主要素、つまりデータパケット出発プロセッサ５１４とＡＣＫ到着プロセッサを含んでいる。ＡＣＫ到着プロセッサ５１６は輻輳レベルを調べ、入ってくるＡＣＫパケットを保留すべきかどうかを決める。データパケット出発プロセッサ５１４は、リンク層エンティティ５２８とデータパケットバッファ５３０を介して輻輳レベルを監視し、ソースに対して何時ＡＣＫパケット５３２を「クロック」アウトするかを決める。
【００７７】
図６は、本発明によるＴＣＰ  ＡＣＫ到着６１０及びデータ出発６６０方法の擬似コード６００を示している。ＴＣＰ  ＡＣＫ到着６１０及びデータ出発６６０方法は、入ってくるＴＣＰ  ＡＣＫパケット全てについて実行される。
【００７８】
図６では、キューオブジェクトがＡＣＫパケットをエンキュー／デキューするために存在しており、バッファされたＡＣＫパケットの数の実行計数が、例えばｎｕｍ＿ＡＣＫ６０４として保存されているものと仮定する。リンク層が輻輳している、及び／又はＡＣＫバッファ６１２が空でないというケースでは、入ってくるＡＣＫパケットはバッファ６１４に記憶される。バッファされたＡＣＫパケットはバッファに６１４保存され、データパケット出発方法６６０によってしか適切に送り出されない。
【００７９】
先に述べたように、ＡＣＫバファリングは集合体ベース、又は図５に関連して先に論じた、より選択的なクラス毎／フロー毎ベースで行なわれる。ＡＣＫパケットが空のバッファに到着し、そこに輻輳がなければ６４０、パケットは単純に前向きにＴＣＰソースへと送られる（即ち目に見えない通過）６４２。しかしながら、これがバッファされるべき最初のＡＣＫであれば６３０、ＡＣＫ放出プロセスを「ジャンプスタート」させるために、このＡＣＫパケットは適当な時間間隔の後ゲートアウトされねばならない６３２。
【００８０】
高価なタイマー機構への依存を回避するために、ＡＣＫパケットの放出は、リンク層エンティティ内の下層のデータパケット出発プロセス６６０に関係付けられねばならない。即ち、輻輳期間中、ＡＣＫパケットは、すべてのα1データパケットが放出されてしまった後に送られるということであり、ここにα1は（積分）減速因数の項である。
【００８１】
インプリメンテーションの観点から、上記機能性は、単純なカウンタ変数、例えばｐｋｔ＿ｃｏｕｎｔｅｒ６４４を使うことによりみごとに実現され得る。１番目のＡＣＫパケットについては、カウンタ変数値はα1にセットされ、データ出発プロセス６６０に従って、データパケット出発毎に減分される。カウンタ変数値がゼロになると、バッファされたＡＣＫパケットがリリースされ、カウンタはリセットされる。
【００８２】
予想に反して、与えられたα1の値はＴＣＰソースが等しい度数で減速することを示唆していない。ここで、問題は、緩慢なスタート／輻輳回避体制、及び「ＡＣＫの他の全ての特性」並びに遅延ＡＣＫタイマー等、のようなＴＣＰプロトコルの多くの特性により複雑になる。例えば、至る所に存在する「ＡＣＫの他の全ての」特性が使用可能になっている、無限なソースがフルサイズのセグメントを送信するという理想的なケースでは、ＴＣＰソースを抑制するにはα1＞３が必要となることが分かる。代わりに、ＴＣＰソースの端末システムの挙動が未知の場合、キューの長さ制御を「保証する」ために、非常に大きなα1値が使用される。換言すると、このような値は、輻輳が収まるまでは実質的に全てのＡＣＫの放出を禁じる（即ちオン／オフ型制御）が、大抵はキュー振動が増加する。
【００８３】
包括的でより柔軟性のある仕様を提示するために、図６の擬似コードは輻輳検知方法を明示的には指定しない点に着目されたい。厳密には、ｃｏｎｇｅｓｔｉｏｎ＿ｓｔａｔｕｓ（）ルーチン６２０は、単にブール値を戻してリンク層エンティティが輻輳しているかどうかを表示するだけである。多種多様な輻輳表示機構がここで使用できることは明らかである。キュー長、平均キュー長、入力速度オーバーロード測定、及びデータ紛失速度を例として挙げることができる。しかしながら、インプリメンテーションの複雑性を簡素にするために、キュー長を使用するのが望ましい。
【００８４】
２つのヒステリシスキュー閾値、ＱＬ７１０とＱＨ７１４を使ったサンプル方法７００の擬似コードを図７に示す。図７では、輻輳状態が調べられ、バイナリフラグが戻される７０２。ヒステリシスキュー閾値ＱＬ７１０とＱＨ７１２が使用される７２０。輻輳が存在してキューの長さがＱＬよりも小さい場合７２２、輻輳が収まる状態変化は、フラグを第１状態、即ちｃｏｎｇｅｓｔｅｄ＿ｆｌａｇ＝ＯＦＦにセットする７２４ことにより記憶される。代わりに、輻輳は存在せずキューの長さがＱＨよりも大きい場合７３０、輻輳開始の状態変化は、フラグを第２状態、即ちｃｏｎｇｅｓｔｅｄ＿ｆｌａｇ＝ＯＮにセットする７３２ことにより記憶される。次にバイナリフラグの状態は戻される７４０。
【００８５】
結果は、これらの閾値７１０、７２０がソースとアクセスノード間の往復にかかる遅れ（アクセス・ネットワーク・ディレイ）に基づいて適切にサイズ合わせされている場合、ほとんどロスの無い性能が実現できることを示している。このような遅れは、ＷＡＮネットワークに見られる端末対端末の遅れよりも何倍も小さいのが普通であるので、バッファリング要件におけるサイズ合わせ可能な縮小は、本発明のＡＣＫ歩調合せスキームで可能となる。
【００８６】
ここで再度図６を参照すると、データパケット出発方法６６０は、パケットがリンク層を出発するときはいつでも実行される。目標は、記憶されているＡＣＫパケットを適時にリリースし、それにより、アクセスノードのリンク層バッファの輻輳レベル（キュー）を適切に制御する、即ちパケット紛失を最小限にすることである。本方法はまず、送信を待っているバッファされたＡＣＫパケットがあるかどうか６６２、及びＡＣＫ放出カウンタ、即ちｐｋｔ＿ｃｏｕｎｔｅｒがゼロになっているかどうか６６４を調べる。そうである場合、バッファされたＡＣＫパケットはソースにリリース６７０される。
【００８７】
この後、輻輳が依然存在するのであれば６８０、ＡＣＫパケット内スペーシングは、ｐｋ＿ｃｏｕｎｔｅｒをα1にリセットすることによりα1データパケット毎に１に維持される６８２。これにより、データリンク層内のデータバッファを更に排出することができる。しかしながら、輻輳が緩和していれば６８４、ＡＣＫパケット内スペーシングはα2データパケットまで下げられ６８６、ソースがより速く送信できるようにする。α2パラメータは積分の加速因数の項であり、必ずα1＞α2である。カウンタがゼロでなければ６８８、それは単に減分されるだけである６９０。しかしながら、輻輳期間の後に帯域幅が十分に使用されなくなるのを防止するために、カウンタがα2よりも大きい場合、単にα2にリセットされるだけ（例えば、α2値がより大きい場合は特にそうである）である。
【００８８】
ここでも、ＴＣＰの特性により生じる複雑性のせいで、α2＝１値であってもＴＣＰソース速度が下層のリンクエンティティ速度に（大凡）等しいということではない。より厳密には「ＡＣＫの他の全ての」特性による理想的な条件に対しては、α2＝２という値の方が良好に機能する。
【００８９】
図５に戻るが、適格なＡＣＫパケット５３２は、ＡＣＫスケジューラ５２０により使用されているキューイング戦略に基づいて選定される。この機構全体は、記憶されているＡＣＫパケット５３２をリリースするに当たり、先行技術による方法において必要とされた高価なタイマー機構を必要としない。
【００９０】
図８は、本発明による、エンハンスドＴＣＰ  ＡＣＫ到着８１０とＡＴＭセル出発８６０方法に関する擬似コード８００を示している。ＴＣＰ  ＡＣＫ到着プロセス８１０において、リンク層エンティティは輻輳しているか否か、又はＡＣＫバッファが空でないか否かについて判定が行われる８１２。リンク層エンティティが輻輳しておりＡＣＫバッファが空でなければ８１４、入ってくるＡＣＫはキューに記憶（ＦＩＦＯ、クラス毎又はフロー毎）される８１６。ＡＣＫパケットは各ＡＣＫキューの末尾に記憶され、ＡＣＫカウントは増分される８１８。次に、ＡＣＫパケットはバッファされる最初のＡＣＫパケットか否かを判定するためにチェックが行われる８２０。これが、バッファされるべき１番目のＡＣＫパケットであれば８２２、カウンタがより大きなスペーシングにセットされるように、セルカウンタはα1*パケットセルにセットされる８２４。そうでない場合８２６、ＡＣＫパケットはＴＣＰソースに送られる８２８。
【００９１】
ＡＴＭセル出発プロセス８６０において、ＡＣＫバッファが空でないか否か、即ち送信されるべきＡＣＫパケットはあるかどうかについて判定が下される８６２。送信されるべきＡＣＫパケットがあれば８６４、スケジューラは、次に適格なＡＣＫパケットを確定する８７２。次に適格なＡＣＫパケットは、適格なＡＣＫキューの先頭から外され８７２、ＴＣＰソースに送られる８７４。ＡＣＫカウントは減分され８７６、セルカウンタは然るべくリセットされる８８０。輻輳が存在すれば８８２、スペーシングを増加させるためにセルカウンタはα1*パケットセルにセットされる８８４。そうでない場合８８６、スペーシングを減少させるためにセルカウンタはα2*パケットセルにセットされる８８８。
【００９２】
セルカウンタがゼロでなければ８９０、輻輳が緩和されたか否かについて判定が下される８９２。輻輳が収まっておりセルカウンタ値がα2*パケットセルよりも大きければ８９４、セルカウンタはα2*パケットセルに等しくセットされる８９５。そうでなければ８９６、セルカウンタは減分される８９８。
【００９３】
仮に上述のパケット取り扱い方法は非常に一般的であるとしても、より小さいパケット（セル）サイズを使用するＡＴＭネットワークの場合には、より多くの柔軟性が存在する。厳密には、データ（関数）パケット放出毎にＡＣＫ放出を実行することが可能であると同時に、高価なタイマー機構の使用を避ける道を見つけることが可能となり、つまりはカウンタはここではパケットではなくセルによる（セルカウンタ）ものとなる。セルサイズは、通常ＴＣＰ  ＭＳＳサイズのパケットよりもずっと小さいので、パケットはより細かく時間を細分化して放出することができる。即ち、パケットを基礎としたスキームの場合にはそうであったが、α1とα2の因数はもはや整数でなくともよいということである。定数値、ｐａｃｋｅｔ＿ｃｅｌｌ、即ち（ＩＰ）ＴＣＰ  ＭＳＳのセルの数を、
0004417566.tif 000002
数式（１）と考えよう。
【００９４】
再度図５に戻るが、輻輳中、ＡＣＫパケット５３２は、全てのα1*ｐａｃｋｅｔ＿ｃｅｌｌｓの後で、且つα2*ｐａｃｋｅｔ＿ｃｅｌｌｓのロード中に放出される。かなりの部分まで、ＡＣＫ到着及びセル出発方法は、パケットベースの相当物と同一である。例えば、全てのセルの放出の後、セルカウンタが減分されゼロになると、バッファ５３４内のＡＣＫパケット５３２が、ＡＣＫスケジューラ５２０によりリリースされる。ＡＣＫバッファ５３４が空になっている間、カウンタ値は然るべくリセットされる。
【００９５】
要約すると、ＡＴＭネットワーク上のＴＣＰプロトコルの性能は重要な領域である。最近では、より進化した下層のＡＴＭトランスポートカテゴリ（例：ＡＢＲフロー制御、接続毎キューイング）とのＴＣＰの会話を改善するために種々のＡＣＫ歩調合せスキームが提示されている。しかしながら、これらのスキームはパラメータの感度問題に悩まされており、実際には実現が困難であると考えられる。従って、広範なネットワークシナリオにおいて実行可能なエンハンスドＡＣＫ歩調合せを開示したわけである。本スキームは（より直接的な）キュー長輻輳情報を使ってＴＣＰ  ＡＣＫパケットを遅らせるので、広い範囲にわたって公平性の判定基準をインプリメントできる。本方法は端末対端末ＴＣＰ処理能力及び帯域幅公平性を改善する強力な手段を提供する。アクセスノードにおけるバッファリング要件も広範なサブネットワークに備えているので意義深い。
【００９６】
本発明の代表的な実施例についての上記記述は説明と記述を目的として提示したものである。上記説明は、本発明を網羅しようとしたり開示された厳密な形態に限定することを意図するものではない。上記教示に鑑み、多くの修正及び変更が可能であろう。本発明の範囲は、この詳細な説明によってではなく、請求項目によって限定されるものである。
【図面の簡単な説明】
【図１】  ７つの層を含んでいるＯＳＩモデルを示す図である。
【図２】  インターネット・プロトコル・ネットワーク層とＯＳＩ７層モデルとの比較を示す図である。
【図３】  パケットストリーム及びＴＣＰスライディングウインドウを示す図である。
【図４】  受信者がソースからデータを受信するとともに確認応答をソースに提供するネットワークシステムを示す図である。
【図５】  本発明によるエンハンスドＡＣＫ歩調合せデバイスの図である。
【図６】  本発明によるＴＣＰ  ＡＣＫ到着及びデータ出発６６０方法の擬似コードを示す図である。
【図７】  ２つのヒステリシスキュー閾値、ＱＬとＱＨを使った輻輳状態方法の擬似コードを示す図である。
【図８】  本発明によるエンハンスドＴＣＰ  ＡＣＫ到着及びＡＴＭセル出発方法の擬似コードを示す図である。
【図１】
0004417566.tif 000003
【図２】
0004417566.tif 000004
【図３】
0004417566.tif 000005
【図４】
0004417566.tif 000006
【図５】
0004417566.tif 000007
【図６】
0004417566.tif 000008
【図７】
0004417566.tif 000009
【図８】
0004417566.tif 000010