JP2002527936A - Ｔｃｐ接続のためのエンハンスド確認応答歩調合せデバイス及び方法 - Google Patents
Ｔｃｐ接続のためのエンハンスド確認応答歩調合せデバイス及び方法Info
- Publication number
- JP2002527936A JP2002527936A JP2000575250A JP2000575250A JP2002527936A JP 2002527936 A JP2002527936 A JP 2002527936A JP 2000575250 A JP2000575250 A JP 2000575250A JP 2000575250 A JP2000575250 A JP 2000575250A JP 2002527936 A JP2002527936 A JP 2002527936A
- Authority
- JP
- Japan
- Prior art keywords
- acknowledgment
- packet
- acknowledgment packet
- buffer
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1854—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
- H04L47/323—Discarding or blocking control packets, e.g. ACK packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
(57)【要約】
ＴＣＰ接続のためのエンハンスド確認応答歩調合せデバイス（５００）及び方法が開示されている。本発明は、ソースからデータパケットを受信して、データパケット（５４０）を順方向のデータリンクに送るためのリンク層エンティティ（５２８）であって、データパケットがリンク層エンティティ（５２８）を出発し順方向リンクに送られるまで、受信されたデータパケット（５４０）をデータパケットバッファ（５３０）に記憶するリンク層エンティティ（５２８）と、前記リンク層エンティティに連結されている、ソースからのデータパケット（５４０）の受信に応えてソースに送信されるべき確認応答パケット（５３２）を歩調合せするための確認応答歩調合せデバイス（５００）とを含んでいる。確認応答歩調合せデバイス（５００）は、リンク層エンティティ（５２８）における輻輳を監視し、リンク層エンティティ（５２８）に輻輳が起きているか否かに基づいて確認応答パケット（５３２）のプロセッシングを制御するための制御信号を生成するための確認応答制御装置（５１０）と、前記確認応答制御装置（５１０）に連結されている、確認応答制御装置（５１０）から受信した確認応答パケット（５３２）を記憶するための確認応答パケットバッファ（５３４）と、前記確認応答制御装置（５１０）及び確認応答パケットバッファ（５３４）に連結されている、前記確認応答制御装置（５１０）により生成された制御信号に基づいて確認応答パケット（５３２）をソース（５４０）にリリースするスケジューラ（５２０）を更に含んでいる。
Description
【０００１】 （発明の技術的分野） 本発明は、概括的にはネットワークに、より厳密にはＴＣＰ接続のためのエン
ハンスド確認応答歩調合せデバイス及び方法に関する。
ハンスド確認応答歩調合せデバイス及び方法に関する。
【０００２】 （発明の背景） 今日、管理機関のコンピュータネットワークは、循環システムになってきてい
る。管理機関は、デスクトップ・ワークステーション、サーバ、及びホストを、
ローカルエリアネットワーク（ＬＡＮ）集団へと合体させてきた。これらのロー
カルエリアネットワークは、他のローカルエリアネットワーク及びワイドエリア
ネットワーク（ＷＡＮ）に接続されている。日々のオペレーションにおいて、ネ
ットワークのどこに位置しているかに関係なく、対になったシステムが必要なと
きに必ず通信できるようになっていることが必要となってきた。
る。管理機関は、デスクトップ・ワークステーション、サーバ、及びホストを、
ローカルエリアネットワーク（ＬＡＮ）集団へと合体させてきた。これらのロー
カルエリアネットワークは、他のローカルエリアネットワーク及びワイドエリア
ネットワーク（ＷＡＮ）に接続されている。日々のオペレーションにおいて、ネ
ットワークのどこに位置しているかに関係なく、対になったシステムが必要なと
きに必ず通信できるようになっていることが必要となってきた。
【０００３】 ネットワークコンピューティングの初期の頃には、所有者のネットワークプロ
トコルが標準であった。しかしながら、国際標準化機構（ＩＳＯ）により導入さ
れたオープンシステム相互接続基準モデルは見事なまでに網間接続の度合いを高
めたので、エンドユーザーのアプリケーションがネットワークのシステム間で概
ね非常に良好に作動することができるようになっている。インプリメンテーショ
ンは、多数のコンピュータベンダー、ハードウェアコンポーネントベンダー、及
び独立したソフトウェア会社からのボランティアにより手にはいるようになった
書面標準に基づいている。
トコルが標準であった。しかしながら、国際標準化機構（ＩＳＯ）により導入さ
れたオープンシステム相互接続基準モデルは見事なまでに網間接続の度合いを高
めたので、エンドユーザーのアプリケーションがネットワークのシステム間で概
ね非常に良好に作動することができるようになっている。インプリメンテーショ
ンは、多数のコンピュータベンダー、ハードウェアコンポーネントベンダー、及
び独立したソフトウェア会社からのボランティアにより手にはいるようになった
書面標準に基づいている。
【０００４】 ここ１０年の間にＬＡＮは激増した。これにより、どのように輻輳を最小限に
し処理能力を最適化するかという問題が再浮上し、ネットワーク管理者はこの問
題を解決せねばならなくなっている。初期の解決策は、ローカルエリアネットワ
ークを、より少ない母集団を担う多数の小規模ネットワークに単純に分割すると
いうものであった。各セグメントはブリッジにより接続され、トラフィックが各
セグメントに対して局所的に差別して扱われるようになっている、単一のローカ
ルエリアネットワークを形成していた。
し処理能力を最適化するかという問題が再浮上し、ネットワーク管理者はこの問
題を解決せねばならなくなっている。初期の解決策は、ローカルエリアネットワ
ークを、より少ない母集団を担う多数の小規模ネットワークに単純に分割すると
いうものであった。各セグメントはブリッジにより接続され、トラフィックが各
セグメントに対して局所的に差別して扱われるようになっている、単一のローカ
ルエリアネットワークを形成していた。
【０００５】 新しいネットワークタイプの展開とワイドエリアネットワークは、ルータの必
要性を生み出した。例えば、インターネットはゲートウェイにより接続されたネ
ットワークのセットであるが、これは時にはルータと称されることもある。ルー
タは、同報通信ドメイン上でより多くの制御を提供し、同報通信トラフィックを
制限し、そしてセキュリティを強化するために、フィルタリングとファイアウォ
ールの能力を追加した。ルータは埋め込み型知能によりネットワークを通る最良
の経路を選定することができる。追加されたこの知能により、ルータは可能な場
合、目的地までの冗長経路を構築することもできる。それでもやはり、埋め込み
型知能により与えられた最良経路の選定能力には複雑性が加わるので、ルータの
ポート費用が増し、実質的には待ち時間というオーバーヘッドが生じた。分散し
たクライアント／サーバ・データトラフィック、拡大したユーザー母集団、及び
より複雑なアプリケーションを備えた共有媒体ネットワークが、新しい帯域幅ボ
トルネックを生み出した。このような輻輳により、ネットワーク応答時間は予測
不可能となり、遅れに敏感なアプリケーションをサポートできなくなり、ネット
ワークの故障頻度が上がった。
要性を生み出した。例えば、インターネットはゲートウェイにより接続されたネ
ットワークのセットであるが、これは時にはルータと称されることもある。ルー
タは、同報通信ドメイン上でより多くの制御を提供し、同報通信トラフィックを
制限し、そしてセキュリティを強化するために、フィルタリングとファイアウォ
ールの能力を追加した。ルータは埋め込み型知能によりネットワークを通る最良
の経路を選定することができる。追加されたこの知能により、ルータは可能な場
合、目的地までの冗長経路を構築することもできる。それでもやはり、埋め込み
型知能により与えられた最良経路の選定能力には複雑性が加わるので、ルータの
ポート費用が増し、実質的には待ち時間というオーバーヘッドが生じた。分散し
たクライアント／サーバ・データトラフィック、拡大したユーザー母集団、及び
より複雑なアプリケーションを備えた共有媒体ネットワークが、新しい帯域幅ボ
トルネックを生み出した。このような輻輳により、ネットワーク応答時間は予測
不可能となり、遅れに敏感なアプリケーションをサポートできなくなり、ネット
ワークの故障頻度が上がった。
【０００６】 現在のネットワークにおける輻輳制御は、益々重要な問題になりつつある。ワ
ールドワイドウェブ（ＷＷＷ）のようなインターネットアプリケーションの爆発
的な成長は現在の技術をその限界へと追いやっており、転送を迅速に行い、輻輳
を改善する制御機構の必要性が表面化している。その結果、多数の機器ベンダー
とサービスプロバイダは、関連する複雑な通信サービス品質（ＱＯＳ）管理問題
に対して適切な解決策を提供しようとアドバンスド・ネットワーキング技術に走
っている。例としては非同期転送モード（ＡＴＭ）ネットワークがあり、ＩＰネ
ットワークサービスも新たに出てきている。それにもかかわらず、これらのより
新しい対応策内で、現存する遺産のＩＰプロトコルのホストをサポートすること
がなお必要とされている。厳密には、至る所に存在するＴＣＰトランスポート層
プロトコルは、ＩＰネットワーク内では長きにわたり使われてきており、ウェブ
ブラウザ、ファイル／ｅメール転送サービス等により広く使われてきた。
ールドワイドウェブ（ＷＷＷ）のようなインターネットアプリケーションの爆発
的な成長は現在の技術をその限界へと追いやっており、転送を迅速に行い、輻輳
を改善する制御機構の必要性が表面化している。その結果、多数の機器ベンダー
とサービスプロバイダは、関連する複雑な通信サービス品質（ＱＯＳ）管理問題
に対して適切な解決策を提供しようとアドバンスド・ネットワーキング技術に走
っている。例としては非同期転送モード（ＡＴＭ）ネットワークがあり、ＩＰネ
ットワークサービスも新たに出てきている。それにもかかわらず、これらのより
新しい対応策内で、現存する遺産のＩＰプロトコルのホストをサポートすること
がなお必要とされている。厳密には、至る所に存在するＴＣＰトランスポート層
プロトコルは、ＩＰネットワーク内では長きにわたり使われてきており、ウェブ
ブラウザ、ファイル／ｅメール転送サービス等により広く使われてきた。
【０００７】 伝送制御プロトコル（ＴＣＰ）は、ＴＣＰ／ＩＰプロトコルファミリーの一部
であり、インターネットの成功と共に、世界的に最も重要なデータ通信プロトコ
ルの１つとしてのその地位を得ている。ＴＣＰはＴＣＰ／ＩＰプロトコルを使用
しているデバイス間に信頼できるデータ通信を提供する。ＴＣＰは、データをデ
ータグラムと呼ばれるデータパケットにパッキングするため、及びネットワーク
を横断して伝送するために使用されるＩＰの上位で動作する。
であり、インターネットの成功と共に、世界的に最も重要なデータ通信プロトコ
ルの１つとしてのその地位を得ている。ＴＣＰはＴＣＰ／ＩＰプロトコルを使用
しているデバイス間に信頼できるデータ通信を提供する。ＴＣＰは、データをデ
ータグラムと呼ばれるデータパケットにパッキングするため、及びネットワーク
を横断して伝送するために使用されるＩＰの上位で動作する。
【０００８】 インターネットプロトコル（ＩＰ）は、ネットワークを横断してデータをルー
ト付けるネットワーク層プロトコルである。インターネットプロトコルは、異な
るベンダーにより構築されたホストとルーターの使用に適応し、成長するネット
ワーク型式の成長の多様性を範囲に入れ、サービスに干渉することなくネットワ
ークを成長させ、セッション及びメッセージ指向型サービスの上位層をサポート
するように設計された。ＩＰネットワーク層は、ローカルエリアネットワークの
「島」を統合できるようにしている。
ト付けるネットワーク層プロトコルである。インターネットプロトコルは、異な
るベンダーにより構築されたホストとルーターの使用に適応し、成長するネット
ワーク型式の成長の多様性を範囲に入れ、サービスに干渉することなくネットワ
ークを成長させ、セッション及びメッセージ指向型サービスの上位層をサポート
するように設計された。ＩＰネットワーク層は、ローカルエリアネットワークの
「島」を統合できるようにしている。
【０００９】 しかしながら、ＩＰはフロー制御も再伝送機構も含んでいない。これが、ＴＣ
ＰがＩＰの上位で使用される理由である。特に、ＴＣＰは失われたデータパケッ
トを検知するため、確認応答を使用する。ＴＣＰ／ＩＰネットワークは、おそら
く今日では全ネットワークの中で最も重要であり、上記のＡＴＭ等幾つかの（物
理的）ネットワークの上位で動作する。これら下層のネットワークは、ネットワ
ークとトラフィックの状態についてある情報を提供するが、それは輻輳に関する
フィードバックを提供するために使用されることになる。
ＰがＩＰの上位で使用される理由である。特に、ＴＣＰは失われたデータパケッ
トを検知するため、確認応答を使用する。ＴＣＰ／ＩＰネットワークは、おそら
く今日では全ネットワークの中で最も重要であり、上記のＡＴＭ等幾つかの（物
理的）ネットワークの上位で動作する。これら下層のネットワークは、ネットワ
ークとトラフィックの状態についてある情報を提供するが、それは輻輳に関する
フィードバックを提供するために使用されることになる。
【００１０】 輻輳を管理するに当たり、ＴＣＰは、送信者のウインドウサイズを調節するた
めに反応性輻輳制御に連結されたスライディングウインドウ機構を使用する。こ
のプロトコルは、遠隔の受信者端末から送られてきた返送確認応答（ＡＣＫ）パ
ケット次第でその伝送行為を調整する。
めに反応性輻輳制御に連結されたスライディングウインドウ機構を使用する。こ
のプロトコルは、遠隔の受信者端末から送られてきた返送確認応答（ＡＣＫ）パ
ケット次第でその伝送行為を調整する。
【００１１】 しかしながら、ＴＣＰの問題は、輻輳制御機構が比較的低速なことである。ほ
とんどのＴＣＰインプリメンテーションは、タイムアウトを測定するのに非常に
粗いタイマーを使用しており、即ち２００−５００ｍｓの細分性である。更に、
ほとんどのＴＣＰインプリメンテーションは、輻輳を検知するのに、ＡＣＫディ
レイ又はパケット・ドロップに依存している。その結果、ソースウインドウが過
剰に縮小されると、ＴＣＰソースが強制的に自身の伝送ウインドウを再始動させ
られるので、大量の帯域幅が浪費されることになる。更に、多くの研究により、
ＴＣＰはＡＴＭネットワーク上では、特により大型のＷＡＮタイプの伝播ディレ
イについては、あまり良好に作動しないことが分かっている。
とんどのＴＣＰインプリメンテーションは、タイムアウトを測定するのに非常に
粗いタイマーを使用しており、即ち２００−５００ｍｓの細分性である。更に、
ほとんどのＴＣＰインプリメンテーションは、輻輳を検知するのに、ＡＣＫディ
レイ又はパケット・ドロップに依存している。その結果、ソースウインドウが過
剰に縮小されると、ＴＣＰソースが強制的に自身の伝送ウインドウを再始動させ
られるので、大量の帯域幅が浪費されることになる。更に、多くの研究により、
ＴＣＰはＡＴＭネットワーク上では、特により大型のＷＡＮタイプの伝播ディレ
イについては、あまり良好に作動しないことが分かっている。
【００１２】 ＴＣＰに関する上記欠点に立ち向かうためには、ＴＣＰフィードバックループ
に、より迅速な輻輳表示機構をどうにかして組み入れることにより、ネットワー
ク輻輳の機会を最小限にすることが必要である。しかしながら、現在のバージョ
ンとの互換性を保証し、そして市場の受け入れを促進するために、このような試
みは、実際のＴＣＰプロトコル又はそのインプリメンテーションに対する変更を
避けねばならない。
に、より迅速な輻輳表示機構をどうにかして組み入れることにより、ネットワー
ク輻輳の機会を最小限にすることが必要である。しかしながら、現在のバージョ
ンとの互換性を保証し、そして市場の受け入れを促進するために、このような試
みは、実際のＴＣＰプロトコル又はそのインプリメンテーションに対する変更を
避けねばならない。
【００１３】 これらの方針に沿って、様々なＡＣＫ歩調合せスキームが提示されてきた。こ
れらＡＣＫ歩調合せスキームは、基本的には、輻輳の期間中にソース放出を制限
するために、ＴＣＰ ＡＣＫパケットのスペーシングを調整する。ＡＣＫ歩調合
せは、ＡＴＭ、ギガバイトＩＰ（即ち光ＷＤＭ）のような高速（サブ）ネットワ
ーク又はサテライトの境界にうまく適合している。本質的には、この技術はアク
セスノードのＴＣＰトラフィック適合化を行なう。このような技法は、アドバン
スドＡＴＭデータサービス、即ち下層のＡＢＲフロー制御又は接続毎のキューイ
ングにとって特に有益である、というのも輻輳はＡＴＭの周辺部、即ちアクセス
ノードに生まれる傾向があるからである。ある輻輳距離により示されるように順
方向リンクが混み合っていれば、ＡＣＫパケットは適当に遅れてソースに送信さ
れる。
れらＡＣＫ歩調合せスキームは、基本的には、輻輳の期間中にソース放出を制限
するために、ＴＣＰ ＡＣＫパケットのスペーシングを調整する。ＡＣＫ歩調合
せは、ＡＴＭ、ギガバイトＩＰ（即ち光ＷＤＭ）のような高速（サブ）ネットワ
ーク又はサテライトの境界にうまく適合している。本質的には、この技術はアク
セスノードのＴＣＰトラフィック適合化を行なう。このような技法は、アドバン
スドＡＴＭデータサービス、即ち下層のＡＢＲフロー制御又は接続毎のキューイ
ングにとって特に有益である、というのも輻輳はＡＴＭの周辺部、即ちアクセス
ノードに生まれる傾向があるからである。ある輻輳距離により示されるように順
方向リンクが混み合っていれば、ＡＣＫパケットは適当に遅れてソースに送信さ
れる。
【００１４】 他の著者は、性能を改善するために、ＡＣＫパケット自体のフィールド、即ち
受信者ウインドウサイズを修正することを提案している。しかしながら、このよ
うなスキームは、正確な往復移動遅れの測定を必要条件とするか、さもなければ
タイトなバッファ制御を保守することができなくなるかの何れかである。更に、
ＡＣＫパケットフィールドの書き直しは、再計算を必要とし合計費用が高くつく
ことになる。
受信者ウインドウサイズを修正することを提案している。しかしながら、このよ
うなスキームは、正確な往復移動遅れの測定を必要条件とするか、さもなければ
タイトなバッファ制御を保守することができなくなるかの何れかである。更に、
ＡＣＫパケットフィールドの書き直しは、再計算を必要とし合計費用が高くつく
ことになる。
【００１５】 ＡＣＫ歩調合せはＴＣＰソースの挙動を制御する効果的な方法ではあっても、
提案されたスキームの多くは複雑すぎるか、及び／又はネットワークパラメータ
設定に対し過敏であるかの何れかである。研究によってＴＣＰの処理能力と公平
性レベルは多くの高速ネットワークシナリオでは低くなることが示されているの
で、その性能を強化するために効率がよく実用的なスキームを考案することが必
要である。プロトコルの機能そのものを改正することもオプションであるが、短
期から中期のタイムフレームにおいては実現可能な代替案とは言いかねる。この
方針によれば、ＡＣＫ歩調合せ方法は意義深い利益を与えることができる。
提案されたスキームの多くは複雑すぎるか、及び／又はネットワークパラメータ
設定に対し過敏であるかの何れかである。研究によってＴＣＰの処理能力と公平
性レベルは多くの高速ネットワークシナリオでは低くなることが示されているの
で、その性能を強化するために効率がよく実用的なスキームを考案することが必
要である。プロトコルの機能そのものを改正することもオプションであるが、短
期から中期のタイムフレームにおいては実現可能な代替案とは言いかねる。この
方針によれば、ＡＣＫ歩調合せ方法は意義深い利益を与えることができる。
【００１６】 ＡＣＫ歩調合せのためのより強固で包括的なスキームが必要とされている。
【００１７】 高い処理能力と精密なレベルの帯域幅公平性を提供するＡＣＫ歩調合せも必要
とされている。
とされている。
【００１８】 更に、ＴＣＰバッファリング遅れを大幅に低減し、広範なネットワークシナリ
オに適応可能なＡＣＫ歩調合せへの必要性も表面化している。
オに適応可能なＡＣＫ歩調合せへの必要性も表面化している。
【００１９】 又更に、ＴＣＰプロトコルを修正することなく、より迅速な輻輳表示を提供す
るＡＣＫ歩調合せへの必要性も表面化している。
るＡＣＫ歩調合せへの必要性も表面化している。
【００２０】 （発明の概要） 上記先行技術における限界を克服するため、そして本明細書を読み、理解する
際に明らかになるであろう他の限界を克服するために、本発明はＴＣＰ接続のた
めのエンハンスド確認応答歩調合せデバイス及び方法を開示する。
際に明らかになるであろう他の限界を克服するために、本発明はＴＣＰ接続のた
めのエンハンスド確認応答歩調合せデバイス及び方法を開示する。
【００２１】 本発明は、ＡＣＫ歩調合せのためのより強靭で包括的なスキームを提供するこ
とにより上記問題を解決する。本発明によるＡＣＫ歩調合せは、高い処理能力と
精密なレベルの帯域幅公平性を提供する。更に、ＡＣＫ歩調合せは、ＴＣＰバッ
ファリング遅れを大幅に低減し、広範なネットワークシナリオに適用することが
できる。こうして、本ＡＣＫ歩調合せは、ＴＣＰプロトコルを修正することなく
より迅速な輻輳表示を提供する。
とにより上記問題を解決する。本発明によるＡＣＫ歩調合せは、高い処理能力と
精密なレベルの帯域幅公平性を提供する。更に、ＡＣＫ歩調合せは、ＴＣＰバッ
ファリング遅れを大幅に低減し、広範なネットワークシナリオに適用することが
できる。こうして、本ＡＣＫ歩調合せは、ＴＣＰプロトコルを修正することなく
より迅速な輻輳表示を提供する。
【００２２】 本発明の原理によるシステムは、ソースからデータパケットを受信しデータパ
ケットを順方向データリンクへ送るためのリンク層エンティティであって、受信
したデータパケットを、データパケットがリンク層エンティティを離れて順方向
データリンクへと送られるまでデータパケットバッファに記憶するリンク層エン
ティティと、リンク層エンティティに連結されていて、ソースからのデータパケ
ットの受信に応えてソースに送られるＡＣＫパケットを歩調合せするための確認
応答歩調合せデバイスとを含んでいる。確認応答歩調合せデバイスは、リンク層
エンティティの輻輳を監視し、リンク層エンティティに輻輳が起きているかどう
かに基づいて確認応答パケットのプロセシングを制御するための制御信号を生成
するための確認応答制御装置と、確認応答制御装置に連結されている、確認応答
制御装置から受信された確認応答パケットを記憶するための確認応答パケットバ
ッファと、確認応答制御装置と確認応答バッファに連結されている、確認応答制
御装置により生成された制御信号に基づいてソースに確認応答パケットをリリー
スするスケジューラを更に含んでいる。
ケットを順方向データリンクへ送るためのリンク層エンティティであって、受信
したデータパケットを、データパケットがリンク層エンティティを離れて順方向
データリンクへと送られるまでデータパケットバッファに記憶するリンク層エン
ティティと、リンク層エンティティに連結されていて、ソースからのデータパケ
ットの受信に応えてソースに送られるＡＣＫパケットを歩調合せするための確認
応答歩調合せデバイスとを含んでいる。確認応答歩調合せデバイスは、リンク層
エンティティの輻輳を監視し、リンク層エンティティに輻輳が起きているかどう
かに基づいて確認応答パケットのプロセシングを制御するための制御信号を生成
するための確認応答制御装置と、確認応答制御装置に連結されている、確認応答
制御装置から受信された確認応答パケットを記憶するための確認応答パケットバ
ッファと、確認応答制御装置と確認応答バッファに連結されている、確認応答制
御装置により生成された制御信号に基づいてソースに確認応答パケットをリリー
スするスケジューラを更に含んでいる。
【００２３】 本発明の原理による他のシステムの実施例は、代わりの又は随意的な他の態様
を含んでいる。本発明のこのような態様の１つは、キューイング戦略に基づいて
スケジューラがＡＣＫパケットを選定してリリースすることである。
を含んでいる。本発明のこのような態様の１つは、キューイング戦略に基づいて
スケジューラがＡＣＫパケットを選定してリリースすることである。
【００２４】 本発明の別の態様は、キューイング戦略が、集合体ＡＣＫパケットバッファリ
ングが使用される場合には、ヘッド・オブ・ラインＡＣＫパケットを送信する段
階を含んでいることである。
ングが使用される場合には、ヘッド・オブ・ラインＡＣＫパケットを送信する段
階を含んでいることである。
【００２５】 本発明の別の態様は、キューイング戦略が、クラス毎又はフロー毎ＡＣＫパケ
ットバッファリングが使用されている場合には、リリースに向けてＡＣＫパケッ
トバッファ中のＡＣＫパケットを選択するための加重ラウンドロビン（ＷＲＲ）
プロセスを含んでいることである。
ットバッファリングが使用されている場合には、リリースに向けてＡＣＫパケッ
トバッファ中のＡＣＫパケットを選択するための加重ラウンドロビン（ＷＲＲ）
プロセスを含んでいることである。
【００２６】 本発明の別の態様は、加重ラウンドロビン（ＷＲＲ）が、ＴＣＰ最大セグメン
トサイズ（ＭＳＳ）に反比例してリリースするために、ＡＣＫパケットの選択に
加重するための重みを使用して、より小さなＭＳＳフローに対する偏りを少なく
することである。
トサイズ（ＭＳＳ）に反比例してリリースするために、ＡＣＫパケットの選択に
加重するための重みを使用して、より小さなＭＳＳフローに対する偏りを少なく
することである。
【００２７】 本発明の別の態様は、キューイング戦略が、クラス毎又はフロー毎ＡＣＫパケ
ットバッファリングが使用される場合には、リリースに際しＡＣＫパケットバッ
ファ内のあるＡＣＫパケットを選択するための公平なキューイング（ＦＱ）プロ
セスを含んでいることである。
ットバッファリングが使用される場合には、リリースに際しＡＣＫパケットバッ
ファ内のあるＡＣＫパケットを選択するための公平なキューイング（ＦＱ）プロ
セスを含んでいることである。
【００２８】 本発明の別の態様は、確認応答制御装置が、ＡＣＫパケット到着プロセッサと
データパケット出発プロセッサを使って確認応答パケットのプロセッシングを制
御するための制御信号を生成するＡＣＫパケット歩調合せプロセッサを更に含ん
でいることである。
データパケット出発プロセッサを使って確認応答パケットのプロセッシングを制
御するための制御信号を生成するＡＣＫパケット歩調合せプロセッサを更に含ん
でいることである。
【００２９】 本発明の別の態様は、ＡＣＫパケット到着プロセッサが、リンク層エンティテ
ィの輻輳をチェックし、ＡＣＫパケットをＡＣＫパケットバッファに保留するか
又はＡＣＫパケットをＡＣＫパケットバッファにバッファせずにＡＣＫパケット
を直接ソースに送るべきかを決定することにより、ＡＣＫパケットバッファに対
するＡＣＫパケットのプロセッシングを制御することである。
ィの輻輳をチェックし、ＡＣＫパケットをＡＣＫパケットバッファに保留するか
又はＡＣＫパケットをＡＣＫパケットバッファにバッファせずにＡＣＫパケット
を直接ソースに送るべきかを決定することにより、ＡＣＫパケットバッファに対
するＡＣＫパケットのプロセッシングを制御することである。
【００３０】 本発明の別の態様は、ＡＣＫパケット到着プロセッサが、リンク層エンティテ
ィが混み合っているかどうかを判定し、ＡＣＫパケットバッファが空であるかど
うかを判定し、リンク層エンティティが混み合っているか又はＡＣＫパケットバ
ッファが空である場合はＡＣＫパケットをバッファに記憶し、ＡＣＫパケットバ
ッファが空でありリンク層エンティティが混み合っていない場合はＡＣＫパケッ
トを送ることにより、ＡＣＫパケットをＡＣＫパケットバッファに保留するか又
はＡＣＫパケットをＡＣＫパケットバッファにバッファせずにＡＣＫパケットを
直接ソースに送るべきかを決定することである。
ィが混み合っているかどうかを判定し、ＡＣＫパケットバッファが空であるかど
うかを判定し、リンク層エンティティが混み合っているか又はＡＣＫパケットバ
ッファが空である場合はＡＣＫパケットをバッファに記憶し、ＡＣＫパケットバ
ッファが空でありリンク層エンティティが混み合っていない場合はＡＣＫパケッ
トを送ることにより、ＡＣＫパケットをＡＣＫパケットバッファに保留するか又
はＡＣＫパケットをＡＣＫパケットバッファにバッファせずにＡＣＫパケットを
直接ソースに送るべきかを決定することである。
【００３１】 本発明の別の態様は、ＡＣＫパケットは、そのＡＣＫパケットが輻輳中にＡＣ
Ｋパケットバッファにバッファされるべき第１のＡＣＫパケットである場合は、
スケジューラによりＡＣＫパケットバッファに記憶され、ゲートアウトされるこ
とである。
Ｋパケットバッファにバッファされるべき第１のＡＣＫパケットである場合は、
スケジューラによりＡＣＫパケットバッファに記憶され、ゲートアウトされるこ
とである。
【００３２】 本発明の別の態様は、そのＡＣＫパケットが輻輳中にＡＣＫパケットバッファ
にバッファされるべき第１のＡＣＫパケットである場合は、ＡＣＫ制御装置がＡ
ＣＫパケットバッファからゲートされたＡＣＫパケット相互間のスペーシングを
大きくすることである。
にバッファされるべき第１のＡＣＫパケットである場合は、ＡＣＫ制御装置がＡ
ＣＫパケットバッファからゲートされたＡＣＫパケット相互間のスペーシングを
大きくすることである。
【００３３】 本発明の別の態様は、リンク層エンティティの輻輳がおさまった場合は、デー
タパケット出発プロセッサが、ＡＣＫパケットバッファからのＡＣＫパケットの
リリースの間隔を小さくすることである。
タパケット出発プロセッサが、ＡＣＫパケットバッファからのＡＣＫパケットの
リリースの間隔を小さくすることである。
【００３４】 以上及び他の様々な利点、並びに本発明を特徴付ける新規な特性は、本願に附
随しその一部を成す請求項目により厳密に指摘される。しかしながら、本発明、
その利点、及びその使用により得られる目的をより深く理解するためには、本願
の別の一部を成す図面並びに附随の説明事項を参照すべきであり、そこには本発
明による装置の具体例を図示し説明している。
随しその一部を成す請求項目により厳密に指摘される。しかしながら、本発明、
その利点、及びその使用により得られる目的をより深く理解するためには、本願
の別の一部を成す図面並びに附随の説明事項を参照すべきであり、そこには本発
明による装置の具体例を図示し説明している。
【００３５】 (好適な実施例の詳細な説明) これより図面を参照するが、全体を通して類似符号は対応している部分を表す
ものである。
ものである。
【００３６】 代表的実施例を以下に記述する中で、本願の一部を成す附随図面を参照するこ
とになるが、当図面は本発明が具現化されている特定の実施例の説明に役立つよ
うに示すものである。本発明の範囲を逸脱することなく、構造的変更を加えた他
の実施例も使用できるものと理解して頂きたい。
とになるが、当図面は本発明が具現化されている特定の実施例の説明に役立つよ
うに示すものである。本発明の範囲を逸脱することなく、構造的変更を加えた他
の実施例も使用できるものと理解して頂きたい。
【００３７】 本発明は、ＴＣＰ接続のためのエンハンスド確認応答歩調合せデバイスを提供
する。高い処理能力と精密なレベルの帯域幅公平性を可能にするＡＣＫ歩調合せ
のためのより強靭で包括的なスキームが提供される。更に、ＡＣＫ歩調合せは、
ＴＣＰバッファリング遅れを大幅に低減し、広範なネットワークシナリオに適用
することができる。こうして、本発明によるＡＣＫ歩調合せは、ＴＣＰプロトコ
ルを修正することなく、より迅速な輻輳表示を提供する。
する。高い処理能力と精密なレベルの帯域幅公平性を可能にするＡＣＫ歩調合せ
のためのより強靭で包括的なスキームが提供される。更に、ＡＣＫ歩調合せは、
ＴＣＰバッファリング遅れを大幅に低減し、広範なネットワークシナリオに適用
することができる。こうして、本発明によるＡＣＫ歩調合せは、ＴＣＰプロトコ
ルを修正することなく、より迅速な輻輳表示を提供する。
【００３８】 図１は、アプリケーション層１１０、プレゼンテーション層１２０、セッショ
ン層１３０、トランスポート層１４０、ネットワーク層１５０、データリンク層
１６０、物理層１７０から成る７つの層を含んでいるＯＳＩモデル１００を示し
ている。ＯＳＩモデル１００は、国際標準化機構（ＩＳＯ）により開発され、本
願にも援用しているが「ＯＳＩ基準モデル」という標題でＩＳＯ７４９８に記述
されている。
ン層１３０、トランスポート層１４０、ネットワーク層１５０、データリンク層
１６０、物理層１７０から成る７つの層を含んでいるＯＳＩモデル１００を示し
ている。ＯＳＩモデル１００は、国際標準化機構（ＩＳＯ）により開発され、本
願にも援用しているが「ＯＳＩ基準モデル」という標題でＩＳＯ７４９８に記述
されている。
【００３９】 ＯＳＩモデルの各層は、特定のデータ通信タスク、即ち自身に先行する層への
及び先行する層のためのサービス（例：ネットワーク層はトランスポート層のた
めのサービスを提供する）を行なう。プロセスは、郵便システムを介して送られ
る前に一連の封筒に手紙を入れることに似ている。後続の各封筒は、トランザク
ションを処理するのに必要なプロセッシング又はオーバーヘッド情報の別の層を
追加する。全体として、封筒は全て、手紙が正しい宛先に確実に到着し、受信さ
れたメッセージが送信されたメッセージと同一であることを保証することを助け
る。一旦、全パケットがその宛先に受信されると、手紙自体が書かれたとおりに
現れるまで、封筒は１つずつ開封される。
及び先行する層のためのサービス（例：ネットワーク層はトランスポート層のた
めのサービスを提供する）を行なう。プロセスは、郵便システムを介して送られ
る前に一連の封筒に手紙を入れることに似ている。後続の各封筒は、トランザク
ションを処理するのに必要なプロセッシング又はオーバーヘッド情報の別の層を
追加する。全体として、封筒は全て、手紙が正しい宛先に確実に到着し、受信さ
れたメッセージが送信されたメッセージと同一であることを保証することを助け
る。一旦、全パケットがその宛先に受信されると、手紙自体が書かれたとおりに
現れるまで、封筒は１つずつ開封される。
【００４０】 しかしながら、データ通信トランザクションでは、各エンドユーザーは封筒に
気づかず、封筒は自身の機能を目に見えないように行なう。例えば、銀行の自動
金銭出納トランザクションは多層ＯＳＩシステムを通して追跡可能である。ある
１つの多層ＯＳＩシステム（オープンシステムＡ）は、トランザクションを試み
ている人に対するインターフェースであるアプリケーション層を提供し、一方別
の多層ＯＳＩシステム（オープンシステムＢ）は、銀行のホストコンピュータの
アプリケーションソフトウェアとインターフェースするアプリケーション層を提
供する。オープンシステムＡ及びＢの対応している層はピア層と呼ばれ、ピアプ
ロトコルを介して通信する。これらのピアプロトコルはユーザーアプリケーショ
ンのための通信サポートを提供し、口座の引き落とし、現金支払い、又は口座の
貸し付け等、トランザクション関連のタスクを実行する。
気づかず、封筒は自身の機能を目に見えないように行なう。例えば、銀行の自動
金銭出納トランザクションは多層ＯＳＩシステムを通して追跡可能である。ある
１つの多層ＯＳＩシステム（オープンシステムＡ）は、トランザクションを試み
ている人に対するインターフェースであるアプリケーション層を提供し、一方別
の多層ＯＳＩシステム（オープンシステムＢ）は、銀行のホストコンピュータの
アプリケーションソフトウェアとインターフェースするアプリケーション層を提
供する。オープンシステムＡ及びＢの対応している層はピア層と呼ばれ、ピアプ
ロトコルを介して通信する。これらのピアプロトコルはユーザーアプリケーショ
ンのための通信サポートを提供し、口座の引き落とし、現金支払い、又は口座の
貸し付け等、トランザクション関連のタスクを実行する。
【００４１】 ２つのオープンシステム（オープンシステムＡ及びオープンシステムＢ）の間
の実際のデータフローは、しかしながら、一方のオープンシステム（オープンシ
ステムＡ即ちソース）のトップ１８０からボトム１８２へと通信ラインを横断し
て流れ、次に他方のオープンシステム（オープンシステムＢ即ち宛先）のボトム
１８２からトップ１８０へと流れる。ユーザーアプリケーションのデータが同一
のシステム内の１つの層から次の層へと下向きに流れる都度、より多くのプロセ
ッシング情報が追加される。その情報が移動して他のシステムのピア層により処
理されるときに、それは実行されるべき種々のタスク（エラー補正、フロー制御
等）を生じさせる。
の実際のデータフローは、しかしながら、一方のオープンシステム（オープンシ
ステムＡ即ちソース）のトップ１８０からボトム１８２へと通信ラインを横断し
て流れ、次に他方のオープンシステム（オープンシステムＢ即ち宛先）のボトム
１８２からトップ１８０へと流れる。ユーザーアプリケーションのデータが同一
のシステム内の１つの層から次の層へと下向きに流れる都度、より多くのプロセ
ッシング情報が追加される。その情報が移動して他のシステムのピア層により処
理されるときに、それは実行されるべき種々のタスク（エラー補正、フロー制御
等）を生じさせる。
【００４２】 ＩＳＯは７層を特定的に定義しており、これよりそれらの層の概要について、
実際にデータがソースを離れて流れる順に従って説明する。
実際にデータがソースを離れて流れる順に従って説明する。
【００４３】 層７即ちアプリケーション層１１０は、ユーザーアプリケーションが（銀行の
現金自動支払機からお金をおろす等）ＯＳＩアプリケーション層とインターフェ
ースすることに備えている。このＯＳＩアプリケーション層１１０は、他方のオ
ープンシステム、即ち銀行のホストコンピュータ、に対応するピア層を有してい
る。
現金自動支払機からお金をおろす等）ＯＳＩアプリケーション層とインターフェ
ースすることに備えている。このＯＳＩアプリケーション層１１０は、他方のオ
ープンシステム、即ち銀行のホストコンピュータ、に対応するピア層を有してい
る。
【００４４】 層６即ちプレゼンテーション層１２０は、ユーザー情報（当座預金口座から現
金で５０ドルを引き落とすためのリクエスト）を宛先のオープンシステムが理解
できるフォーマット（即ち１と０の構文又はシーケンス）で確認する。
金で５０ドルを引き落とすためのリクエスト）を宛先のオープンシステムが理解
できるフォーマット（即ち１と０の構文又はシーケンス）で確認する。
【００４５】 層５即ちセッション層１３０は、オープンシステム間のデータの同期性の制御
（即ち、ソースの層５を通過するビット構成が確実に宛先の層５を通過するビッ
ト構成と同じになるようにする）を提供する。
（即ち、ソースの層５を通過するビット構成が確実に宛先の層５を通過するビッ
ト構成と同じになるようにする）を提供する。
【００４６】 層４即ちトランスポート層１４０は、端末対端末接続が２つのオープンシステ
ム間に設定されていることを保証し、多くの場合信頼できる（即ち、宛先の層４
は、接続のためのリクエストであること、いわば、それがソースの層４から受信
されたこと確認する）。
ム間に設定されていることを保証し、多くの場合信頼できる（即ち、宛先の層４
は、接続のためのリクエストであること、いわば、それがソースの層４から受信
されたこと確認する）。
【００４７】 層３即ちネットワーク層１５０は、ネットワークを通してのデータの経過指定
と中継を提供する（他の事とともに、出て行く側の層３でアドレスは封筒上に置
かれ、その後宛先の層３に読まれる）。
と中継を提供する（他の事とともに、出て行く側の層３でアドレスは封筒上に置
かれ、その後宛先の層３に読まれる）。
【００４８】 層２即ちデータリンク層１６０は、メッセージが一方のオープンシステムのこ
の層を下向きに通過し、他方のオープンシステムのピア層を上向きに通過するよ
うなデータのフロー制御を含んでいる。
の層を下向きに通過し、他方のオープンシステムのピア層を上向きに通過するよ
うなデータのフロー制御を含んでいる。
【００４９】 層１即ち物理的インターフェース層１７０は、データ通信機器が機械的且つ電
気的に接続される方法と、データがそれら物理的接続を横断してソースの層１か
ら宛先の層１まで移動する手段を含んでいる。
気的に接続される方法と、データがそれら物理的接続を横断してソースの層１か
ら宛先の層１まで移動する手段を含んでいる。
【００５０】 図２は、インターネットプロトコル・ネットワーク層２０２をＯＳＩ７層モデ
ル２０４に当てはめた場合の比較２００を示している。図２では、トランスポー
ト層２１０はアプリケーションにデータ接続サービスを提供するが、データがエ
ラーやもれがない状態でシーケンスで届けられることを保証する機構を含んでい
てもよい。ＴＣＰ／ＩＰモデル２１２のトランスポート層２１０は、セグメント
をＩＰ層２０２に渡すことにより送信し、ＩＰ層２０２はセグメントを宛先まで
経路づける。トランスポート層２１０は、ＩＰ２０２から入ってくるセグメント
を受け入れ、どのアプリケーションが受取人なのかを判断し、データを当該アプ
リケーションへそれが送信された順序で渡す。
ル２０４に当てはめた場合の比較２００を示している。図２では、トランスポー
ト層２１０はアプリケーションにデータ接続サービスを提供するが、データがエ
ラーやもれがない状態でシーケンスで届けられることを保証する機構を含んでい
てもよい。ＴＣＰ／ＩＰモデル２１２のトランスポート層２１０は、セグメント
をＩＰ層２０２に渡すことにより送信し、ＩＰ層２０２はセグメントを宛先まで
経路づける。トランスポート層２１０は、ＩＰ２０２から入ってくるセグメント
を受け入れ、どのアプリケーションが受取人なのかを判断し、データを当該アプ
リケーションへそれが送信された順序で渡す。
【００５１】 こうして、インターネットプロトコル２０２はネットワーク層機能を実行し、
システム間の経路づけを行なう。データは、１つのリンクを横断することもあれ
ば、インターネット内の幾つかのリンクをまたいで中継されることもある。デー
タはデータグラムと呼ばれる単位で運ばれるが、このデータグラムには層３、２
２０のアドレス指定情報を保有しているＩＰヘッダが含まれている。ルータは、
データグラムをその宛先に向かわせるためにＩＰヘッダ内の宛先アドレスを調べ
る。すべてのデータグラムは独立して経路が決められ、ＩＰ層２０２は、データ
グラムの信頼できる即ちシーケンスでの配達を保証しないので、ＩＰ層２０２は
コネクションレスと呼ばれる。ＩＰ層２０２は、特定のデータグラムがどのアプ
リケーション対アプリケーションの対話に属しているかに構わず、自身のトラフ
ィックを経路決めする。
システム間の経路づけを行なう。データは、１つのリンクを横断することもあれ
ば、インターネット内の幾つかのリンクをまたいで中継されることもある。デー
タはデータグラムと呼ばれる単位で運ばれるが、このデータグラムには層３、２
２０のアドレス指定情報を保有しているＩＰヘッダが含まれている。ルータは、
データグラムをその宛先に向かわせるためにＩＰヘッダ内の宛先アドレスを調べ
る。すべてのデータグラムは独立して経路が決められ、ＩＰ層２０２は、データ
グラムの信頼できる即ちシーケンスでの配達を保証しないので、ＩＰ層２０２は
コネクションレスと呼ばれる。ＩＰ層２０２は、特定のデータグラムがどのアプ
リケーション対アプリケーションの対話に属しているかに構わず、自身のトラフ
ィックを経路決めする。
【００５２】 ＴＣＰ層２１０は、ＴＣＰ／ＩＰプロトコルを使用しているデバイス間に信頼
できるデータ接続を提供する。ＴＣＰ層２１０は、データをデータグラムと呼ば
れるデータパケットにパッキングし、物理層２３０を介して下層のネットワーク
を横断して伝送するために使用されるＩＰ層２０２の上位で動作する。
できるデータ接続を提供する。ＴＣＰ層２１０は、データをデータグラムと呼ば
れるデータパケットにパッキングし、物理層２３０を介して下層のネットワーク
を横断して伝送するために使用されるＩＰ層２０２の上位で動作する。
【００５３】 しかしながら、ＩＰプロトコルは、フロー制御又は伝送機構を何ら保有してい
ない。そのような理由から、ＴＣＰ層２１０は普通はＩＰ層２０２の上で使用さ
れる訳である。反対に、ＴＣＰプロトコルは、失われたデータパケットを検知す
るための確認応答を提供する。
ない。そのような理由から、ＴＣＰ層２１０は普通はＩＰ層２０２の上で使用さ
れる訳である。反対に、ＴＣＰプロトコルは、失われたデータパケットを検知す
るための確認応答を提供する。
【００５４】 図３は、パケットのストリーム３００と、ＴＣＰスライディングウインドウ３
１０を示している。ＴＣＰソースの主な特徴の１つは、ＴＣＰソースが、バイト
を、そしてその結果、受信者からの確認応答が受信される前に送信することので
きるＩＰパケットを確定することになるスライディングウインドウ３１０を使用
することである。これは、ソースの有効伝送速度が調整できるようにする。
１０を示している。ＴＣＰソースの主な特徴の１つは、ＴＣＰソースが、バイト
を、そしてその結果、受信者からの確認応答が受信される前に送信することので
きるＩＰパケットを確定することになるスライディングウインドウ３１０を使用
することである。これは、ソースの有効伝送速度が調整できるようにする。
【００５５】 ＴＣＰソースがスライディングウインドウ３１０のサイズを増やすときには、
その平均伝送速度も速くなる。スライディングウインドウ３１０はオクテット１
２−１９の上にある。１１までのオクテットは送信されており、スライディング
ウインドウ３１０はそれらを通り越している。スライディングウインドウ３１０
の内部にはオクテットグループ３２０、３２２がある。第１のオクテットグルー
プ３２０は、既に送信３３０された１２から１６までのオクテットである。スラ
イディングウインドウ３１０内のオクテットの第２グループ３２２は、まだ送信
されていないオクテット１７−１９である。オクテットの第２グループ３２２は
即座に送信することができる３４０。最後にオクテット２０以降３５０は、送信
され得ない３６０。オクテット１２が確認応答し、スライディングウインドウが
順方向にスライドして、始めてオクテット２０が送信できるようになる。こうし
て、ＴＣＰは、ＴＣＰスライディングウインドウ３１０を使って、失われたデー
タパケットの再伝送とフロー制御を提供する。スライディングウインドウ３１０
は、実際には、受信者により送信されるウインドウ告示の輻輳ウインドウの最小
限のものである。
その平均伝送速度も速くなる。スライディングウインドウ３１０はオクテット１
２−１９の上にある。１１までのオクテットは送信されており、スライディング
ウインドウ３１０はそれらを通り越している。スライディングウインドウ３１０
の内部にはオクテットグループ３２０、３２２がある。第１のオクテットグルー
プ３２０は、既に送信３３０された１２から１６までのオクテットである。スラ
イディングウインドウ３１０内のオクテットの第２グループ３２２は、まだ送信
されていないオクテット１７−１９である。オクテットの第２グループ３２２は
即座に送信することができる３４０。最後にオクテット２０以降３５０は、送信
され得ない３６０。オクテット１２が確認応答し、スライディングウインドウが
順方向にスライドして、始めてオクテット２０が送信できるようになる。こうし
て、ＴＣＰは、ＴＣＰスライディングウインドウ３１０を使って、失われたデー
タパケットの再伝送とフロー制御を提供する。スライディングウインドウ３１０
は、実際には、受信者により送信されるウインドウ告示の輻輳ウインドウの最小
限のものである。
【００５６】 図４はＴＣＰネットワークシステム４００を示しており、受信者４１０は、ソ
ース４３０からデータ４４０を受信するとともに、確認応答４２０をソース４３
０に提供する。受信者４１０は、ソース４３０に受信者４１０の入ってくるデー
タ４４０に対する対処能力を通知するためのウインドウ告示データ４５０も含ん
でいる、確認応答パケット４２０を送信する。こうして、受信者４１０は、フロ
ー制御の用途に適するウインドウサイズ４５０を告示することができる。実際、
ウインドウ告示４５０は、受信者４１０が、あとどれほど多くのデータのオクテ
ットを受け入れる準備ができているかを規定する。ソース４３０により保守され
ている輻輳ウインドウ４６０がそれよりも小さい場合以外は、ソース４３０はこ
の告示に従って自身のスライディングウインドウを調節することになっている。
ース４３０からデータ４４０を受信するとともに、確認応答４２０をソース４３
０に提供する。受信者４１０は、ソース４３０に受信者４１０の入ってくるデー
タ４４０に対する対処能力を通知するためのウインドウ告示データ４５０も含ん
でいる、確認応答パケット４２０を送信する。こうして、受信者４１０は、フロ
ー制御の用途に適するウインドウサイズ４５０を告示することができる。実際、
ウインドウ告示４５０は、受信者４１０が、あとどれほど多くのデータのオクテ
ットを受け入れる準備ができているかを規定する。ソース４３０により保守され
ている輻輳ウインドウ４６０がそれよりも小さい場合以外は、ソース４３０はこ
の告示に従って自身のスライディングウインドウを調節することになっている。
【００５７】 第２のウインドウ、即ち輻輳ウインドウ４６０は、スライディングウインドウ
のサイズを落すためにＴＣＰソース４３０で内部的に使用される。これはタイマ
ーが時限切れになった場合に生じ、データパッケットは送信済みだが一定時間内
に確認応答が到着していないということを教える。これはデータパケットが、最
も高い可能性としてはネットワークの輻輳により、紛失されたことを意味する。
輻輳状態を更に悪化させないために、ＴＣＰソース４３０はスライディングスウ
インドウのサイズを落すことにより伝送速度を下げる。これらウインドウの関係
は、 Ｔw＝ＭＩＮ（ウインドウ告示，輻輳ウインドウ） と表すことができ、ここにＴwは送信ウインドウ、即ちスライディングウインド
ウを指す。
のサイズを落すためにＴＣＰソース４３０で内部的に使用される。これはタイマ
ーが時限切れになった場合に生じ、データパッケットは送信済みだが一定時間内
に確認応答が到着していないということを教える。これはデータパケットが、最
も高い可能性としてはネットワークの輻輳により、紛失されたことを意味する。
輻輳状態を更に悪化させないために、ＴＣＰソース４３０はスライディングスウ
インドウのサイズを落すことにより伝送速度を下げる。これらウインドウの関係
は、 Ｔw＝ＭＩＮ（ウインドウ告示，輻輳ウインドウ） と表すことができ、ここにＴwは送信ウインドウ、即ちスライディングウインド
ウを指す。
【００５８】 原則的に、輻輳ウインドウ４６０と、下層のネットワークにより提供される告
示ウインドウ４５０に含まれているフィードバック情報とは、同じ目的、即ちネ
ットワークの負荷及び輻輳に従ってＴＣＰソース４３０の伝送速度を調節するこ
とに使用することができる。しかしながら、輻輳ウインドウ４６０と告示ウイン
ドウ４５０に含まれているフィードバック情報との間のある１つの重大な相違点
は、輻輳ウインドウ４６０が端末対端末ベースで動作し、タイムアウトが相対的
に長いせいで、通常、変更に対する反応がかなり遅いということである。このよ
うなわけで輻輳ウインドウ４６０は何れの詳細な情報を与えることもできない。
ＴＣＰソース４１０は、パケットが捨てられたことを知るのみであり、ネットワ
ークの状況について正確な全体像を与えることはしない。一方、告示ウインドウ
４５０に含まれているフィードバック情報は、より正確で、変化している状況に
対しより素早く反応する。
示ウインドウ４５０に含まれているフィードバック情報とは、同じ目的、即ちネ
ットワークの負荷及び輻輳に従ってＴＣＰソース４３０の伝送速度を調節するこ
とに使用することができる。しかしながら、輻輳ウインドウ４６０と告示ウイン
ドウ４５０に含まれているフィードバック情報との間のある１つの重大な相違点
は、輻輳ウインドウ４６０が端末対端末ベースで動作し、タイムアウトが相対的
に長いせいで、通常、変更に対する反応がかなり遅いということである。このよ
うなわけで輻輳ウインドウ４６０は何れの詳細な情報を与えることもできない。
ＴＣＰソース４１０は、パケットが捨てられたことを知るのみであり、ネットワ
ークの状況について正確な全体像を与えることはしない。一方、告示ウインドウ
４５０に含まれているフィードバック情報は、より正確で、変化している状況に
対しより素早く反応する。
【００５９】 下層のネットワークは、ＴＣＰソース４１０の伝送速度を制御するために、確
認応答パケット４２０で運ばれる受信者のウインドウ告示４５０を使うことがで
きる。これは、デバイス若しくはここでフィードバック・インフォメーション・
コンバータ（ＦＩＣ）と呼ばれるネットワーク機能性を加えることにより実現さ
れる。
認応答パケット４２０で運ばれる受信者のウインドウ告示４５０を使うことがで
きる。これは、デバイス若しくはここでフィードバック・インフォメーション・
コンバータ（ＦＩＣ）と呼ばれるネットワーク機能性を加えることにより実現さ
れる。
【００６０】 こうして、ＴＣＰはスライディングウインドウ・プロトコルを使用し、ソース
４３０は自身のウインドウサイズを、受信者４１０からの返信ＡＣＫパケット４
２０に基づいて調節する。ウインドウ４６０の成長速度はこれら返信パケット４
２０の速度に比例することになる。従って、返信ＡＣＫストリーム４２０のタイ
ミングを修正することにより、ソースウインドウ４６０が制御され得ることは自
明であろう。ＡＣＫ歩調合せ方法が依拠しているのはこの基本的原理である。厳
密には、これらの方法は、混み合ったネットワーク要素、例えばアクセスノード
及びＩＰルータなどにおいて、ソース４３０による過剰放出を制限するために、
返信ＡＣＫパケット４２０を適度に遅延させる。これが正しく行なわれた場合、
ＡＣＫ歩調合せは、ＴＣＰタイムアウトを縮小し、キューが大きくなるのを制限
し、それにより全体的な接続の良好性を向上させる。
４３０は自身のウインドウサイズを、受信者４１０からの返信ＡＣＫパケット４
２０に基づいて調節する。ウインドウ４６０の成長速度はこれら返信パケット４
２０の速度に比例することになる。従って、返信ＡＣＫストリーム４２０のタイ
ミングを修正することにより、ソースウインドウ４６０が制御され得ることは自
明であろう。ＡＣＫ歩調合せ方法が依拠しているのはこの基本的原理である。厳
密には、これらの方法は、混み合ったネットワーク要素、例えばアクセスノード
及びＩＰルータなどにおいて、ソース４３０による過剰放出を制限するために、
返信ＡＣＫパケット４２０を適度に遅延させる。これが正しく行なわれた場合、
ＡＣＫ歩調合せは、ＴＣＰタイムアウトを縮小し、キューが大きくなるのを制限
し、それにより全体的な接続の良好性を向上させる。
【００６１】 ＴＣＰトラフィックプロフィールの大きな非対称性のおかげで、ＡＣＫ歩調合
せは現実的にはＴＣＰソース側４３０にしか必要でなくなる。これは、必要とさ
れるＡＣＫ歩調合せの機能性が大規模ウェブ−サーバ／ファイル−ホストに限っ
て必要であることを示唆しているので、特筆に価すべき点である。従って、より
大規模で多様なユーザーアクセスベースにとって高価なアップグレードは不要と
なる。しかしながら、ＡＣＫ歩調合せはネットワーク内部の速度制御を良好にす
る点を強調したい。これは、本質的にネットワークをかなり一定の帯域幅にまと
め、輻輳が基本的にはアクセスノードで起きるようにする。
せは現実的にはＴＣＰソース側４３０にしか必要でなくなる。これは、必要とさ
れるＡＣＫ歩調合せの機能性が大規模ウェブ−サーバ／ファイル−ホストに限っ
て必要であることを示唆しているので、特筆に価すべき点である。従って、より
大規模で多様なユーザーアクセスベースにとって高価なアップグレードは不要と
なる。しかしながら、ＡＣＫ歩調合せはネットワーク内部の速度制御を良好にす
る点を強調したい。これは、本質的にネットワークをかなり一定の帯域幅にまと
め、輻輳が基本的にはアクセスノードで起きるようにする。
【００６２】 アドバンスドＡＴＭが持っている能力、例えばＶＢＲ−ｎｒｔ、ＡＢＲ、及び
ＧＦＲはこれらの条件を現実的に実現する。更には、高速ＩＰルータでの速度保
証が実現されることは、ＡＣＫ歩調合せに対して好ましい状況を生み出すことに
もなると期待される。
ＧＦＲはこれらの条件を現実的に実現する。更には、高速ＩＰルータでの速度保
証が実現されることは、ＡＣＫ歩調合せに対して好ましい状況を生み出すことに
もなると期待される。
【００６３】 しかしながら、先に説明したように、現在のＡＣＫ歩調合せ方法の多くは、イ
ンプリメンテーションに対して特別に修正可能であるわけではない。例えば、高
速ＴＣＰ（Ｆ−ＴＣＰ）は、順方向の下層データ「クリアリング」速度を知る必
要があった。これは、リンク能力、又はＡＴＭ利用可能ビット速度（ＡＢＲ）サ
ービスカテゴリーの場合の接続許容セル速度（ＡＣＲ）の何れかに当たる。ＡＣ
Ｋパケット４２０のための計算された遅れはこの速度に基づいている。
ンプリメンテーションに対して特別に修正可能であるわけではない。例えば、高
速ＴＣＰ（Ｆ−ＴＣＰ）は、順方向の下層データ「クリアリング」速度を知る必
要があった。これは、リンク能力、又はＡＴＭ利用可能ビット速度（ＡＢＲ）サ
ービスカテゴリーの場合の接続許容セル速度（ＡＣＲ）の何れかに当たる。ＡＣ
Ｋパケット４２０のための計算された遅れはこの速度に基づいている。
【００６４】 明らかなように、このようなスキームはより進化した情報処理方法を必要とし
ており、下層の速度が広い範囲で変動する場合には問題が生じる。更には、遠隔
のＴＣＰクライアント４１０によるＡＣＫパケット４２０の放出に遅れがある場
合には、感度の問題を生じさせ、このようなスキームの性能を著しく劣化させる
ことになりかねない。また、これらスキームは、返信ＡＣＫパケット４２０を集
積的な方法、即ち先入れ先出し（ＦＩＦＯ）方式でバッファするだけなので、明
示的な公平性規定を提供することができない。別のＡＣＫ歩調合せ方法、即ちＡ
ＣＫバケットスキームは、フロー毎状態をあまりに多く必要としすぎるので、実
質的に各ＴＣＰフローのウインドウ挙動を「追跡する」ことになる。
ており、下層の速度が広い範囲で変動する場合には問題が生じる。更には、遠隔
のＴＣＰクライアント４１０によるＡＣＫパケット４２０の放出に遅れがある場
合には、感度の問題を生じさせ、このようなスキームの性能を著しく劣化させる
ことになりかねない。また、これらスキームは、返信ＡＣＫパケット４２０を集
積的な方法、即ち先入れ先出し（ＦＩＦＯ）方式でバッファするだけなので、明
示的な公平性規定を提供することができない。別のＡＣＫ歩調合せ方法、即ちＡ
ＣＫバケットスキームは、フロー毎状態をあまりに多く必要としすぎるので、実
質的に各ＴＣＰフローのウインドウ挙動を「追跡する」ことになる。
【００６５】 図５は、本発明によるエンハンスドＡＣＫ歩調合せデバイス５００を示してい
る。ＡＣＫ歩調合せデバイス５００は、輻輳レベルを推測するに当たってはキュ
ーの長さ情報に依存するもので、追加の（高価な）タイマー機構を一切必要とし
ない。図５に示すＡＣＫ歩調合せデバイス５００は、非常に包括的であるので、
広範囲のネットワークに合うように仕立てることができる。
る。ＡＣＫ歩調合せデバイス５００は、輻輳レベルを推測するに当たってはキュ
ーの長さ情報に依存するもので、追加の（高価な）タイマー機構を一切必要とし
ない。図５に示すＡＣＫ歩調合せデバイス５００は、非常に包括的であるので、
広範囲のネットワークに合うように仕立てることができる。
【００６６】 図５にはＡＣＫ制御装置５１０が設けられている。ＡＣＫ制御装置５１０は、
オーバーロード（即ち輻輳）とアンダーロード両方の期間中、ＡＣＫスケジュー
ラ装置５２０のオペレーションと共に、ＡＣＫパケットのプロセッシングを制御
する。ＡＣＫ制御装置５１０は、下層のリンク層エンティティ５２８及びデータ
パケットバッファ５３０からの、トラフィック測定及びデータ伝送通知５２２に
依存している。輻輳期間中は、返信ＡＣＫパケット５３２は、適当な分類細分性
（集合体、クラス毎、フロー毎）を使ってＡＣＫバッファ５３４に記憶され、適
切に選定された速度でゲートアウトされる。厳密には、混み合っている期間中の
ＡＣＫパケットの放出は、バッファ５３４が妥当な時間内に空にされるように行
なわれる。輻輳が収まるとＡＣＫ放出速度は上げられ、帯域幅の利用が改善され
ることになる。ＡＣＫ制御装置５１０は、全てのケースにおいて、ＡＣＫスケジ
ューラ装置５２０を起動させてバッファ５３４内のＡＣＫパケット５２０を放出
させる点に留意されたい。
オーバーロード（即ち輻輳）とアンダーロード両方の期間中、ＡＣＫスケジュー
ラ装置５２０のオペレーションと共に、ＡＣＫパケットのプロセッシングを制御
する。ＡＣＫ制御装置５１０は、下層のリンク層エンティティ５２８及びデータ
パケットバッファ５３０からの、トラフィック測定及びデータ伝送通知５２２に
依存している。輻輳期間中は、返信ＡＣＫパケット５３２は、適当な分類細分性
（集合体、クラス毎、フロー毎）を使ってＡＣＫバッファ５３４に記憶され、適
切に選定された速度でゲートアウトされる。厳密には、混み合っている期間中の
ＡＣＫパケットの放出は、バッファ５３４が妥当な時間内に空にされるように行
なわれる。輻輳が収まるとＡＣＫ放出速度は上げられ、帯域幅の利用が改善され
ることになる。ＡＣＫ制御装置５１０は、全てのケースにおいて、ＡＣＫスケジ
ューラ装置５２０を起動させてバッファ５３４内のＡＣＫパケット５２０を放出
させる点に留意されたい。
【００６７】 ＴＣＰは拡張可能なプロトコルなので、受信者ウインドウに制限がない場合に
は常に伝送クォータを増すよう試みる。これは、大きな（嵩高な）ファイル転送
の場合に、通常のＴＣＰプロトコルは、ウインドウサイズを増大させ、パケット
を紛失し、次に速度を落す、ということを繰り返すことを意味する。システム中
のデータのボリュームが増大するにつれ、ＡＣＫパケット５３２の数も増える。
は常に伝送クォータを増すよう試みる。これは、大きな（嵩高な）ファイル転送
の場合に、通常のＴＣＰプロトコルは、ウインドウサイズを増大させ、パケット
を紛失し、次に速度を落す、ということを繰り返すことを意味する。システム中
のデータのボリュームが増大するにつれ、ＡＣＫパケット５３２の数も増える。
【００６８】 この点に、ＡＣＫ歩調合せの非常に明敏な含意がある。つまり、通常のＴＣＰ
プロトコルにおけるデータパケット５４０の成長は、ＡＣＫパケット５３２の成
長に「置き換え」られる。これはＡＣＫバッファ「ドリフト」現象と称される。
このドリフトの速度は、ゆっくりした開始体制でＴＣＰ接続とＡＣＫ歩調合せす
る場合には線形（即ち速い）となり、輻輳回避体制でＴＣＰ接続とＡＣＫ歩調合
せする場合には略線形となる。
プロトコルにおけるデータパケット５４０の成長は、ＡＣＫパケット５３２の成
長に「置き換え」られる。これはＡＣＫバッファ「ドリフト」現象と称される。
このドリフトの速度は、ゆっくりした開始体制でＴＣＰ接続とＡＣＫ歩調合せす
る場合には線形（即ち速い）となり、輻輳回避体制でＴＣＰ接続とＡＣＫ歩調合
せする場合には略線形となる。
【００６９】 この問題に取り組む方法としては２つ考えられる。より単純なアプローチとし
ては、ＡＣＫバッファ５３４にＡＣＫパケット５３２用の十分な能力を設け、Ａ
ＣＫバッファ５３４を使い果たす稀な事象においてはドロップ・フロム・フロン
ト戦略を採用することである。通常、前置きのＡＣＫ数は、到着パケット５４０
用のシーケンス数よりもシーケンス数が小さいという傾向が強い。ＡＣＫパケッ
ト５３２は小さく（４０バイト）ほとんどのファイル転送は無限ではないので、
このバッファリングアプローチは非常に合理的である。例えば、ＲＡＭの６４ｋ
ＢのＡＣＫバッファ５３４は、大凡１，７００のＡＣＫパケット５３２を保留す
ることができるが、これは１５５Ｍｂ／ｓＷＡＮリンクにとっては適量を超える
ものである。
ては、ＡＣＫバッファ５３４にＡＣＫパケット５３２用の十分な能力を設け、Ａ
ＣＫバッファ５３４を使い果たす稀な事象においてはドロップ・フロム・フロン
ト戦略を採用することである。通常、前置きのＡＣＫ数は、到着パケット５４０
用のシーケンス数よりもシーケンス数が小さいという傾向が強い。ＡＣＫパケッ
ト５３２は小さく（４０バイト）ほとんどのファイル転送は無限ではないので、
このバッファリングアプローチは非常に合理的である。例えば、ＲＡＭの６４ｋ
ＢのＡＣＫバッファ５３４は、大凡１，７００のＡＣＫパケット５３２を保留す
ることができるが、これは１５５Ｍｂ／ｓＷＡＮリンクにとっては適量を超える
ものである。
【００７０】 別のアプローチは、２つの変数を使ってＴＣＰシーケンス数を追跡する、即ち
フロー毎に後入れ後出し値を求めるということである。このアプローチでは必要
なメモリの量が小さくてすむが、ＡＣＫ数の再書き込み（即ち合計の再計算）が
必要になる。また、ＡＣＫパケット５３２が順不同に到着する場合は、特別な考
慮が必要である。更には、受信者ウインドウサイズ及びＵＲＧ／ＲＳＴフラグの
ような、ＡＣＫパケット５３２内にある他のフィールドが、非冗長情報も保有し
ているという可能性が高く、これがまた問題を複雑にしている。
フロー毎に後入れ後出し値を求めるということである。このアプローチでは必要
なメモリの量が小さくてすむが、ＡＣＫ数の再書き込み（即ち合計の再計算）が
必要になる。また、ＡＣＫパケット５３２が順不同に到着する場合は、特別な考
慮が必要である。更には、受信者ウインドウサイズ及びＵＲＧ／ＲＳＴフラグの
ような、ＡＣＫパケット５３２内にある他のフィールドが、非冗長情報も保有し
ているという可能性が高く、これがまた問題を複雑にしている。
【００７１】 こうして、ＡＣＫバッファリングのアプローチは、インプリメンテーションの
観点から実現の可能性がより高い。ＡＣＫバッファリングアプローチは、最小限
の追加的拘束条件を出すが、ＴＣＰパケット５３２の何れのフィールドもいじる
ことはない。
観点から実現の可能性がより高い。ＡＣＫバッファリングアプローチは、最小限
の追加的拘束条件を出すが、ＴＣＰパケット５３２の何れのフィールドもいじる
ことはない。
【００７２】 図５に示すように、データフローの順方向で、リンク層エンティティ５２８は
広範な下層技術の代表となる。例として、専用リンク又はＡＴＭ ＶＣ、又はＩ
Ｐフロークラスが挙げられる。更には、リンク層エンティティ５２８は、１つの
ＴＣＰフロー、例えばＡＴＭ ＶＣ等の専用であるか、又はＴＣＰフローのグル
ープ（トラフィック集合体）の中で共用されているか、の何れであってもよい。
同様に、逆方向のＡＣＫ歩調合せは、異なるレベルで行なわれる。例えば、フロ
ー毎のキューイングが順方向に実行される場合、フロー毎のＡＣＫ歩調合わせは
逆方向にも必要とされ、即ちフローデータ毎／フロー毎ＡＣＫである。
広範な下層技術の代表となる。例として、専用リンク又はＡＴＭ ＶＣ、又はＩ
Ｐフロークラスが挙げられる。更には、リンク層エンティティ５２８は、１つの
ＴＣＰフロー、例えばＡＴＭ ＶＣ等の専用であるか、又はＴＣＰフローのグル
ープ（トラフィック集合体）の中で共用されているか、の何れであってもよい。
同様に、逆方向のＡＣＫ歩調合せは、異なるレベルで行なわれる。例えば、フロ
ー毎のキューイングが順方向に実行される場合、フロー毎のＡＣＫ歩調合わせは
逆方向にも必要とされ、即ちフローデータ毎／フロー毎ＡＣＫである。
【００７３】 しかしながら、集合体又はクラスベースのＡＣＫ歩調合せが順方向に行なわれ
る場合、同じように逆方向（集合体データ／集合体ＡＣＫ、クラス毎データ／ク
ラス毎ＡＣＫ）に行なわれるのが望ましいであろう。他の場合としては、より単
純で集約的なキューイングを順方向に行い、逆方向にはより進化したフロー毎Ａ
ＣＫバッファリングを行なうように決めることもできる。このアプローチは、順
方向の高速フロー毎バッファリング及びスケジューリング技術を必要とせずに、
同一のリンク層エンティティ５３０に集約されたフロー内の公平性を改善する。
入ってくるＡＣＫパケット５３２については、依然フロー毎ＡＣＫ計算が必要で
はあるものの、それはネットワークのエッジに限られることで、そこではＡＣＫ
パケット５３２はより大きいＩＰパケットサイズに相応しいことから、処理速度
の要件も著しく緩和されている。スケジューラ割付、即ち重みを、フローのＴＣ
Ｐ最大セグメントサイズ（ＭＳＳ）に反比例するように選定することにより、よ
り小さなＭＳＳフローに対するバイアスは（ある程度まで）小さくできる。
る場合、同じように逆方向（集合体データ／集合体ＡＣＫ、クラス毎データ／ク
ラス毎ＡＣＫ）に行なわれるのが望ましいであろう。他の場合としては、より単
純で集約的なキューイングを順方向に行い、逆方向にはより進化したフロー毎Ａ
ＣＫバッファリングを行なうように決めることもできる。このアプローチは、順
方向の高速フロー毎バッファリング及びスケジューリング技術を必要とせずに、
同一のリンク層エンティティ５３０に集約されたフロー内の公平性を改善する。
入ってくるＡＣＫパケット５３２については、依然フロー毎ＡＣＫ計算が必要で
はあるものの、それはネットワークのエッジに限られることで、そこではＡＣＫ
パケット５３２はより大きいＩＰパケットサイズに相応しいことから、処理速度
の要件も著しく緩和されている。スケジューラ割付、即ち重みを、フローのＴＣ
Ｐ最大セグメントサイズ（ＭＳＳ）に反比例するように選定することにより、よ
り小さなＭＳＳフローに対するバイアスは（ある程度まで）小さくできる。
【００７４】 差別化されたサービスアーキテクチャへの標準化に対する続行中の努力には、
後者の原理がかなりうまくなじむ。つまり、フロー毎計算／オーバーヘッドは、
ネットワークのアクセス部分、即ちＡＣＫ歩調合わせが行なわれる部分に限られ
るので、バックボーン内の複雑性が低減されることになる。ほとんどのアクセス
ノードはバックボーンデバイスよりも接続数がずっと少ないので、このアプロー
チはこれから出現するネットワークにおいて実現の可能性が非常に高い。
後者の原理がかなりうまくなじむ。つまり、フロー毎計算／オーバーヘッドは、
ネットワークのアクセス部分、即ちＡＣＫ歩調合わせが行なわれる部分に限られ
るので、バックボーン内の複雑性が低減されることになる。ほとんどのアクセス
ノードはバックボーンデバイスよりも接続数がずっと少ないので、このアプロー
チはこれから出現するネットワークにおいて実現の可能性が非常に高い。
【００７５】 上記の説明に鑑みると、ＡＣＫスケジューラ５２０は、公平性を改善するため
に多様なパケットスケジューリング方法を取り入れている、かなり包括的なもの
であると規定することができる。例えば、集約（ＦＩＦＯ）ＡＣＫバッファリン
グの最も単純な形態では、スケジューラ５２０は、ヘッド・オブ・ライン（ＨＯ
Ｌ）ＡＣＫを送りさえすればよい。より進化したクラス毎又はフロー毎ＡＣＫバ
ッファリング戦略では、重みつきラウンドロビン（ＷＲＲ）又は公平キューイン
グ（ＦＱ）スケジューラが、送信に対し次に適するＡＣＫを「選定」するために
インプリメントすることができる。
に多様なパケットスケジューリング方法を取り入れている、かなり包括的なもの
であると規定することができる。例えば、集約（ＦＩＦＯ）ＡＣＫバッファリン
グの最も単純な形態では、スケジューラ５２０は、ヘッド・オブ・ライン（ＨＯ
Ｌ）ＡＣＫを送りさえすればよい。より進化したクラス毎又はフロー毎ＡＣＫバ
ッファリング戦略では、重みつきラウンドロビン（ＷＲＲ）又は公平キューイン
グ（ＦＱ）スケジューラが、送信に対し次に適するＡＣＫを「選定」するために
インプリメントすることができる。
【００７６】 ＡＣＫ制御装置５１０は、ソースに対するＡＣＫパケットの歩調合せを制御す
るためのＡＣＫ歩調合せプロセッサ５１２を含んでいる。ＡＣＫ歩調合せプロセ
ッサは、２つの主要素、つまりデータパケット出発プロセッサ５１４とＡＣＫ到
着プロセッサを含んでいる。ＡＣＫ到着プロセッサ５１６は輻輳レベルを調べ、
入ってくるＡＣＫパケットを保留すべきかどうかを決める。データパケット出発
プロセッサ５１４は、リンク層エンティティ５２８とデータパケットバッファ５
３０を介して輻輳レベルを監視し、ソースに対して何時ＡＣＫパケット５３２を
「クロック」アウトするかを決める。
るためのＡＣＫ歩調合せプロセッサ５１２を含んでいる。ＡＣＫ歩調合せプロセ
ッサは、２つの主要素、つまりデータパケット出発プロセッサ５１４とＡＣＫ到
着プロセッサを含んでいる。ＡＣＫ到着プロセッサ５１６は輻輳レベルを調べ、
入ってくるＡＣＫパケットを保留すべきかどうかを決める。データパケット出発
プロセッサ５１４は、リンク層エンティティ５２８とデータパケットバッファ５
３０を介して輻輳レベルを監視し、ソースに対して何時ＡＣＫパケット５３２を
「クロック」アウトするかを決める。
【００７７】 図６は、本発明によるＴＣＰ ＡＣＫ到着６１０及びデータ出発６６０方法の
擬似コード６００を示している。ＴＣＰ ＡＣＫ到着６１０及びデータ出発６６
０方法は、入ってくるＴＣＰ ＡＣＫパケット全てについて実行される。
擬似コード６００を示している。ＴＣＰ ＡＣＫ到着６１０及びデータ出発６６
０方法は、入ってくるＴＣＰ ＡＣＫパケット全てについて実行される。
【００７８】 図６では、キューオブジェクトがＡＣＫパケットをエンキュー／デキューする
ために存在しており、バッファされたＡＣＫパケットの数の実行計数が、例えば
ｎｕｍ＿ＡＣＫ６０４として保存されているものと仮定する。リンク層が輻輳し
ている、及び／又はＡＣＫバッファ６１２が空でないというケースでは、入って
くるＡＣＫパケットはバッファ６１４に記憶される。バッファされたＡＣＫパケ
ットはバッファに６１４保存され、データパケット出発方法６６０によってしか
適切に送り出されない。
ために存在しており、バッファされたＡＣＫパケットの数の実行計数が、例えば
ｎｕｍ＿ＡＣＫ６０４として保存されているものと仮定する。リンク層が輻輳し
ている、及び／又はＡＣＫバッファ６１２が空でないというケースでは、入って
くるＡＣＫパケットはバッファ６１４に記憶される。バッファされたＡＣＫパケ
ットはバッファに６１４保存され、データパケット出発方法６６０によってしか
適切に送り出されない。
【００７９】 先に述べたように、ＡＣＫバファリングは集合体ベース、又は図５に関連して
先に論じた、より選択的なクラス毎／フロー毎ベースで行なわれる。ＡＣＫパケ
ットが空のバッファに到着し、そこに輻輳がなければ６４０、パケットは単純に
前向きにＴＣＰソースへと送られる（即ち目に見えない通過）６４２。しかしな
がら、これがバッファされるべき最初のＡＣＫであれば６３０、ＡＣＫ放出プロ
セスを「ジャンプスタート」させるために、このＡＣＫパケットは適当な時間間
隔の後ゲートアウトされねばならない６３２。
先に論じた、より選択的なクラス毎／フロー毎ベースで行なわれる。ＡＣＫパケ
ットが空のバッファに到着し、そこに輻輳がなければ６４０、パケットは単純に
前向きにＴＣＰソースへと送られる（即ち目に見えない通過）６４２。しかしな
がら、これがバッファされるべき最初のＡＣＫであれば６３０、ＡＣＫ放出プロ
セスを「ジャンプスタート」させるために、このＡＣＫパケットは適当な時間間
隔の後ゲートアウトされねばならない６３２。
【００８０】 高価なタイマー機構への依存を回避するために、ＡＣＫパケットの放出は、リ
ンク層エンティティ内の下層のデータパケット出発プロセス６６０に関係付けら
れねばならない。即ち、輻輳期間中、ＡＣＫパケットは、すべてのα1データパ
ケットが放出されてしまった後に送られるということであり、ここにα1は（積
分）減速因数の項である。
ンク層エンティティ内の下層のデータパケット出発プロセス６６０に関係付けら
れねばならない。即ち、輻輳期間中、ＡＣＫパケットは、すべてのα1データパ
ケットが放出されてしまった後に送られるということであり、ここにα1は（積
分）減速因数の項である。
【００８１】 インプリメンテーションの観点から、上記機能性は、単純なカウンタ変数、例
えばｐｋｔ＿ｃｏｕｎｔｅｒ６４４を使うことによりみごとに実現され得る。１
番目のＡＣＫパケットについては、カウンタ変数値はα1にセットされ、データ
出発プロセス６６０に従って、データパケット出発毎に減分される。カウンタ変
数値がゼロになると、バッファされたＡＣＫパケットがリリースされ、カウンタ
はリセットされる。
えばｐｋｔ＿ｃｏｕｎｔｅｒ６４４を使うことによりみごとに実現され得る。１
番目のＡＣＫパケットについては、カウンタ変数値はα1にセットされ、データ
出発プロセス６６０に従って、データパケット出発毎に減分される。カウンタ変
数値がゼロになると、バッファされたＡＣＫパケットがリリースされ、カウンタ
はリセットされる。
【００８２】 予想に反して、与えられたα1の値はＴＣＰソースが等しい度数で減速するこ
とを示唆していない。ここで、問題は、緩慢なスタート／輻輳回避体制、及び「
ＡＣＫの他の全ての特性」並びに遅延ＡＣＫタイマー等、のようなＴＣＰプロト
コルの多くの特性により複雑になる。例えば、至る所に存在する「ＡＣＫの他の
全ての」特性が使用可能になっている、無限なソースがフルサイズのセグメント
を送信するという理想的なケースでは、ＴＣＰソースを抑制するにはα1＞３が
必要となることが分かる。代わりに、ＴＣＰソースの端末システムの挙動が未知
の場合、キューの長さ制御を「保証する」ために、非常に大きなα1値が使用さ
れる。換言すると、このような値は、輻輳が収まるまでは実質的に全てのＡＣＫ
の放出を禁じる（即ちオン／オフ型制御）が、大抵はキュー振動が増加する。
とを示唆していない。ここで、問題は、緩慢なスタート／輻輳回避体制、及び「
ＡＣＫの他の全ての特性」並びに遅延ＡＣＫタイマー等、のようなＴＣＰプロト
コルの多くの特性により複雑になる。例えば、至る所に存在する「ＡＣＫの他の
全ての」特性が使用可能になっている、無限なソースがフルサイズのセグメント
を送信するという理想的なケースでは、ＴＣＰソースを抑制するにはα1＞３が
必要となることが分かる。代わりに、ＴＣＰソースの端末システムの挙動が未知
の場合、キューの長さ制御を「保証する」ために、非常に大きなα1値が使用さ
れる。換言すると、このような値は、輻輳が収まるまでは実質的に全てのＡＣＫ
の放出を禁じる（即ちオン／オフ型制御）が、大抵はキュー振動が増加する。
【００８３】 包括的でより柔軟性のある仕様を提示するために、図６の擬似コードは輻輳検
知方法を明示的には指定しない点に着目されたい。厳密には、ｃｏｎｇｅｓｔｉ
ｏｎ＿ｓｔａｔｕｓ（）ルーチン６２０は、単にブール値を戻してリンク層エン
ティティが輻輳しているかどうかを表示するだけである。多種多様な輻輳表示機
構がここで使用できることは明らかである。キュー長、平均キュー長、入力速度
オーバーロード測定、及びデータ紛失速度を例として挙げることができる。しか
しながら、インプリメンテーションの複雑性を簡素にするために、キュー長を使
用するのが望ましい。
知方法を明示的には指定しない点に着目されたい。厳密には、ｃｏｎｇｅｓｔｉ
ｏｎ＿ｓｔａｔｕｓ（）ルーチン６２０は、単にブール値を戻してリンク層エン
ティティが輻輳しているかどうかを表示するだけである。多種多様な輻輳表示機
構がここで使用できることは明らかである。キュー長、平均キュー長、入力速度
オーバーロード測定、及びデータ紛失速度を例として挙げることができる。しか
しながら、インプリメンテーションの複雑性を簡素にするために、キュー長を使
用するのが望ましい。
【００８４】 ２つのヒステリシスキュー閾値、ＱＬ７１０とＱＨ７１４を使ったサンプル方
法７００の擬似コードを図７に示す。図７では、輻輳状態が調べられ、バイナリ
フラグが戻される７０２。ヒステリシスキュー閾値ＱＬ７１０とＱＨ７１２が使
用される７２０。輻輳が存在してキューの長さがＱＬよりも小さい場合７２２、
輻輳が収まる状態変化は、フラグを第１状態、即ちｃｏｎｇｅｓｔｅｄ＿ｆｌａ
ｇ＝ＯＦＦにセットする７２４ことにより記憶される。代わりに、輻輳は存在せ
ずキューの長さがＱＨよりも大きい場合７３０、輻輳開始の状態変化は、フラグ
を第２状態、即ちｃｏｎｇｅｓｔｅｄ＿ｆｌａｇ＝ＯＮにセットする７３２こと
により記憶される。次にバイナリフラグの状態は戻される７４０。
法７００の擬似コードを図７に示す。図７では、輻輳状態が調べられ、バイナリ
フラグが戻される７０２。ヒステリシスキュー閾値ＱＬ７１０とＱＨ７１２が使
用される７２０。輻輳が存在してキューの長さがＱＬよりも小さい場合７２２、
輻輳が収まる状態変化は、フラグを第１状態、即ちｃｏｎｇｅｓｔｅｄ＿ｆｌａ
ｇ＝ＯＦＦにセットする７２４ことにより記憶される。代わりに、輻輳は存在せ
ずキューの長さがＱＨよりも大きい場合７３０、輻輳開始の状態変化は、フラグ
を第２状態、即ちｃｏｎｇｅｓｔｅｄ＿ｆｌａｇ＝ＯＮにセットする７３２こと
により記憶される。次にバイナリフラグの状態は戻される７４０。
【００８５】 結果は、これらの閾値７１０、７２０がソースとアクセスノード間の往復にか
かる遅れ（アクセス・ネットワーク・ディレイ）に基づいて適切にサイズ合わせ
されている場合、ほとんどロスの無い性能が実現できることを示している。この
ような遅れは、ＷＡＮネットワークに見られる端末対端末の遅れよりも何倍も小
さいのが普通であるので、バッファリング要件におけるサイズ合わせ可能な縮小
は、本発明のＡＣＫ歩調合せスキームで可能となる。
かる遅れ（アクセス・ネットワーク・ディレイ）に基づいて適切にサイズ合わせ
されている場合、ほとんどロスの無い性能が実現できることを示している。この
ような遅れは、ＷＡＮネットワークに見られる端末対端末の遅れよりも何倍も小
さいのが普通であるので、バッファリング要件におけるサイズ合わせ可能な縮小
は、本発明のＡＣＫ歩調合せスキームで可能となる。
【００８６】 ここで再度図６を参照すると、データパケット出発方法６６０は、パケットが
リンク層を出発するときはいつでも実行される。目標は、記憶されているＡＣＫ
パケットを適時にリリースし、それにより、アクセスノードのリンク層バッファ
の輻輳レベル（キュー）を適切に制御する、即ちパケット紛失を最小限にするこ
とである。本方法はまず、送信を待っているバッファされたＡＣＫパケットがあ
るかどうか６６２、及びＡＣＫ放出カウンタ、即ちｐｋｔ＿ｃｏｕｎｔｅｒがゼ
ロになっているかどうか６６４を調べる。そうである場合、バッファされたＡＣ
Ｋパケットはソースにリリース６７０される。
リンク層を出発するときはいつでも実行される。目標は、記憶されているＡＣＫ
パケットを適時にリリースし、それにより、アクセスノードのリンク層バッファ
の輻輳レベル（キュー）を適切に制御する、即ちパケット紛失を最小限にするこ
とである。本方法はまず、送信を待っているバッファされたＡＣＫパケットがあ
るかどうか６６２、及びＡＣＫ放出カウンタ、即ちｐｋｔ＿ｃｏｕｎｔｅｒがゼ
ロになっているかどうか６６４を調べる。そうである場合、バッファされたＡＣ
Ｋパケットはソースにリリース６７０される。
【００８７】 この後、輻輳が依然存在するのであれば６８０、ＡＣＫパケット内スペーシン
グは、ｐｋ＿ｃｏｕｎｔｅｒをα1にリセットすることによりα1データパケット
毎に１に維持される６８２。これにより、データリンク層内のデータバッファを
更に排出することができる。しかしながら、輻輳が緩和していれば６８４、ＡＣ
Ｋパケット内スペーシングはα2データパケットまで下げられ６８６、ソースが
より速く送信できるようにする。α2パラメータは積分の加速因数の項であり、
必ずα1＞α2である。カウンタがゼロでなければ６８８、それは単に減分される
だけである６９０。しかしながら、輻輳期間の後に帯域幅が十分に使用されなく
なるのを防止するために、カウンタがα2よりも大きい場合、単にα2にリセット
されるだけ（例えば、α2値がより大きい場合は特にそうである）である。
グは、ｐｋ＿ｃｏｕｎｔｅｒをα1にリセットすることによりα1データパケット
毎に１に維持される６８２。これにより、データリンク層内のデータバッファを
更に排出することができる。しかしながら、輻輳が緩和していれば６８４、ＡＣ
Ｋパケット内スペーシングはα2データパケットまで下げられ６８６、ソースが
より速く送信できるようにする。α2パラメータは積分の加速因数の項であり、
必ずα1＞α2である。カウンタがゼロでなければ６８８、それは単に減分される
だけである６９０。しかしながら、輻輳期間の後に帯域幅が十分に使用されなく
なるのを防止するために、カウンタがα2よりも大きい場合、単にα2にリセット
されるだけ（例えば、α2値がより大きい場合は特にそうである）である。
【００８８】 ここでも、ＴＣＰの特性により生じる複雑性のせいで、α2＝１値であっても
ＴＣＰソース速度が下層のリンクエンティティ速度に（大凡）等しいということ
ではない。より厳密には「ＡＣＫの他の全ての」特性による理想的な条件に対し
ては、α2＝２という値の方が良好に機能する。
ＴＣＰソース速度が下層のリンクエンティティ速度に（大凡）等しいということ
ではない。より厳密には「ＡＣＫの他の全ての」特性による理想的な条件に対し
ては、α2＝２という値の方が良好に機能する。
【００８９】 図５に戻るが、適格なＡＣＫパケット５３２は、ＡＣＫスケジューラ５２０に
より使用されているキューイング戦略に基づいて選定される。この機構全体は、
記憶されているＡＣＫパケット５３２をリリースするに当たり、先行技術による
方法において必要とされた高価なタイマー機構を必要としない。
より使用されているキューイング戦略に基づいて選定される。この機構全体は、
記憶されているＡＣＫパケット５３２をリリースするに当たり、先行技術による
方法において必要とされた高価なタイマー機構を必要としない。
【００９０】 図８は、本発明による、エンハンスドＴＣＰ ＡＣＫ到着８１０とＡＴＭセル
出発８６０方法に関する擬似コード８００を示している。ＴＣＰ ＡＣＫ到着プ
ロセス８１０において、リンク層エンティティは輻輳しているか否か、又はＡＣ
Ｋバッファが空でないか否かについて判定が行われる８１２。リンク層エンティ
ティが輻輳しておりＡＣＫバッファが空でなければ８１４、入ってくるＡＣＫは
キューに記憶（ＦＩＦＯ、クラス毎又はフロー毎）される８１６。ＡＣＫパケッ
トは各ＡＣＫキューの末尾に記憶され、ＡＣＫカウントは増分される８１８。次
に、ＡＣＫパケットはバッファされる最初のＡＣＫパケットか否かを判定するた
めにチェックが行われる８２０。これが、バッファされるべき１番目のＡＣＫパ
ケットであれば８２２、カウンタがより大きなスペーシングにセットされるよう
に、セルカウンタはα1 *パケットセルにセットされる８２４。そうでない場合８
２６、ＡＣＫパケットはＴＣＰソースに送られる８２８。
出発８６０方法に関する擬似コード８００を示している。ＴＣＰ ＡＣＫ到着プ
ロセス８１０において、リンク層エンティティは輻輳しているか否か、又はＡＣ
Ｋバッファが空でないか否かについて判定が行われる８１２。リンク層エンティ
ティが輻輳しておりＡＣＫバッファが空でなければ８１４、入ってくるＡＣＫは
キューに記憶（ＦＩＦＯ、クラス毎又はフロー毎）される８１６。ＡＣＫパケッ
トは各ＡＣＫキューの末尾に記憶され、ＡＣＫカウントは増分される８１８。次
に、ＡＣＫパケットはバッファされる最初のＡＣＫパケットか否かを判定するた
めにチェックが行われる８２０。これが、バッファされるべき１番目のＡＣＫパ
ケットであれば８２２、カウンタがより大きなスペーシングにセットされるよう
に、セルカウンタはα1 *パケットセルにセットされる８２４。そうでない場合８
２６、ＡＣＫパケットはＴＣＰソースに送られる８２８。
【００９１】 ＡＴＭセル出発プロセス８６０において、ＡＣＫバッファが空でないか否か、
即ち送信されるべきＡＣＫパケットはあるかどうかについて判定が下される８６
２。送信されるべきＡＣＫパケットがあれば８６４、スケジューラは、次に適格
なＡＣＫパケットを確定する８７２。次に適格なＡＣＫパケットは、適格なＡＣ
Ｋキューの先頭から外され８７２、ＴＣＰソースに送られる８７４。ＡＣＫカウ
ントは減分され８７６、セルカウンタは然るべくリセットされる８８０。輻輳が
存在すれば８８２、スペーシングを増加させるためにセルカウンタはα1 *パケッ
トセルにセットされる８８４。そうでない場合８８６、スペーシングを減少させ
るためにセルカウンタはα2 *パケットセルにセットされる８８８。
即ち送信されるべきＡＣＫパケットはあるかどうかについて判定が下される８６
２。送信されるべきＡＣＫパケットがあれば８６４、スケジューラは、次に適格
なＡＣＫパケットを確定する８７２。次に適格なＡＣＫパケットは、適格なＡＣ
Ｋキューの先頭から外され８７２、ＴＣＰソースに送られる８７４。ＡＣＫカウ
ントは減分され８７６、セルカウンタは然るべくリセットされる８８０。輻輳が
存在すれば８８２、スペーシングを増加させるためにセルカウンタはα1 *パケッ
トセルにセットされる８８４。そうでない場合８８６、スペーシングを減少させ
るためにセルカウンタはα2 *パケットセルにセットされる８８８。
【００９２】 セルカウンタがゼロでなければ８９０、輻輳が緩和されたか否かについて判定
が下される８９２。輻輳が収まっておりセルカウンタ値がα2 *パケットセルより
も大きければ８９４、セルカウンタはα2 *パケットセルに等しくセットされる８
９５。そうでなければ８９６、セルカウンタは減分される８９８。
が下される８９２。輻輳が収まっておりセルカウンタ値がα2 *パケットセルより
も大きければ８９４、セルカウンタはα2 *パケットセルに等しくセットされる８
９５。そうでなければ８９６、セルカウンタは減分される８９８。
【００９３】 仮に上述のパケット取り扱い方法は非常に一般的であるとしても、より小さい
パケット（セル）サイズを使用するＡＴＭネットワークの場合には、より多くの
柔軟性が存在する。厳密には、データ（関数）パケット放出毎にＡＣＫ放出を実
行することが可能であると同時に、高価なタイマー機構の使用を避ける道を見つ
けることが可能となり、つまりはカウンタはここではパケットではなくセルによ
る（セルカウンタ）ものとなる。セルサイズは、通常ＴＣＰ ＭＳＳサイズのパ
ケットよりもずっと小さいので、パケットはより細かく時間を細分化して放出す
ることができる。即ち、パケットを基礎としたスキームの場合にはそうであった
が、α1とα2の因数はもはや整数でなくともよいということである。定数値、ｐ
ａｃｋｅｔ＿ｃｅｌｌ、即ち（ＩＰ）ＴＣＰ ＭＳＳのセルの数を、 数式（１）
と考えよう。
パケット（セル）サイズを使用するＡＴＭネットワークの場合には、より多くの
柔軟性が存在する。厳密には、データ（関数）パケット放出毎にＡＣＫ放出を実
行することが可能であると同時に、高価なタイマー機構の使用を避ける道を見つ
けることが可能となり、つまりはカウンタはここではパケットではなくセルによ
る（セルカウンタ）ものとなる。セルサイズは、通常ＴＣＰ ＭＳＳサイズのパ
ケットよりもずっと小さいので、パケットはより細かく時間を細分化して放出す
ることができる。即ち、パケットを基礎としたスキームの場合にはそうであった
が、α1とα2の因数はもはや整数でなくともよいということである。定数値、ｐ
ａｃｋｅｔ＿ｃｅｌｌ、即ち（ＩＰ）ＴＣＰ ＭＳＳのセルの数を、 数式（１）
と考えよう。
【００９４】 再度図５に戻るが、輻輳中、ＡＣＫパケット５３２は、全てのα1 *ｐａｃｋｅ
ｔ＿ｃｅｌｌｓの後で、且つα2 *ｐａｃｋｅｔ＿ｃｅｌｌｓのロード中に放出さ
れる。かなりの部分まで、ＡＣＫ到着及びセル出発方法は、パケットベースの相
当物と同一である。例えば、全てのセルの放出の後、セルカウンタが減分されゼ
ロになると、バッファ５３４内のＡＣＫパケット５３２が、ＡＣＫスケジューラ
５２０によりリリースされる。ＡＣＫバッファ５３４が空になっている間、カウ
ンタ値は然るべくリセットされる。
ｔ＿ｃｅｌｌｓの後で、且つα2 *ｐａｃｋｅｔ＿ｃｅｌｌｓのロード中に放出さ
れる。かなりの部分まで、ＡＣＫ到着及びセル出発方法は、パケットベースの相
当物と同一である。例えば、全てのセルの放出の後、セルカウンタが減分されゼ
ロになると、バッファ５３４内のＡＣＫパケット５３２が、ＡＣＫスケジューラ
５２０によりリリースされる。ＡＣＫバッファ５３４が空になっている間、カウ
ンタ値は然るべくリセットされる。
【００９５】 要約すると、ＡＴＭネットワーク上のＴＣＰプロトコルの性能は重要な領域で
ある。最近では、より進化した下層のＡＴＭトランスポートカテゴリ（例：ＡＢ
Ｒフロー制御、接続毎キューイング）とのＴＣＰの会話を改善するために種々の
ＡＣＫ歩調合せスキームが提示されている。しかしながら、これらのスキームは
パラメータの感度問題に悩まされており、実際には実現が困難であると考えられ
る。従って、広範なネットワークシナリオにおいて実行可能なエンハンスドＡＣ
Ｋ歩調合せを開示したわけである。本スキームは（より直接的な）キュー長輻輳
情報を使ってＴＣＰ ＡＣＫパケットを遅らせるので、広い範囲にわたって公平
性の判定基準をインプリメントできる。本方法は端末対端末ＴＣＰ処理能力及び
帯域幅公平性を改善する強力な手段を提供する。アクセスノードにおけるバッフ
ァリング要件も広範なサブネットワークに備えているので意義深い。
ある。最近では、より進化した下層のＡＴＭトランスポートカテゴリ（例：ＡＢ
Ｒフロー制御、接続毎キューイング）とのＴＣＰの会話を改善するために種々の
ＡＣＫ歩調合せスキームが提示されている。しかしながら、これらのスキームは
パラメータの感度問題に悩まされており、実際には実現が困難であると考えられ
る。従って、広範なネットワークシナリオにおいて実行可能なエンハンスドＡＣ
Ｋ歩調合せを開示したわけである。本スキームは（より直接的な）キュー長輻輳
情報を使ってＴＣＰ ＡＣＫパケットを遅らせるので、広い範囲にわたって公平
性の判定基準をインプリメントできる。本方法は端末対端末ＴＣＰ処理能力及び
帯域幅公平性を改善する強力な手段を提供する。アクセスノードにおけるバッフ
ァリング要件も広範なサブネットワークに備えているので意義深い。
【００９６】 本発明の代表的な実施例についての上記記述は説明と記述を目的として提示し
たものである。上記説明は、本発明を網羅しようとしたり開示された厳密な形態
に限定することを意図するものではない。上記教示に鑑み、多くの修正及び変更
が可能であろう。本発明の範囲は、この詳細な説明によってではなく、請求項目
によって限定されるものである。
たものである。上記説明は、本発明を網羅しようとしたり開示された厳密な形態
に限定することを意図するものではない。上記教示に鑑み、多くの修正及び変更
が可能であろう。本発明の範囲は、この詳細な説明によってではなく、請求項目
によって限定されるものである。
【図１】 ７つの層を含んでいるＯＳＩモデルを示す図である。
【図２】 インターネット・プロトコル・ネットワーク層とＯＳＩ７層モデルとの比較を
示す図である。
示す図である。
【図３】 パケットストリーム及びＴＣＰスライディングウインドウを示す図である。
【図４】 受信者がソースからデータを受信するとともに確認応答をソースに提供するネ
ットワークシステムを示す図である。
ットワークシステムを示す図である。
【図５】 本発明によるエンハンスドＡＣＫ歩調合せデバイスの図である。
【図６】 本発明によるＴＣＰ ＡＣＫ到着及びデータ出発６６０方法の擬似コードを示
す図である。
す図である。
【図７】 ２つのヒステリシスキュー閾値、ＱＬとＱＨを使った輻輳状態方法の擬似コー
ドを示す図である。
ドを示す図である。
【図８】 本発明によるエンハンスドＴＣＰ ＡＣＫ到着及びＡＴＭセル出発方法の擬似
コードを示す図である。
コードを示す図である。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ， ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，Ｓ Ｌ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5K030 HA08 KA03 LA02 LC01 LC11 【要約の続き】 いる、確認応答制御装置（５１０）から受信した確認応 答パケット（５３２）を記憶するための確認応答パケッ トバッファ（５３４）と、前記確認応答制御装置（５１ ０）及び確認応答パケットバッファ（５３４）に連結さ れている、前記確認応答制御装置（５１０）により生成 された制御信号に基づいて確認応答パケット（５３２） をソース（５４０）にリリースするスケジューラ（５２ ０）を更に含んでいる。
Claims (76)
- 【請求項１】 ソースからのデータパケットの受信に応えてソースに送信さ
れるべき確認応答パケットを歩調合せするための確認応答歩調合せデバイスにお
いて、 ネットワークのローディングを監視し、前記ネットワークのローディングに基
づいて確認応答パケットのプロセッシングを制御するための制御信号を生成する
ための確認応答制御装置と、 前記確認応答制御装置に連結されており、前記確認応答制御装置から受信した
確認応答パケットを記憶するための確認応答パケットバッファと、 前記確認応答制御装置及び前記確認応答パケットバッファに連結されており、
前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットを
リリースするスケジューラと、を備えていることを特徴とする確認応答歩調合せ
デバイス。 - 【請求項２】 前記スケジューラは、キューイング戦略に基づいて、リリー
スする確認応答パケットを選定することを特徴とする請求項１に記載の確認応答
歩調合せデバイス。 - 【請求項３】 前記キューイング戦略は、集合体確認応答パケットバッファ
リングが使用される場合、ヘッド・オブ・ライン確認応答パケットを送信する段
階を含んでいることを特徴とする請求項２に記載の確認応答歩調合せデバイス。 - 【請求項４】 前記キューイング戦略は、クラス毎又はフロー毎確認応答パ
ケットバッファリングが使用される場合、リリースに向けて確認応答パケットバ
ッファ内の確認応答パケットを選択するための加重ラウンドロビン（ＷＲＲ）プ
ロセスを含んでいることを特徴とする請求項２に記載の確認応答歩調合せデバイ
ス。 - 【請求項５】 前記加重ラウンドロビン（ＷＲＲ）プロスセは、より小さい
最大セグメントサイズ（ＭＳＳ）フローに対するバイアスを小さくするために、
リリースに向けて、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例して、確認
応答パケットの選択に重み付けするために重みを使用することを特徴とする請求
項４に記載の確認応答歩調合せデバイス。 - 【請求項６】 前記キューイング戦略は、クラス毎又はフロー毎確認応答パ
ケットバッファリングが使用される場合、リリースに向けて確認応答パケットバ
ッファ内の確認応答パケットを選択するための公平キューイング（ＦＱ）プロセ
スを含んでいることを特徴とする請求項２に記載の確認応答歩調合せデバイス。 - 【請求項７】 前記確認応答制御装置は、確認応答パケット到着プロセッサ
とデータパケット出発プロセッサを使って確認応答パケットのプロセッシングを
制御するための信号を生成する確認応答パケット歩調合せプロセッサを更に備え
ていることを特徴とする請求項１に記載の確認応答歩調合せデバイス。 - 【請求項８】 前記確認応答パケット到着プロセッサは、ネットワークの輻
輳レベルをチェックし、確認応答パケットを確認応答パケットバッファに保留す
べきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確
認応答パケットを直接ソースに送るべきかを決めることにより、確認応答パケッ
トバッファに対する確認応答パケットのプロセッシングを制御することを特徴と
する請求項７に記載の確認応答歩調合せデバイス。 - 【請求項９】 前記確認応答パケット到着プロセッサは、ネットワークが輻
輳しているかどうかを判定し、確認応答パケットバッファが空であるかどうかを
判定し、ネットワークが輻輳しているか、又は確認応答パケットバッファが空で
なければ、確認応答パケットをバッファに記憶し、確認応答パケットバッファが
空でありネットワークが輻輳していなければ、確認応答パケットをソースに送る
ことにより、確認応答パケットを確認応答パケットバッファに保留すべきか、又
は確認応答パケットを確認応答パケットバッファにバッファせずに確認応答パケ
ットを直接ソースに送るべきかを決めることを特徴とする請求項７に記載の確認
応答歩調合せデバイス。 - 【請求項１０】 前記確認応答パケットは、確認応答パケットが輻輳中に確
認応答パケットバッファ内にバッファされるべき１番目のパケットである場合に
は、確認応答パケットバッファに記憶され、前記スケジューラによりゲートアウ
トされることを特徴とする請求項９に記載の確認応答歩調合せデバイス。 - 【請求項１１】 前記確認応答制御装置は、確認応答パケットが輻輳中に確
認応答パケットバッファ内にバッファされるべき１番目の確認応答パケットであ
る場合には、確認応答パケットバッファからゲートされる確認応答パケット相互
間のスペーシングを増加させることを特徴とする請求項１０に記載の確認応答歩
調合せデバイス。 - 【請求項１２】 前記確認応答制御装置は、パケットカウンタ変数を第１の
所定値にセットすることにより、確認応答パケット相互間のスペーシングを増加
させることを特徴とする請求項１１に記載の確認応答歩調合せデバイス。 - 【請求項１３】 前記パケットカウンタ変数は、データパケットがネットワ
ークを出発する際に減分されることを特徴とする請求項１２に記載の確認応答歩
調合せデバイス。 - 【請求項１４】 前記スケジューラは、パケットカウンタ変数が減分されて
ゼロになったらバッファされている確認応答パケットをリリースし、そうすると
確認応答制御装置がパケットカウンタ変数をリセットすることを特徴とする請求
項１３に記載の確認応答歩調合せデバイス。 - 【請求項１５】 ネットワークの前記輻輳レベルは、データパケットバッフ
ァの容量を表すキュー長を分析することにより求められることを特徴とする請求
項８に記載の確認応答歩調合せデバイス。 - 【請求項１６】 前記ネットワークは、前記キュー長が低い閾値よりも小さ
い場合には輻輳していないとして表示されることを特徴とする請求項１５に記載
の確認応答歩調合せデバイス。 - 【請求項１７】 前記ネットワークは、前記キュー長が高い閾値よりも大き
い場合には輻輳しているとして表示されることを特徴とする請求項１５に記載の
確認応答歩調合せデバイス。 - 【請求項１８】 前記データパケット出発プロセッサは、ネットワークの輻
輳レベルを監視し、確認応答パケットを確認応答パケットバッファからソースへ
何時ゲートさせるかを決めることにより、確認応答パケットバッファからの確認
応答パケットのリリースを制御することを特徴とする請求項７に記載の確認応答
歩調合せデバイス。 - 【請求項１９】 前記データパケット出発プロセッサは、確認応答パケット
が送信を待ちながら確認応答パケットバッファ内に在るか否か、並びに確認応答
制御装置によりセットされたパケットカウンタ変数がゼロの値を有しているか否
かをチェックし、パケットカウンタ変数がゼロの値を有しているときに確認応答
パケットバッファ内のバッファされた確認応答パケットをソースにリリースする
ことにより、確認応答パケットを確認応答パケットバッファからソースへ何時ゲ
ートさせるかを決めることを特徴とする請求項１８に記載の確認応答歩調合せデ
バイス。 - 【請求項２０】 前記データパケット出発プロセッサは、ネットワーク内に
依然として輻輳が存在している場合、確認応答パケットバッファからの確認応答
パケットのリリースの間のスペーシングを増やすことを特徴とする請求項１９に
記載の確認応答歩調合せデバイス。 - 【請求項２１】 確認応答パケットのリリースの間の前記スペーシングは、
パケットカウンタ変数を第１の所定値にリセットすることにより増やされること
を特徴とする請求項２０に記載の確認応答歩調合せデバイス。 - 【請求項２２】 前記データパケット出発プロセッサは、パケットカウンタ
変数がゼロでない場合、パケットカウンタ変数を減分することを特徴とする請求
項２１に記載の確認応答歩調合せデバイス。 - 【請求項２３】 前記データパケット出発プロセッサは、パケットカウンタ
変数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方
を防止するために、パケットカウンタ変数を第２の所定値にリセットすることを
特徴とする請求項２２に記載の確認応答歩調合せデバイス。 - 【請求項２４】 前記データパケット出発プロセッサは、ネットワーク内の
輻輳が収まっている場合、確認応答パケットバッファからの確認応答パケットの
リリースの間のスペーシングを減少させることを特徴とする請求項１９に記載の
確認応答歩調合せデバイス。 - 【請求項２５】 前記データパケット出発プロセッサは、パケットカウンタ
変数を第１の所定値よりも小さい第２の所定値にリセットすることにより、確認
応答パケットのリリースの間のスペーシングを減少させることを特徴とする請求
項２４に記載の確認応答歩調合せデバイス。 - 【請求項２６】 前記データパケット出発プロセッサは、パケットカウンタ
変数の値がゼロでない場合、パケットカウンタ変数を減分することを特徴とする
請求項２５に記載の確認応答歩調合せデバイス。 - 【請求項２７】 前記データパケット出発プロセッサは、パケットカウンタ
変数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方
を防止するために、パケットカウンタ変数を第２の所定値にリセットすることを
特徴とする請求項２６に記載の確認応答歩調合せデバイス。 - 【請求項２８】 ネットワークの前記輻輳レベルは、データパケットバッフ
ァの容量を表すキュー長を分析することにより求められることを特徴とする請求
項１９に記載の確認応答歩調合せデバイス。 - 【請求項２９】 前記ネットワークは、前記キュー長が低い閾値よりも小さ
い場合には輻輳していないとして表示されることを特徴とする請求項２８に記載
の確認応答歩調合せデバイス。 - 【請求項３０】 前記ネットワークは、前記キュー長が高い閾値よりも大き
い場合には輻輳しているとして表示されることを特徴とする請求項２８に記載の
確認応答歩調合せデバイス。 - 【請求項３１】 前記確認応答パケットバッファは、確認応答パケットを集
合体ベースでバッファすることを特徴とする請求項１に記載の確認応答歩調合せ
デバイス。 - 【請求項３２】 前記確認応答パケットバッファは、フロータイプにより確
認応答パケットをバッファし、前記スケジューラは、バッファされた確認応答パ
ケットに関するフローのタイプを考慮に入れて確認応答バッファ内の確認応答パ
ケットをリリースすることを特徴とする請求項１に記載の確認応答歩調合せデバ
イス。 - 【請求項３３】 アクセスノード・デバイスにおいて、 データパケットをソースから受信し、そのデータパケットを順方向データリン
クに送るためのリンク層エンティティであって、データパケットがリンク層エン
ティティを出発して順方向のデータリンクへと送られるまで受信されたデータパ
ケットをデータパケットバッファに記憶するリンク層エンティティと、 前記リンク層エンティティに連結されている、ソースからのデータパケットの
受信に応えてソースに送信されるべき確認応答パケットを歩調合せするための確
認応答歩調合せデバイスとを備えており、前記確認応答歩調合せデバイスが、 前記リンク層エンティティの輻輳を監視し、前記リンク層エンティティに輻輳
が起きているか否かに基づいて確認応答パケットのプロセッシングを制御するた
めの信号を生成するための確認応答制御装置と、 前記確認応答制御装置に連結されている、前記確認応答制御装置から受信した
確認応答パケットを記憶するための確認応答パケットバッファと、 前記確認応答制御装置及び前記確認応答パケットバッファに連結されている、
前記確認応答制御装置により生成された制御信号に基づいて確認応答パケットを
リリースするスケジューラとを更に備えていることを特徴とするアクセスノード
・デバイス。 - 【請求項３４】 前記スケジューラは、キューイング戦略に基づいてリリー
スする確認応答パケットを選定することを特徴とする請求項３３に記載のアクセ
スノード・デバイス。 - 【請求項３５】 前記キューイング戦略は、集合体確認応答パケットバッフ
ァリングが使用される場合、ヘッド・オブ・ライン確認応答パケットを送信する
段階を含んでいることを特徴とする請求項３４に記載のアクセスノード・デバイ
ス。 - 【請求項３６】 前記キューイング戦略は、クラス毎又はフロー毎確認応答
パケットバッファリングが使用される場合、リリースに向けて確認応答パケット
バッファ内の確認応答パケットを選択するための加重ラウンドロビン（ＷＲＲ）
プロセスを含んでいることを特徴とする請求項３４に記載のアクセスノード・デ
バイス。 - 【請求項３７】 前記加重ラウンドロビン（ＷＲＲ）プロスセは、より小さ
い最大セグメントサイズ（ＭＳＳ）フローに対するバイアスを小さくするため、
リリースに向けて、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例して、確認
応答パケットの選択に重み付けするために重みを使用することを特徴とする請求
項３６に記載のアクセスノード・デバイス。 - 【請求項３８】 前記キューイング戦略は、クラス毎又はフロー毎確認応答
パケットバッファリングが使用される場合、リリースに向けて確認応答パケット
バッファ内の確認応答パケットを選択するための公平キューイング（ＦＱ）プロ
セスを含んでいることを特徴とする請求項３４に記載のアクセスノード・デバイ
ス。 - 【請求項３９】 前記確認応答制御装置は、確認応答パケット到着プロセッ
サとデータパケット出発プロセッサとを使って、確認応答パケットのプロセッシ
ングを制御するための制御信号を生成する確認応答パケット歩調合せプロセッサ
を更に備えていることを特徴とする請求項３３に記載のアクセスノード・デバイ
ス。 - 【請求項４０】 前記確認応答パケット到着プロセッサは、リンク層エンテ
ィティの輻輳をチェックし、確認応答パケットを確認応答パケットバッファに保
留すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせず
に確認応答パケットを直接ソースに送るべきかを決めることにより、確認応答パ
ケットバッファに対する確認応答パケットのプロセッシングを制御することを特
徴とする請求項３９に記載のアクセスノード・デバイス。 - 【請求項４１】 前記確認応答パケット到着プロセッサが、リンク層エンテ
ィティが輻輳しているかどうかを判定し、確認応答パケットバッファが空である
かどうかを判定し、リンク層エンティティが輻輳しているか、又は確認応答パケ
ットバッファが空でない場合には、確認応答パケットをバッファに記憶し、確認
応答パケットバッファが空であり、リンク層エンティティが輻輳していない場合
には、確認応答パケットをソースに送ることにより、確認応答パケットを確認応
答パケットバッファ内に保留すべきか、又は確認応答パケットを確認応答パケッ
トバッファ内にバッファせずに確認応答パケットを直接ソースに送るべきかを決
めることを特徴とする請求項３９に記載のアクセスノード・デバイス。 - 【請求項４２】 前記確認応答パケットは、確認応答パケットが輻輳中に確
認応答パケットバッファ内にバッファされるべき１番目の確認応答パケットであ
る場合には、確認応答パケットバッファに記憶され、スケジューラによりゲート
アウトされることを特徴とする請求項４１に記載のアクセスノード・デバイス。 - 【請求項４３】 前記確認応答制御装置は、確認応答パケットが輻輳中に確
認応答パケットバッファ内にバッファされるべき１番目の確認応答パケットであ
る場合には、確認応答パケットバッファからゲートされる確認応答パケット相互
間のスペーシングを増やすことを特徴とする請求項４２に記載のアクセスノード
・デバイス。 - 【請求項４４】 前記データパケット出発プロセッサは、リンク層エンティ
ティの輻輳が収まっている場合、確認応答パケットバッファからの確認応答パケ
ットのリリースの間のスペーシングを減少させることを特徴とする請求項３９に
記載のアクセスノード・デバイス。 - 【請求項４５】 ソースからのデータパケットの受信に応えてソースに送信
されるべき確認応答パケットのための確認応答歩調合せを提供するための方法に
おいて、 ネットワークのローディングを監視する段階と、 ネットワークのローディングに基づいて確認応答パケットのプロセッシングを
制御するための制御信号を生成する段階と、 確認応答制御装置から受信した確認応答パケットを確認応答パケットバッファ
に記憶する段階と、 制御信号に基づいて確認応答パケットをリリースする段階と、から成ることを
特徴とする方法。 - 【請求項４６】 前記リリースする段階は、キューイング戦略に基づいてリ
リースするために確認応答パケットを選定する段階を更に含んでいることを特徴
とする請求項４５に記載の方法。 - 【請求項４７】 前記キューイング戦略は、集合体確認応答パケットバッフ
ァリングが使用される場合、ヘッド・オブ・ライン確認応答パケットを送信する
段階を含んでいることを特徴とする請求項４６に記載の方法。 - 【請求項４８】 前記キューイング戦略は、クラス毎又はフロー毎確認応答
パケットバッファリングが使用される場合、リリースに向けて確認応答パケット
バッファ内の確認応答パケットを選択するための加重ラウンドロビン（ＷＲＲ）
プロセスを含んでいることを特徴とする請求項４６に記載の方法。 - 【請求項４９】 前記加重ラウンドロビン（ＷＲＲ）プロスセは、より小さ
い最大セグメントサイズ（ＭＳＳ）フローに対するバイアスを小さくするため、
リリースに向けて、ＴＣＰ最大セグメントサイズ（ＭＳＳ）に反比例して、確認
応答パケットの選択に重み付けするために重みを使用することを特徴とする請求
項４８に記載の方法。 - 【請求項５０】 前記キューイング戦略は、クラス毎又はフロー毎確認応答
パケットバッファリングが使用される場合、リリースに向けて確認応答パケット
バッファ内の確認応答パケットを選択するための公平キューイング（ＦＱ）プロ
セスを含んでいることを特徴とする請求項４６に記載の方法。 - 【請求項５１】 前記確認応答パケットのプロセッシングを制御するための
制御信号を生成する段階は、確認応答パケット到着プロセスとデータパケット出
発プロセスを含んでいることを特徴とする請求項４５に記載の方法。 - 【請求項５２】 前記確認応答パケット到着プロセスは、ネットワークの輻
輳レベルをチェックし、確認応答パケットを確認応答パケットバッファに保留す
べきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに確
認応答パケットを直接ソースに送るべきかを決めることにより、確認応答パケッ
トバッファに対する確認応答パケットのプロセッシングを制御することを特徴と
する請求項５１に記載の方法。 - 【請求項５３】 前記確認応答パケットを確認応答パケットバッファに保留
すべきか、又は確認応答パケットを確認応答パケットバッファにバッファせずに
確認応答パケットを直接ソースに送るべきかを決める段階は、ネットワークが輻
輳しているかどうかを判定する段階と、確認応答パケットバッファが空であるか
どうかを判定する段階と、ネットワークが輻輳しているか、又は確認応答パケッ
トバッファが空でない場合、確認応答パケットをバッファに記憶する段階と、確
認応答パケットバッファが空であり、ネットワークが輻輳していない場合、確認
応答パケットをソースに送る段階と、を更に含んでいることを特徴とする請求項
５１に記載の方法。 - 【請求項５４】 前記確認応答パケットは、確認応答パケットが確認応答パ
ケットバッファ内にバッファされるべき１番目のパケットである場合には、確認
応答パケットバッファ内に記憶され、ゲートアウトされることを特徴とする請求
項５３に記載の方法。 - 【請求項５５】 確認応答パケットが確認応答パケットバッファ内にバッフ
ァされるべき１番目のパケットである場合には、確認応答パケットバッファから
ゲートされる確認応答パケット相互間のスペーシングを増加させる段階を更に含
んでいることを特徴とする請求項５４に記載の方法。 - 【請求項５６】 前記スペーシングを増加させる段階は、パケットカウンタ
変数を第１の所定値にセットする段階を更に含んでいることを特徴とする請求項
５５に記載の方法。 - 【請求項５７】 データパケットがネットワークを出発する際にパケットカ
ウンタ変数を減分する段階を更に含んでいることを特徴とする請求項５６に記載
の方法。 - 【請求項５８】 前記パケットカウンタ変数が減分されてゼロになると、バ
ッファされている確認応答パケットをリリースする段階と、前記パケットカウン
タ変数をリセットする段階とを更に含んでいることを特徴とする請求項５７に記
載の方法。 - 【請求項５９】 ネットワークの前記輻輳レベルは、データパケットバッフ
ァの容量を表すキュー長を分析することにより求められることを特徴とする請求
項５２に記載の方法。 - 【請求項６０】 前記キュー長が低い閾値よりも小さいときには、前記ネッ
トワークが輻輳していないと表示する段階を更に含んでいることを特徴とする請
求項５９に記載の方法。 - 【請求項６１】 前記キュー長が高い閾値よりも大きいときには、前記ネッ
トワークが輻輳していると表示する段階を更に含んでいることを特徴とする請求
項５９に記載の方法。 - 【請求項６２】 前記リリースする段階は、ネットワークの輻輳レベルを監
視する段階と、確認応答パケットを確認応答パケットバッファからソースへ何時
ゲートさせるかを決定する段階を更に含んでいることを特徴とする請求項５１に
記載の方法。 - 【請求項６３】 前記決定する段階は、確認応答パケットが送信を待ちなが
ら確認応答パケットバッファ内に在るか否か、並びに確認応答制御装置によりセ
ットされたパケットカウンタ変数がゼロの値を有しているか否かをチェックする
段階と、パケットカウンタ変数がゼロの値を有している場合、確認応答パケット
バッファ内のバッファされた確認応答パケットをソースにリリースする段階とを
更に含んでいることを特徴とする請求項６２に記載の方法。 - 【請求項６４】 前記データパケット出発プロセスは、ネットワーク内に依
然として輻輳が存在している場合、確認応答パケットバッファからの確認応答パ
ケットのリリースの間のスペーシングを増加する段階を更に含んでいることを特
徴とする請求項６３に記載の方法。 - 【請求項６５】 前記増加する段階は、パケットカウンタ変数を第１の所定
値にリセットする段階を更に含んでいることを特徴とする請求項６４に記載の方
法。 - 【請求項６６】 前記データパケット出発プロセスは、パケットカウンタ変
数がゼロでない場合、パケットカウンタ変数を減分する段階を更に含んでいるこ
とを特徴とする請求項６５に記載の方法。 - 【請求項６７】 前記データパケット出発プロセスは、パケットカウンタ変
数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方を
防止するために、パケットカウンタ変数を第２の所定値にリセットする段階を更
に含んでいることを特徴とする請求項６６に記載の方法。 - 【請求項６８】 前記データパケット出発プロセスは、ネットワーク内の輻
輳が収まっている場合、確認応答パケットバッファからの確認応答パケットのリ
リースの間のスペーシングを減少させる段階を更に含んでいることを特徴とする
請求項６３に記載の方法。 - 【請求項６９】 前記データパケット出発プロセスは、パケットカウンタ変
数を第１の所定値よりも小さい第２の所定値にリセットすることにより、確認応
答パケットのリリースの間のスペーシングを減少させる段階を更に含んでいるこ
とを特徴とする請求項６８に記載の方法。 - 【請求項７０】 前記データパケット出発プロセスは、パケットカウンタ変
数の値がゼロでない場合、パケットカウンタ変数を減分する段階を更に含んでい
ることを特徴とする請求項６９に記載の方法。 - 【請求項７１】 前記データパケット出発プロセスは、パケットカウンタ変
数が第２の所定値よりも大きい場合、輻輳期間後の帯域幅の不十分な使われ方を
防止するために、パケットカウンタ変数を第２の所定値にリセットする段階を更
に含んでいることを特徴とする請求項７０に記載の方法。 - 【請求項７２】 前記ネットワークの輻輳レベルを判定する段階は、データ
パケットバッファに関する容量を表すキュー長を分析する段階を更に含んでいる
ことを特徴とする請求項６３に記載の方法。 - 【請求項７３】 前記キュー長が低い閾値よりも小さい場合には、ネットワ
ークが輻輳していないと表示する段階を更に含んでいることを特徴とする請求項
７２に記載の方法。 - 【請求項７４】 前記キュー長が高い閾値よりも大きい場合には、ネットワ
ークが輻輳していると表示する段階を更に含んでいることを特徴とする請求項７
２に記載の方法。 - 【請求項７５】 前記記憶する段階は、確認応答パケットを集合体ベースで
バッファする段階を更に含んでいることを特徴とする請求項４５に記載の方法。 - 【請求項７６】 前記記憶する段階は、フロータイプにより確認応答パケッ
トをバッファする段階を更に含んでおり、前記リリースする段階は、バッファさ
れた確認応答パケットに関するフローのタイプを考慮することにより、確認応答
バッファ内の確認応答パケットのリリースをスケジュールする段階を更に含んで
いることを特徴とする請求項４５に記載の方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/167,882 | 1998-10-07 | ||
| US09/167,882 US6215769B1 (en) | 1998-10-07 | 1998-10-07 | Enhanced acknowledgment pacing device and method for TCP connections |
| PCT/US1999/023143 WO2000021233A2 (en) | 1998-10-07 | 1999-10-06 | Enhanced acknowledgement pacing device and method for tcp connections |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002527936A true JP2002527936A (ja) | 2002-08-27 |
| JP4417566B2 JP4417566B2 (ja) | 2010-02-17 |
Family
ID=22609207
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000575250A Expired - Fee Related JP4417566B2 (ja) | 1998-10-07 | 1999-10-06 | Ｔｃｐ接続のためのエンハンスド確認応答歩調合せデバイス及び方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6215769B1 (ja) |
| EP (1) | EP1169826B1 (ja) |
| JP (1) | JP4417566B2 (ja) |
| CN (1) | CN1134945C (ja) |
| AU (1) | AU6289099A (ja) |
| DE (1) | DE69942071D1 (ja) |
| WO (1) | WO2000021233A2 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004229306A (ja) * | 2003-01-24 | 2004-08-12 | Microsoft Corp | 送信コンピューティングシステムが連続するアクションを歩調合せする方法 |
| JP2007325270A (ja) * | 2006-06-01 | 2007-12-13 | Asustek Computer Inc | 無線通信システムのデータ伝送効率を向上させる方法及び装置 |
| US8483063B2 (en) | 2010-03-19 | 2013-07-09 | Hitachi, Ltd. | Mobile communication system and communication method |
Families Citing this family (149)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7085227B1 (en) * | 2001-05-11 | 2006-08-01 | Cisco Technology, Inc. | Method for testing congestion avoidance on high speed networks |
| WO1999034555A2 (en) * | 1997-12-24 | 1999-07-08 | America Online, Inc. | Asynchronous data protocol |
| US6594246B1 (en) | 1998-07-10 | 2003-07-15 | Malibu Networks, Inc. | IP-flow identification in a wireless point to multi-point transmission system |
| US6590885B1 (en) | 1998-07-10 | 2003-07-08 | Malibu Networks, Inc. | IP-flow characterization in a wireless point to multi-point (PTMP) transmission system |
| US6452915B1 (en) | 1998-07-10 | 2002-09-17 | Malibu Networks, Inc. | IP-flow classification in a wireless point to multi-point (PTMP) transmission system |
| US6862622B2 (en) * | 1998-07-10 | 2005-03-01 | Van Drebbel Mariner Llc | Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture |
| US6640248B1 (en) | 1998-07-10 | 2003-10-28 | Malibu Networks, Inc. | Application-aware, quality of service (QoS) sensitive, media access control (MAC) layer |
| US6680922B1 (en) | 1998-07-10 | 2004-01-20 | Malibu Networks, Inc. | Method for the recognition and operation of virtual private networks (VPNs) over a wireless point to multi-point (PtMP) transmission system |
| US6628629B1 (en) | 1998-07-10 | 2003-09-30 | Malibu Networks | Reservation based prioritization method for wireless transmission of latency and jitter sensitive IP-flows in a wireless point to multi-point transmission system |
| CA2249152C (en) * | 1998-09-30 | 2003-07-08 | Northern Telecom Limited | Apparatus for and method of managing bandwidth for a packet-based connection |
| US6556578B1 (en) * | 1999-04-14 | 2003-04-29 | Lucent Technologies Inc. | Early fair drop buffer management method |
| US7023800B1 (en) * | 1999-06-01 | 2006-04-04 | Microsoft Corporation | Congestion avoidance within aggregate channels |
| SE516871C2 (sv) * | 1999-06-23 | 2002-03-12 | Teracom Ab | Metod för flödesstyrning i ett datakommunikationsnät |
| US6570851B1 (en) * | 1999-07-01 | 2003-05-27 | Nokia Telecommunications Oy | Receiver driven differentiated service marking for unicast and multicast applications |
| US6603771B1 (en) | 1999-07-02 | 2003-08-05 | Cypress Semiconductor Corp. | Highly scalable architecture for implementing switch fabrics with quality of services |
| US6584517B1 (en) * | 1999-07-02 | 2003-06-24 | Cypress Semiconductor Corp. | Circuit and method for supporting multicast/broadcast operations in multi-queue storage devices |
| US6628656B1 (en) | 1999-08-09 | 2003-09-30 | Cypress Semiconductor Corp. | Circuit, method and/or architecture for improving the performance of a serial communication link |
| US6625177B1 (en) | 1999-08-09 | 2003-09-23 | Cypress Semiconductor Corp. | Circuit, method and/or architecture for improving the performance of a serial communication link |
| US6990070B1 (en) | 1999-12-17 | 2006-01-24 | Nortel Networks Limited | Method and apparatus for adjusting packet transmission volume from a source |
| US6785234B1 (en) * | 1999-12-22 | 2004-08-31 | Cisco Technology, Inc. | Method and apparatus for providing user control of audio quality |
| US6721786B1 (en) * | 2000-01-06 | 2004-04-13 | International Business Machines Corporation | Method and apparatus for balancing bandwidth usage in a browser |
| US7103635B2 (en) * | 2000-01-28 | 2006-09-05 | Lucent Technologies Inc. | Really simple mail transport protocol |
| JP2001237882A (ja) * | 2000-02-23 | 2001-08-31 | Nec Corp | パケットデータ転送におけるパケットサイズ制御装置及びその制御方法 |
| JP3604615B2 (ja) * | 2000-04-21 | 2004-12-22 | 株式会社東芝 | 通信装置、中継装置および通信制御方法 |
| US6894974B1 (en) * | 2000-05-08 | 2005-05-17 | Nortel Networks Limited | Method, apparatus, media, and signals for controlling packet transmission rate from a packet source |
| US6876639B1 (en) * | 2000-06-01 | 2005-04-05 | Nortel Networks Limited | Transmission control protocol handoff notification system and method |
| US6741555B1 (en) * | 2000-06-14 | 2004-05-25 | Nokia Internet Communictions Inc. | Enhancement of explicit congestion notification (ECN) for wireless network applications |
| US6910063B1 (en) * | 2000-06-28 | 2005-06-21 | Microsoft Corporation | System and method of enhancing web server throughput in single and multiple processor systems |
| US7031267B2 (en) * | 2000-12-21 | 2006-04-18 | 802 Systems Llc | PLD-based packet filtering methods with PLD configuration data update of filtering rules |
| US7013482B1 (en) | 2000-07-07 | 2006-03-14 | 802 Systems Llc | Methods for packet filtering including packet invalidation if packet validity determination not timely made |
| US7047312B1 (en) * | 2000-07-26 | 2006-05-16 | Nortel Networks Limited | TCP rate control with adaptive thresholds |
| US7200111B2 (en) * | 2000-08-31 | 2007-04-03 | The Regents Of The University Of California | Method for improving TCP performance over wireless links |
| US6826152B1 (en) | 2000-09-13 | 2004-11-30 | Harris Corporation | System and method of conserving bandwidth in the transmission of message packets |
| US6826153B1 (en) | 2000-09-13 | 2004-11-30 | Jeffrey Kroon | System and method of increasing the message throughput in a radio network |
| US6856599B1 (en) * | 2000-09-13 | 2005-02-15 | Harris Corporation | System and method of reducing retransmission of messages in a TCP/IP environment |
| US6816458B1 (en) * | 2000-09-13 | 2004-11-09 | Harris Corporation | System and method prioritizing message packets for transmission |
| US6625711B1 (en) * | 2000-11-16 | 2003-09-23 | Cypress Semiconductor Corp. | Method and/or architecture for implementing queue expansion in multiqueue devices |
| US20020080784A1 (en) * | 2000-12-21 | 2002-06-27 | 802 Systems, Inc. | Methods and systems using PLD-based network communication protocols |
| US7542419B2 (en) * | 2001-04-02 | 2009-06-02 | International Business Machines Corporation | Method and apparatus for managing aggregate bandwidth at a server |
| US6961309B2 (en) * | 2001-04-25 | 2005-11-01 | International Business Machines Corporation | Adaptive TCP delayed acknowledgment |
| AU2002303501A1 (en) * | 2001-04-27 | 2002-11-11 | Wanwall, Inc. | Weighted fair queuing-based methods and apparatus for protecting against overload conditions on nodes of a distributed network |
| US7050393B2 (en) * | 2001-05-10 | 2006-05-23 | International Business Machines Corporation | Method, system, and product for alleviating router congestion |
| US20030002497A1 (en) * | 2001-06-29 | 2003-01-02 | Anil Vasudevan | Method and apparatus to reduce packet traffic across an I/O bus |
| US7000024B1 (en) * | 2001-07-09 | 2006-02-14 | Cisco Technology, Inc. | Systems and methods for providing transmission control protocol communications |
| US7006834B2 (en) | 2001-10-29 | 2006-02-28 | Qualcomm Incorporated | Base station time calibration using position measurement data sent by mobile stations during regular position location sessions |
| US6975647B2 (en) * | 2001-11-13 | 2005-12-13 | Ems Technologies Canada, Ltd | Enhancements for TCP performance enhancing proxies |
| US7266612B1 (en) | 2002-02-14 | 2007-09-04 | At&T Corp. | Network having overload control using deterministic early active drops |
| US7283469B2 (en) * | 2002-04-30 | 2007-10-16 | Nokia Corporation | Method and system for throughput and efficiency enhancement of a packet based protocol in a wireless network |
| US7236459B1 (en) | 2002-05-06 | 2007-06-26 | Packeteer, Inc. | Method and apparatus for controlling data transmission volume using explicit rate control and queuing without data rate supervision |
| US8046484B2 (en) * | 2002-09-26 | 2011-10-25 | Sharp Laboratories Of America, Inc. | Transmitting data across a contention channel in a centralized network |
| US7428595B2 (en) * | 2002-09-30 | 2008-09-23 | Sharp Laboratories Of America, Inc. | System and method for streaming TCP messages in an enterprise network |
| KR100460958B1 (ko) * | 2002-12-04 | 2004-12-09 | 삼성전자주식회사 | 비대칭 네트워크 환경에서의 ｔｃｐ의 데이터 전송효율을향상시킬 수 있는 통신시스템 및 그 방법 |
| US7225266B2 (en) * | 2002-12-20 | 2007-05-29 | Nokia Corporation | Adaptive delayed ACK switching for TCP applications |
| US7307952B2 (en) * | 2002-12-20 | 2007-12-11 | Intel Corporation | Method and apparatus to determine whether data flow is restricted by a sending node, a receiving node, or by a network |
| US7583594B2 (en) * | 2003-01-31 | 2009-09-01 | Texas Instruments Incorporated | Adaptive transmit window control mechanism for packet transport in a universal port or multi-channel environment |
| ES2294468T3 (es) * | 2003-03-20 | 2008-04-01 | NOKIA SIEMENS NETWORKS GMBH & CO. KG | Procedimiento y emisor para la transmision de paquetes de datos. |
| US8230106B2 (en) * | 2003-03-31 | 2012-07-24 | Alcatel Lucent | Methods and apparatus for improved transmission control protocol transmission over a wireless channel exhibiting rate and delay variations |
| US20040223506A1 (en) * | 2003-05-08 | 2004-11-11 | Renesas Technology Corp. | Packet communication device sending delayed acknowledgement through network |
| US7352700B2 (en) * | 2003-09-09 | 2008-04-01 | Lucent Technologies Inc. | Methods and devices for maximizing the throughput of TCP/IP data along wireless links |
| US7502322B2 (en) * | 2003-09-30 | 2009-03-10 | Nokia Corporation | System, method and computer program product for increasing throughput in bi-directional communications |
| US7613115B2 (en) * | 2003-10-31 | 2009-11-03 | International Business Machines Corporation | Minimal delay transmission of short messages |
| US7349337B1 (en) * | 2003-12-12 | 2008-03-25 | Novell, Inc. | Techniques for shaping data transmission rates |
| US7546367B2 (en) | 2004-01-15 | 2009-06-09 | Novell, Inc. | Methods and systems for managing network traffic by multiple constraints |
| GR1006334B (el) * | 2005-03-09 | 2009-04-14 | Βασιλειος Συρης | Δρομολογητης προσβασης για παροχη διαφοροποιημενων υπηρεσιων σε ασυρματα δικτυα 802.11 |
| US7577097B2 (en) * | 2005-03-22 | 2009-08-18 | Microsoft Corporation | Compound transmission control protocol |
| US7583600B1 (en) * | 2005-09-07 | 2009-09-01 | Sun Microsytems, Inc. | Schedule prediction for data link layer packets |
| US20070073933A1 (en) * | 2005-09-13 | 2007-03-29 | International Business Machines Corporation | Asynchronous interface with vectored interface controls |
| US7719967B2 (en) | 2005-09-28 | 2010-05-18 | Netapp, Inc. | Cumulative TCP congestion control |
| US7680044B2 (en) | 2005-12-29 | 2010-03-16 | Panasonic Electric Works Co., Ltd. | Systems and methods for managing traffic within a peer-to-peer network |
| JP4764930B2 (ja) * | 2006-03-03 | 2011-09-07 | ニュー ジャージー インスティチュート オブ テクノロジー | 分散サービス妨害（ＤＤｏＳ）攻撃防御のための、挙動ベースのトラフィック識別（ＢＴＤ） |
| US7869366B1 (en) | 2006-03-28 | 2011-01-11 | Packeteer, Inc. | Application-aware rate control |
| JP4664243B2 (ja) * | 2006-06-29 | 2011-04-06 | 富士通株式会社 | 通信装置 |
| US8289965B2 (en) | 2006-10-19 | 2012-10-16 | Embarq Holdings Company, Llc | System and method for establishing a communications session with an end-user based on the state of a network connection |
| US8717911B2 (en) | 2006-06-30 | 2014-05-06 | Centurylink Intellectual Property Llc | System and method for collecting network performance information |
| US8194643B2 (en) * | 2006-10-19 | 2012-06-05 | Embarq Holdings Company, Llc | System and method for monitoring the connection of an end-user to a remote network |
| US8488447B2 (en) | 2006-06-30 | 2013-07-16 | Centurylink Intellectual Property Llc | System and method for adjusting code speed in a transmission path during call set-up due to reduced transmission performance |
| US8000318B2 (en) * | 2006-06-30 | 2011-08-16 | Embarq Holdings Company, Llc | System and method for call routing based on transmission performance of a packet network |
| US9094257B2 (en) | 2006-06-30 | 2015-07-28 | Centurylink Intellectual Property Llc | System and method for selecting a content delivery network |
| US8477614B2 (en) | 2006-06-30 | 2013-07-02 | Centurylink Intellectual Property Llc | System and method for routing calls if potential call paths are impaired or congested |
| US7948909B2 (en) * | 2006-06-30 | 2011-05-24 | Embarq Holdings Company, Llc | System and method for resetting counters counting network performance information at network communications devices on a packet network |
| US8064391B2 (en) | 2006-08-22 | 2011-11-22 | Embarq Holdings Company, Llc | System and method for monitoring and optimizing network performance to a wireless device |
| US7940735B2 (en) * | 2006-08-22 | 2011-05-10 | Embarq Holdings Company, Llc | System and method for selecting an access point |
| US8750158B2 (en) | 2006-08-22 | 2014-06-10 | Centurylink Intellectual Property Llc | System and method for differentiated billing |
| US8015294B2 (en) * | 2006-08-22 | 2011-09-06 | Embarq Holdings Company, LP | Pin-hole firewall for communicating data packets on a packet network |
| US8102770B2 (en) * | 2006-08-22 | 2012-01-24 | Embarq Holdings Company, LP | System and method for monitoring and optimizing network performance with vector performance tables and engines |
| US8238253B2 (en) | 2006-08-22 | 2012-08-07 | Embarq Holdings Company, Llc | System and method for monitoring interlayer devices and optimizing network performance |
| US7843831B2 (en) | 2006-08-22 | 2010-11-30 | Embarq Holdings Company Llc | System and method for routing data on a packet network |
| US8407765B2 (en) | 2006-08-22 | 2013-03-26 | Centurylink Intellectual Property Llc | System and method for restricting access to network performance information tables |
| WO2008024387A2 (en) * | 2006-08-22 | 2008-02-28 | Embarq Holdings Company Llc | System and method for synchronizing counters on an asynchronous packet communications network |
| US8224255B2 (en) | 2006-08-22 | 2012-07-17 | Embarq Holdings Company, Llc | System and method for managing radio frequency windows |
| US20080049629A1 (en) * | 2006-08-22 | 2008-02-28 | Morrill Robert J | System and method for monitoring data link layer devices and optimizing interlayer network performance |
| US8274905B2 (en) | 2006-08-22 | 2012-09-25 | Embarq Holdings Company, Llc | System and method for displaying a graph representative of network performance over a time period |
| US8144586B2 (en) * | 2006-08-22 | 2012-03-27 | Embarq Holdings Company, Llc | System and method for controlling network bandwidth with a connection admission control engine |
| US8130793B2 (en) | 2006-08-22 | 2012-03-06 | Embarq Holdings Company, Llc | System and method for enabling reciprocal billing for different types of communications over a packet network |
| US8125897B2 (en) * | 2006-08-22 | 2012-02-28 | Embarq Holdings Company Lp | System and method for monitoring and optimizing network performance with user datagram protocol network performance information packets |
| US8549405B2 (en) | 2006-08-22 | 2013-10-01 | Centurylink Intellectual Property Llc | System and method for displaying a graphical representation of a network to identify nodes and node segments on the network that are not operating normally |
| US8537695B2 (en) | 2006-08-22 | 2013-09-17 | Centurylink Intellectual Property Llc | System and method for establishing a call being received by a trunk on a packet network |
| US8189468B2 (en) | 2006-10-25 | 2012-05-29 | Embarq Holdings, Company, LLC | System and method for regulating messages between networks |
| US7808918B2 (en) | 2006-08-22 | 2010-10-05 | Embarq Holdings Company, Llc | System and method for dynamically shaping network traffic |
| US8576722B2 (en) | 2006-08-22 | 2013-11-05 | Centurylink Intellectual Property Llc | System and method for modifying connectivity fault management packets |
| US8619600B2 (en) | 2006-08-22 | 2013-12-31 | Centurylink Intellectual Property Llc | System and method for establishing calls over a call path having best path metrics |
| US9479341B2 (en) | 2006-08-22 | 2016-10-25 | Centurylink Intellectual Property Llc | System and method for initiating diagnostics on a packet network node |
| US8531954B2 (en) | 2006-08-22 | 2013-09-10 | Centurylink Intellectual Property Llc | System and method for handling reservation requests with a connection admission control engine |
| US8307065B2 (en) | 2006-08-22 | 2012-11-06 | Centurylink Intellectual Property Llc | System and method for remotely controlling network operators |
| US8223655B2 (en) | 2006-08-22 | 2012-07-17 | Embarq Holdings Company, Llc | System and method for provisioning resources of a packet network based on collected network performance information |
| US8107366B2 (en) | 2006-08-22 | 2012-01-31 | Embarq Holdings Company, LP | System and method for using centralized network performance tables to manage network communications |
| US8743703B2 (en) | 2006-08-22 | 2014-06-03 | Centurylink Intellectual Property Llc | System and method for tracking application resource usage |
| US7684332B2 (en) * | 2006-08-22 | 2010-03-23 | Embarq Holdings Company, Llc | System and method for adjusting the window size of a TCP packet through network elements |
| US8199653B2 (en) | 2006-08-22 | 2012-06-12 | Embarq Holdings Company, Llc | System and method for communicating network performance information over a packet network |
| US8040811B2 (en) * | 2006-08-22 | 2011-10-18 | Embarq Holdings Company, Llc | System and method for collecting and managing network performance information |
| US8228791B2 (en) | 2006-08-22 | 2012-07-24 | Embarq Holdings Company, Llc | System and method for routing communications between packet networks based on intercarrier agreements |
| US8144587B2 (en) | 2006-08-22 | 2012-03-27 | Embarq Holdings Company, Llc | System and method for load balancing network resources using a connection admission control engine |
| US8098579B2 (en) * | 2006-08-22 | 2012-01-17 | Embarq Holdings Company, LP | System and method for adjusting the window size of a TCP packet through remote network elements |
| US8194555B2 (en) * | 2006-08-22 | 2012-06-05 | Embarq Holdings Company, Llc | System and method for using distributed network performance information tables to manage network communications |
| US8379515B1 (en) | 2007-02-01 | 2013-02-19 | F5 Networks, Inc. | TCP throughput control by imposing temporal delay |
| US8111692B2 (en) * | 2007-05-31 | 2012-02-07 | Embarq Holdings Company Llc | System and method for modifying network traffic |
| FR2922391B1 (fr) * | 2007-10-15 | 2009-12-04 | Canon Kk | Procede et dispositif de transmission de donnees |
| US8521901B2 (en) | 2007-12-28 | 2013-08-27 | Citrix Systems, Inc. | TCP burst avoidance |
| US9578055B1 (en) | 2008-01-25 | 2017-02-21 | F5 Networks, Inc. | Thwarting drone-waged denial of service attacks on a network |
| US8068425B2 (en) | 2008-04-09 | 2011-11-29 | Embarq Holdings Company, Llc | System and method for using network performance information to determine improved measures of path states |
| US8331231B2 (en) | 2008-09-09 | 2012-12-11 | Centurylink Intellectual Property Llc | System and method for monitoring bursting traffic |
| WO2010070660A1 (en) * | 2008-12-19 | 2010-06-24 | Department Of Information Technology | A centralized wireless manager (wim) for performance management of ieee 802.11 and a method thereof |
| US8374091B2 (en) * | 2009-03-26 | 2013-02-12 | Empire Technology Development Llc | TCP extension and variants for handling heterogeneous applications |
| US8780705B2 (en) * | 2009-04-30 | 2014-07-15 | Freescale Semiconductor, Inc. | Apparatus, communications system and method for optimizing data packet flow |
| US8325623B1 (en) | 2010-02-16 | 2012-12-04 | Google Inc. | System and method for reducing latency during data transmissions over a network |
| US8964543B1 (en) | 2010-02-16 | 2015-02-24 | Google Inc. | System and method of reducing latency by transmitting duplicate packets over a network |
| US8335160B2 (en) * | 2010-03-30 | 2012-12-18 | Telefonaktiebolaget L M Ericsson (Publ) | Flow sampling with top talkers |
| US8468196B1 (en) | 2010-05-20 | 2013-06-18 | Google Inc. | System and method of reducing latency using adaptive retransmission timeouts |
| US8239532B1 (en) | 2010-06-24 | 2012-08-07 | Google Inc. | System and method of reducing latency using adaptive DNS resolution |
| CN101867972B (zh) * | 2010-06-29 | 2012-12-12 | 中国科学院计算技术研究所 | 无线链路控制层非确认模式下的数据传输方法 |
| US8576711B1 (en) | 2010-09-28 | 2013-11-05 | Google Inc. | System and method for reducing latency via client side dynamic acknowledgements |
| DE102011011400B4 (de) * | 2011-02-17 | 2012-10-11 | Innoroute Gmbh | Verfahren und Anordnung zur Vermeidung von Überlast auf der Teilnehmeranschlussleitung |
| CN102143078B (zh) * | 2011-03-29 | 2013-10-02 | 华为技术有限公司 | 一种报文处理方法、转发设备及系统 |
| EP2772028B1 (en) | 2011-10-28 | 2019-07-17 | Telecom Italia S.p.A. | Control system, gateway and method for selectively delaying network data flows |
| US20140351936A1 (en) * | 2011-12-19 | 2014-11-27 | Beijing Rising Information Technology Co., Ltd. | Frequency-variable anti-virus technology |
| WO2013139010A1 (zh) * | 2012-03-21 | 2013-09-26 | 华为技术有限公司 | 确认包的处理方法、设备及系统 |
| US9276967B2 (en) | 2012-07-27 | 2016-03-01 | Centurylink Intellectual Property Llc | System and method for determining optimal bandwidth for streaming to a client device in an adjustable bit rate video system |
| US8917739B2 (en) * | 2013-01-15 | 2014-12-23 | Fluke Corporation | Method and apparatus to dynamically sample NRT using a double-ended queue that allows for seamless transition from full NRT analysis to sampled NRT analysis |
| WO2014155043A1 (en) | 2013-03-28 | 2014-10-02 | British Telecommunications Public Limited Company | Re-marking of packets for queue control |
| CN104184677B (zh) * | 2013-05-24 | 2018-12-14 | 中兴通讯股份有限公司 | 一种流量整形的驱动方法及驱动器 |
| WO2014194515A1 (en) * | 2013-06-07 | 2014-12-11 | Apple Inc. | Managing pending acknowledgement packets in a communication device |
| GB201313760D0 (en) * | 2013-07-31 | 2013-09-18 | British Telecomm | Fast friendly start for a data flow |
| US9319329B2 (en) | 2013-10-14 | 2016-04-19 | Google Inc. | Pacing enhanced packet forwarding/switching and congestion avoidance |
| CN104811998B (zh) * | 2014-01-27 | 2018-08-21 | 华为技术有限公司 | 一种控制传输控制协议窗口调整的方法和无线接入点 |
| US10645016B2 (en) | 2015-08-06 | 2020-05-05 | British Telecommunications Public Limited Company | Data packet network |
| WO2017021048A1 (en) | 2015-08-06 | 2017-02-09 | British Telecommunications Public Limited Company | Data packet network |
| CN107786307A (zh) * | 2017-09-21 | 2018-03-09 | 上海华为技术有限公司 | 一种数据处理方法及终端 |
| US10560391B2 (en) * | 2018-01-18 | 2020-02-11 | Cisco Technology, Inc. | Adaptive acknowledgement control |
| US11784933B2 (en) * | 2020-12-08 | 2023-10-10 | Google Llc | Traffic shaping offload on a network interface controller |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2540930B2 (ja) | 1988-02-19 | 1996-10-09 | 日本電気株式会社 | 輻輳制御装置 |
| JPH0583377A (ja) | 1991-09-25 | 1993-04-02 | Nec Corp | 加入者回線試験方式 |
| DE4323405A1 (de) | 1993-07-13 | 1995-01-19 | Sel Alcatel Ag | Zugangskontrollverfahren für einen Pufferspeicher sowie Vorrichtung zum Zwischenspeichern von Datenpaketen und Vermittlungsstelle mit einer solchen Vorrichtung |
| DE19507569C2 (de) | 1995-03-03 | 1997-02-13 | Siemens Ag | Schaltungsanordnung zur Aufnahme und Weiterleitung von Nachrichtenzellen durch eine ATM-Kommunikationseinrichtung |
| DE19507570C2 (de) | 1995-03-03 | 1997-08-21 | Siemens Ag | Verfahren und Schaltungsanordnung zum Weiterleiten von über eine ATM-Kommunikationseinrichtung übertragenen Nachrichtenzellen an eine Abnehmerleitung |
| US5805577A (en) | 1995-07-20 | 1998-09-08 | Jain; Raj | Erica: explicit rate indication for congestion avoidance in ATM networks |
| US5768627A (en) | 1995-12-15 | 1998-06-16 | On Spec Electronic, Inc. | External parallel-port device using a timer to measure and adjust data transfer rate |
| US5812527A (en) | 1996-04-01 | 1998-09-22 | Motorola Inc. | Simplified calculation of cell transmission rates in a cell based netwook |
| AU717590B2 (en) * | 1996-05-10 | 2000-03-30 | Fujitsu Limited | Method and apparatus for enabling flow control over multiple networks having disparate flow control capability |
| US5805585A (en) | 1996-08-22 | 1998-09-08 | At&T Corp. | Method for providing high speed packet data services for a wireless system |
| US6078564A (en) * | 1996-08-30 | 2000-06-20 | Lucent Technologies, Inc. | System for improving data throughput of a TCP/IP network connection with slow return channel |
| US6038606A (en) * | 1997-11-25 | 2000-03-14 | International Business Machines Corp. | Method and apparatus for scheduling packet acknowledgements |
-
1998
- 1998-10-07 US US09/167,882 patent/US6215769B1/en not_active Expired - Lifetime
-
1999
- 1999-10-06 DE DE69942071T patent/DE69942071D1/de not_active Expired - Lifetime
- 1999-10-06 JP JP2000575250A patent/JP4417566B2/ja not_active Expired - Fee Related
- 1999-10-06 WO PCT/US1999/023143 patent/WO2000021233A2/en active Application Filing
- 1999-10-06 CN CNB998160717A patent/CN1134945C/zh not_active Expired - Fee Related
- 1999-10-06 EP EP99950178A patent/EP1169826B1/en not_active Expired - Lifetime
- 1999-10-06 AU AU62890/99A patent/AU6289099A/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004229306A (ja) * | 2003-01-24 | 2004-08-12 | Microsoft Corp | 送信コンピューティングシステムが連続するアクションを歩調合せする方法 |
| JP4486371B2 (ja) * | 2003-01-24 | 2010-06-23 | マイクロソフト コーポレーション | 送信コンピューティングシステムが連続するアクションを歩調合せする方法 |
| JP2007325270A (ja) * | 2006-06-01 | 2007-12-13 | Asustek Computer Inc | 無線通信システムのデータ伝送効率を向上させる方法及び装置 |
| US8132068B2 (en) | 2006-06-01 | 2012-03-06 | Innovative Sonic Limited | Dual receiving window method and apparatus for automatic retransmission request |
| US8483063B2 (en) | 2010-03-19 | 2013-07-09 | Hitachi, Ltd. | Mobile communication system and communication method |
Also Published As
| Publication number | Publication date |
|---|---|
| US6215769B1 (en) | 2001-04-10 |
| WO2000021233A9 (en) | 2002-04-11 |
| WO2000021233A2 (en) | 2000-04-13 |
| EP1169826B1 (en) | 2010-02-24 |
| DE69942071D1 (de) | 2010-04-08 |
| CN1134945C (zh) | 2004-01-14 |
| WO2000021233A8 (en) | 2001-03-15 |
| JP4417566B2 (ja) | 2010-02-17 |
| AU6289099A (en) | 2000-04-26 |
| CN1344456A (zh) | 2002-04-10 |
| EP1169826A4 (en) | 2006-04-05 |
| EP1169826A2 (en) | 2002-01-09 |
| WO2000021233A3 (en) | 2001-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4417566B2 (ja) | Ｔｃｐ接続のためのエンハンスド確認応答歩調合せデバイス及び方法 | |
| US6894974B1 (en) | Method, apparatus, media, and signals for controlling packet transmission rate from a packet source | |
| US6625118B1 (en) | Receiver based congestion control | |
| US6901593B2 (en) | Active queue management with flow proportional buffering | |
| US6535482B1 (en) | Congestion notification from router | |
| EP1017203B1 (en) | Monitoring of Internet differentiated services for transactional applications | |
| US8605590B2 (en) | Systems and methods of improving performance of transport protocols | |
| US7477601B1 (en) | Methods and apparatus for managing a flow of packets using change and reply signals | |
| US6839767B1 (en) | Admission control for aggregate data flows based on a threshold adjusted according to the frequency of traffic congestion notification | |
| Mankin et al. | Gateway congestion control survey | |
| US20060140121A1 (en) | Optimization of a TCP connection | |
| EP1553740A1 (en) | Method and system for providing committed information rate (CIR) based fair access policy | |
| JP2002527989A (ja) | ハイブリッドｉｐ−ａｔｍネットワーク内で混雑状態を管理するためのｅｃｎベースの方法 | |
| CN115152193A (zh) | 针对ip路由数据中心网络使用自适应路由和基于拥塞提示的节流改进端到端拥塞反应 | |
| JP2002520921A (ja) | ネットワークの状態に関する情報を用いてｔｃｐスライディング・ウィンドウの調節を行う方法及び装置 | |
| WO2001045331A1 (en) | Congestion control method for a packet-switched network | |
| JP2001268130A (ja) | フロー制御されたネットワーク上におけるｔｃｐ接続のフローを制御するための方法および装置、相互接続機器 | |
| JP2004520725A (ja) | サテライトを介するインターネット | |
| US6990073B1 (en) | Data packet congestion management technique | |
| EP0955749A1 (en) | Receiver based congestion control and congestion notification from router | |
| US20170070442A1 (en) | Buffer bloat control | |
| Mankin et al. | RFC1254: gateway congestion control survey | |
| Aweya et al. | TCP rate control with dynamic buffer sharing | |
| Wu et al. | Tradeoffs of Implementing TCP Fairness Schemes. | |
| Patra | Improving TCP with Parameterized Forward-Retransmission Time Out |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061005 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20061005 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090409 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090420 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090721 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20090728 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090819 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20090826 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090918 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20090930 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091019 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20091112 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091126 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121204 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |