JP2018531552A - ネットワークを介するレートベースパケット伝送のためのシステムおよび方法 - Google Patents

ネットワークを介するレートベースパケット伝送のためのシステムおよび方法 Download PDF

Info

Publication number
JP2018531552A
JP2018531552A JP2018516778A JP2018516778A JP2018531552A JP 2018531552 A JP2018531552 A JP 2018531552A JP 2018516778 A JP2018516778 A JP 2018516778A JP 2018516778 A JP2018516778 A JP 2018516778A JP 2018531552 A JP2018531552 A JP 2018531552A
Authority
JP
Japan
Prior art keywords
transmission
data
rate
appliance
packet
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
Application number
JP2018516778A
Other languages
English (en)
Other versions
JP6510142B2 (ja
JP2018531552A6 (ja
Inventor
ムスタファ クツルク テスティシオグル，
ムスタファ クツルク テスティシオグル，
マヘシュ マイララッパ，
マヘシュ マイララッパ，
Original Assignee
サイトリックス システムズ，インコーポレイテッド
サイトリックス システムズ，インコーポレイテッド
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by サイトリックス システムズ，インコーポレイテッド, サイトリックス システムズ，インコーポレイテッド filed Critical サイトリックス システムズ，インコーポレイテッド
Publication of JP2018531552A publication Critical patent/JP2018531552A/ja
Publication of JP2018531552A6 publication Critical patent/JP2018531552A6/ja
Application granted granted Critical
Publication of JP6510142B2 publication Critical patent/JP6510142B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • 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/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0273—Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Environmental & Geological Engineering (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

データ伝送を制御するためのアプライアンスが説明される。アプライアンスは、リンクを経由する第１のデータパケットのフローに関するデータを取得し、フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定するように構成されているパケットエンジンを含む。アプライアンスは、第２のデータパケットを受信し、ＴＣＰ特性に基づいて、伝送レートを決定し、１つ以上の基準に基づいて、レートベースのデータ伝送制御を使用すべきかどうかを決定し、第１のデータパケットの伝送を制御するように構成されたデータ伝送コントローラも含む。データ伝送コントローラは、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきであるという決定に応答して、パケットエンジンに、第２のデータパケットをグループで伝送させるようにも構成されている。

Description

ネットワーク環境では、ネットワーク輻輳は、リンクまたはネットワークノード（例えば、ルータ）が多数のデータパケットでオーバーロードされるときに生じ得、それは、有意な伝送遅延につながり得る。さらに、ネットワークノードがデータパケットを処理不能であり、それらをドロップせざるを得ないので、有意なデータパケット損失が、生じ得る。これらは全て、ネットワーク性能の有意な劣化につながり得る。
ネットワークのオーバーロードを回避し、ネットワーク性能を改良するために利用可能な種々のスキームが存在する。例えば、トランスポート通信プロトコル（ＴＣＰ）は、いくつかの輻輳制御機構を提供し、それは、ネットワークの中に送信されるデータの量を制御するための輻輳ウィンドウの使用を含む。輻輳ウィンドウは、１つのネットワークラウンドトリップ時間（ＲＴＴ）内にネットワークの中に伝送され得るデータの最大サイズを定義することができる。ＲＴＴは、送信側デバイスがデータパケットを伝送するときと、送信側デバイスが受信側デバイスから伝送されたデータパケットに対する肯定応答を受信するときとの間の経過時間に基づいて測定されることができる。輻輳ウィンドウは、ネットワークがより多くのデータパケットを伝送するための容量を有することの指示（例えば、伝送されたデータパケットに対応する肯定応答の受信によって示され得る、ネットワークを通したデータパケットの前の伝送の成功）に基づいて、より多くのデータがネットワークの中に送信されることを可能にするために増加させられることができる。輻輳ウィンドウは、ネットワークが輻輳していることの指示に基づいて、より少ないデータがネットワークの中に送信されることを可能にするために減少させられることもできる。そのような指示は、例えば、ある数の重複肯定応答の受信、選択的肯定応答（ＳＡＣＫ）、肯定応答の受信前にＲＴＴの推定値を反映するタイマが切れるとき等のパケット損失の検出に基づくことができる。ＴＣＰ輻輳制御機構は、再伝送アルゴリズムも含み、データパケットが損失されたことの指示が存在するとき、データパケットが再伝送される。さらに、ＴＣＰは、遅延肯定応答も可能にし、いくつかの肯定応答（いくつかのデータパケットの受信に応答して）が、単一肯定応答に組み合わせられ、プロトコルオーバーヘッドを低減させることができる。
前述のＴＣＰ輻輳制御機構は、いくつかの仮定に基づいて動作する。そのような仮定は、例えば、１）ボトルネックノード（例えば、ルータ）の帯域幅が同一のままであることと、２）接続待ち時間における変化が、パケットがネットワーク輻輳を示すボトルネックノードにおいて待ち行列に入れられていることを示すことと、３）パケット損失が、典型的には、ネットワーク輻輳の指示であり、それに帰することと、４）重複肯定応答にもつながり得る、パケット並べ替えが、希事象であり、数パケット内で検出され得ることと、５）遅延させられた肯定応答が、遅延肯定応答アルゴリズムがアクティブであるときのみに観察され、最大２つのパケットに対して１つの肯定応答に限定されることとを含み得る。
前述の仮定のうちの全部ではないにしても、大部分は、無線ネットワーク（例えば、ＷｉＦｉ、ＬＩＢ等）等のいくつかのタイプのネットワークに対して不正確であり得る。例えば、ＬＴＥネットワークでは、帯域幅は、下位層において展開されるチャネル／搬送波集約技法に起因して変動し得る。媒体アクセス制御（ＭＡＣ）および無線リンク制御（ＲＬＣ）層における再伝送機構に起因して、連続待ち時間変動も存在し得る。チャネルおよび搬送波集約／集約解除時、待ち時間が多数の通常パス待ち時間に急増することも観察されている。さらに、ＭＡＣおよびＲＬＣ構成に基づく多数のアウトオブオーダパケットが、観察され得る。さらに、必ずしも輻輳に起因するネットワークノードのデータパケットの処理の失敗に帰するわけではないランダムデータパケット損失が、無線ネットワークにおいて頻繁に生じる。したがって、ランダムデータパケット損失は、典型的には、そのようなネットワーク内のネットワーク輻輳の信頼性のあるインジケータではない。
全てのこれらの不正確な仮定は、パケット損失の正しくない決定および／またはネットワーク輻輳の正しくない決定につながり得る。例えば、ランダムデータパケット損失は、ネットワーク輻輳を示すように間違って解釈され得る。さらに、いくつかの無線規格（例えば、４Ｇ）下では、受信側デバイスは、ストレッチ肯定応答を送信し得、それは、データの完全ＲＴＴに値する量を対象とし得るが、データ送信の１ ＲＴＴ内で到着しない。ストレッチ肯定応答の遅延させられた受信は、いくつかの点においてＴＣＰ輻輳制御機構の動作に影響を及ぼし得る。第１に、ＴＣＰ輻輳制御機構下では、輻輳ウィンドウの調節およびデータパケットの次の組の伝送の両方が、前に伝送されたデータパケットの肯定応答の受信によってトリガされ、それらの前に伝送されたデータパケットに対応する、ストレッチ肯定応答の遅延させられた受信によって延期され、ネットワークリソースの過小利用につながり得る。第２に、輻輳関連パケット損失の正しくない決定が生じる場合、例えば、ストレッチ肯定応答が、ネットワーク輻輳に起因してではなく、ストレッチ肯定応答の生成のためのデータの蓄積に起因して、予期されるＲＴＴよりも後に到着するとき、輻輳ウィンドウサイズの不必要な低減およびデータパケットの再伝送が、生じ得る。ネットワーク性能は、その結果、劣化し得る。
いくつかの側面では、データ伝送を制御するためのアプライアンスが、説明される。アプライアンスは、リンクを経由した第１のデータパケットのフローに関するデータを取得し、フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定するように構成されているパケットエンジンを含むことができる。アプライアンスは、第２のデータパケットを受信し、伝送レートを決定し、１つ以上の基準に基づいて、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきかどうかを決定するように構成されるデータ伝送コントローラも含むことができる。データ伝送コントローラは、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきであることの決定に応答して、パケットエンジンに、第２のデータパケットをグループで伝送させるように構成され、第２のデータパケットの各グループの伝送時間は、伝送レートに基づいて決定される。
別の側面では、データ伝送を制御する方法が説明される。方法は、リンクを経由した第１のデータパケットのフローに関するデータを取得することと、フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定することと、第２のデータパケットを受信することと、伝送レートを決定することと、１つ以上の基準に基づいて、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきかどうかを決定することと、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきであることの決定に応答して、第２のデータパケットをグループで伝送することとを含むことができ、第２のデータパケットの各グループの伝送時間は、伝送レートに基づいて決定される。
さらに別の側面では、非一過性コンピュータ読み取り可能な記憶媒体が説明される。記憶媒体は、アプライアンスの少なくとも１つのプロセッサによって実行可能であり、アプライアンスにデータ伝送を制御する方法を行わせる、命令の組を記憶する。方法は、リンクを経由した第１のデータパケットのフローに関するデータを取得することと、フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定することと、第２のデータパケットを受信することと、伝送レートを決定することと、１つ以上の基準に基づいて、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきかどうかを決定することと、レートベースのデータ伝送制御が第２のデータパケットの伝送を制御するために使用されるべきであることの決定に応答して、第２のデータパケットをグループで伝送することとを含むことができ、第２のデータパケットの各グループの伝送時間は、伝送レートに基づいて決定される。
ここで、本開示の例示的実施形態を示す付随の図面を参照する。
図１は、本開示の実施形態に準拠する、例示的ネットワーク環境のブロック図である。 図２Ａ−２Ｂは、本開示の実施形態に準拠する、例示的コンピューティングデバイスのブロック図である。 図２Ａ−２Ｂは、本開示の実施形態に準拠する、例示的コンピューティングデバイスのブロック図である。 図３Ａは、本開示の実施形態に準拠する、図１に図示される例示的アプライアンスのブロック図である。 図３Ｂは、本開示の実施形態に準拠する、図３Ａに図示される例示的アプライアンスの一部のブロック図である。 図４は、本開示の実施形態に準拠する、データパケットの伝送レートを推定するために使用される通信の例示的組を図示する。 図５は、本開示の実施形態に準拠する、データ伝送コントローラのための例示的実施形態のブロック図である。 図６は、本開示の実施形態に準拠する、データ伝送制御の例示的方法を表すフローチャートである。 図７Ａ−７Ｃは、本開示の実施形態に準拠する、データ伝送制御の例示的方法を表すフローチャートである。 図７Ａ−７Ｃは、本開示の実施形態に準拠する、データ伝送制御の例示的方法を表すフローチャートである。 図７Ａ−７Ｃは、本開示の実施形態に準拠する、データ伝送制御の例示的方法を表すフローチャートである。
ここで、本開示に従って実装される例示的実施形態が詳細に参照されるであろうが、その実施例は、付随の図面に図示される。可能である場合は常に、同一参照番号は、図面全体を通して、同一または同様の部品を指すために使用されるであろう。
本明細書に説明される実施形態は、データが実際のネットワーク性能を反映させるレートにおいてネットワークを経由して伝送されることを可能にするレートベースのデータ伝送制御を提供し、旧来のＴＣＰ輻輳制御機構下におけるネットワーク輻輳の正しくない決定に起因する、ネットワークのオーバーロードおよび／または過小利用を軽減することができる。ネットワークデータフローの効率は、その結果、改良されることができる。
図１は、例示的通信システム１００のブロック図である。例示的通信システム１００は、ネットワークを経由してデータパケットを伝送する任意のタイプのシステムであることができる。例えば、例示的通信システム１００は、有線または無線ネットワークを横断してデータパケットを端末（図１Ａに図示されない端末）に伝送する１つ以上のネットワークを含むことができる。例示的通信システム１００は、例えば、ＧＳＭ（登録商標）ネットワーク、ワイドバンド符号分割多重アクセス（Ｗ−ＣＤＭＡ）無線アクセス技術を採用するＵＭＴＳネットワーク、ＣＤＭＡ２０００ネットワーク、ＷｉＭａｘネットワーク、ＬＴＥネットワーク等のネットワークアーキテクチャを有することができる。
例示的通信システム１００は、とりわけ、１つ以上のネットワーク１０１、１０２、１０３（Ａ−Ｃ）と、１つ以上のコントローラ１０４（Ａ−Ｄ）と、１つ以上のサービングノード１０５（Ａ−Ｂ）と、１つ以上の基地局１０７（Ａ−Ｃ）−１０９（Ａ−Ｃ）と、ゲートウェイ１２０と、１つ以上のアプライアンス１４０とを含むことができる。大まかには、通信システム１００は、ツリー状ネットワークトポロジを有することができ、ゲートウェイ１２０は、ツリーのルートノードであり、基地局１０７−１０９は、リーフである。
ネットワーク１０１は、無線ネットワーク、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、またはインターネット通信等のパケットタイプ通信に好適な無線ネットワークの任意の組み合わせであることができる。例えば、一例示的実施形態では、ネットワーク１０１は、汎用パケット無線サービス（ＧＰＲＳ）コアネットワークであることができ、それは、ＧＳＭ（登録商標）およびＷ−ＣＤＭＡネットワークにおけるインターネットプロトコルパケットサービスのためのモビリティ管理、セッション管理、およびトランスポートを提供する。いくつかの実施形態では、ネットワーク１０１は、ゲートウェイ１２０と、１つ以上のサービングノード１０５（Ａ−Ｂ）とを含むことができる。
ネットワーク１０２は、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、またはパケットタイプ通信に好適な無線ネットワークの任意の組み合わせを含むことができる。いくつかの例示的実施形態では、ネットワーク１０２は、例えば、インターネットおよびＸ．２５ネットワークであることができる。いくつかの実施形態では、ネットワーク１０２は、データパケットをクライアントデバイス１３０（Ａ−Ｃ）から受信することができる。クライアントデバイス１３０は、ネットワーク１０１および１０３を通して別の遠隔デバイス（例えば、サーバ、別のクライアントデバイス等）と通信するように構成される任意のデバイスであることができる。ネットワーク１０２は、クライアントデバイス１３０から受信されたデータパケットを、例えば、ゲートウェイ１２０を介して、ネットワーク１０１と通信することができる。クライアントデバイス１３０は、コンピュータ（例えば、クライアントデバイス１３０Ａ）、ラップトップ（例えば、クライアントデバイス１３０Ｂ）、およびタブレット（例えば、クライアントデバイス１３０Ｃ）として描かれるが、クライアントデバイス１３０は、パケットをネットワーク１０１、１０２、および１０３を通して通信する任意のタイプのデバイス（例えば、ウェアラブルスマートウォッチ等）であり得ることを理解されたい。
ゲートウェイ１２０は、１つのタイプのネットワーク内で提供されるフォーマットされたデータを別のタイプのネットワークのために要求される特定のフォーマットに変換する、デバイスである。ゲートウェイ１２０は、サーバ、ルータ、ファイアウォールサーバ、ホスト、またはプロキシサーバ、もしくは前述の任意の組み合わせであり得る。いくつかの実施形態では、ゲートウェイ１２０は、負荷バランサまたは他の類似システムを含むことができる。いくつかの実施形態では、ゲートウェイ１２０は、ルータ１１０から受信された信号をネットワーク１０１が理解し得る信号に変換することができ、その逆もできる。ゲートウェイ１２０は、単独で、または任意の組み合わせにおいて、ウェブページ、画像、オーディオ、ビデオ、およびＴ．１２０伝送を処理可能であり得、全二重媒体変換可能である。例示的実施形態として、ゲートウェイ１２０は、ＧＰＲＳネットワークと、インターネットおよびＸ．２５ネットワークのような外部パケット切り替え式ネットワークとの間のインターワーキングをサポートするゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）であることができる。
サービングノード１０５は、データパケットをゲートウェイ１２０からその地理的サービスエリア内の対応するネットワーク１０３に送達し、その逆も行うデバイスである。サービングノード１０５は、例えば、サーバ、ルータ、ファイアウォールサーバ、ホスト、またはプロキシサーバであることができる。サービングノード１０５は、パケットルーティングおよび転送、モビリティ管理（アタッチ／デタッチおよび場所管理）、論理リンク管理、ネットワークアクセス調停および認証、ならびに課金機能を含む機能を有することもできる。いくつかの実施形態では、サービングノード１０５は、サービングＧＰＲＳサポートノード（ＳＧＳＮ）であることができる。そのような実施形態では、ＳＧＳＮは、場所レジスタを有することができ、それは、本ＳＧＳＮに登録された全てのＧＰＲＳユーザの場所情報、例えば、現在のセル、現在の訪問先場所（ＶＬＲ）と、ユーザプロファイル、例えば、国際モバイルサブスクライバ識別（ＩＭＳＩ）およびパケットデータネットワーク内で使用されるアドレスとを記憶する。
ネットワーク１０３は、ＧＳＭ（登録商標）もしくはＵＭＴＳネットワークまたはパケットタイプ通信に好適な任意の他の無線ネットワーク内の任意の無線送受信機ネットワークを含むことができる。いくつかの例示的実施形態では、利用されている下層トランスポート技術に応じて、ネットワーク１０３の無線アクセスネットワーク（ＲＡＮ）またはバックホールエリアは、リングトポロジを有することができる。いくつかの実施形態では、ネットワーク１０３は、ＧＳＭ（登録商標）システム内のＲＡＮまたはＵＭＴＳシステムのバックホールエリアであることができる。例示的ネットワーク１０３は、とりわけ、基地局１０７−１０９（例えば、送受信基地局（ＢＴＳ）またはＮｏｄｅ−Ｂ）と、１つ以上のコントローラ１０４（Ａ−Ｃ）（例えば、基地局コントローラ（ＢＳＣ）または無線ネットワークコントローラ（ＲＮＣ））とを含むことができる。モバイル端末（図１には図示せず）は、無線送受信機機器を有するＢＴＳ／Ｎｏｄｅ−Ｂ １０７−１０９と通信する。ＢＴＳ／Ｎｏｄｅ−Ｂ １０７−１０９は、ユーザが１つのセルから別のセルに移動する場合の無線チャネルの配分およびハンドオフに責任がある、ＢＳＣ／ＲＮＣ１０４（Ａ−Ｃ）と通信する。ＢＳＣ／ＲＮＣ１０４（Ａ−Ｃ）は、順に、ユーザのモビリティを管理し、かつネットワークへのアクセス調停および課金等の他の機能を提供する、サービングノード１０５に通信する。
アプライアンス１４０は、例えば、広域ネットワーク（ＷＡＮ）トラフィックを最適化および制御することができるデバイスである。いくつかの実施形態では、アプライアンス１４０は、ローカルエリアネットワーク（ＬＡＮ）トラフィック、都市規模ネットワーク（ＭＡＮ）トラフィック、または無線ネットワークトラフィック等の他のタイプのネットワークトラフィックを最適化する。アプライアンス１４０は、多くの企業ネットワークにおいて一般的であるＭｕｌｔｉｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ（「ＭＰＬＳ」）のような異なるネットワークをハンドリングすることもできる。アプライアンス１４０は、例えば、ある数のデータパケットが、スケジュールされた時間およびレートで伝送またはドロップされるように確立された通信リンク内のデータパケットをスケジュールすることによって、ネットワーク１０１および１０２ならびにダウンストリームネットワーク（例えば、ネットワーク１０３）内のネットワーク輻輳を回避または軽減するようにネットワークトラフィックを最適化することができる。いくつかの実施形態では、アプライアンス１４０は、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍ’ｓ Ｂｒａｎｃｈ Ｒｅｐｅａｔｅｒ、Ｎｅｔｓｃａｌｅｒ、またはＣｌｏｕｄブリッジ等の物理デバイスである。いくつかの実施形態では、アプライアンス１４０は、仮想アプライアンスであることができる。いくつかの実施形態では、アプライアンス１４０は、仮想マシン（例えば、仮想クラウドブリッジ）の複数のインスタンスを有する物理デバイスであることができる。図１に示されるように、アプライアンス１４０は、ネットワーク１０１内の種々の場所で展開されることができる。いくつかの実施形態では、アプライアンス１４０は、ゲートウェイ１２０、コントローラ１０４、１つ以上の基地局１０７−１０９、または任意の他の場所に位置し、その場所におけるネットワークトラフィックを最適化することができる。
いくつかの実施形態では、通信システム１００はさらに、アプライアンス１４０（図１には図示せず）と通信可能に結合されるデータセンタを含む。データセンタは、物理または仮想のいずれかにおける、特定のパブリックまたはプライベートエンティティに関するデータおよび情報の記憶、管理、および配布のための中央リポジトリであることができる。データセンタは、コンピュータシステムと、１つ以上の物理サーバ、仮想サーバ、および記憶システム等の関連付けられたコンポーネントとを格納するために使用されることができる。データセンタは、とりわけ、あるサービスを提供するように構成される、１つ以上のサーバを含むことができる。データセンタはまた、図１のアプライアンス１４０に類似する様式においてネットワークトラフィックを最適化し得る、アプライアンスを含むことができる。いくつかの実施形態では、データセンタにおけるアプライアンスは、ネットワークトラフィックを最適化する際、アプライアンス１４０と協働することができる。
アプライアンス１４０およびゲートウェイ１２０は、本明細書に説明される任意のタイプおよび形態のネットワーク上で通信可能な任意のタイプならびに形態の具体的コンピューティングデバイス（例えば、図２Ａ−２Ｂのコンピューティングデバイス等）として展開される、またはその上で実行されることができる。
図２Ａ−２Ｂに示されるように、各コンピューティングデバイス２００は、中央処理ユニット（ＣＰＵ）２２１と、メインメモリ２２２とを含む。ＣＰＵ２２１は、メインメモリ２２２からフェッチされた命令に応答し、それを処理する、任意の論理回路であることができる。ＣＰＵ２２１は、メモリ（例えば、メインメモリ２２２）またはキャッシュ（例えば、キャッシュ２４０）内に記憶される特定の命令の組を実行可能な単一もしくは複数のマイクロプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはデジタル信号プロセッサ（ＤＳＰ）であることができる。メモリは、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ（コンパクトディスク読み取り専用メモリ）、ＭＯ（光磁気）ドライブ、ＤＶＤ−ＲＯＭ（デジタル多用途ディスク読み取り専用メモリ）、ＤＶＤ−ＲＡＭ（デジタル多用途ディスクランダムアクセスメモリ）、フラッシュドライブ、フラッシュメモリ、レジスタ、キャッシュ、または半導体メモリ等の有形および／または非一過性コンピュータ読み取り可能な媒体を含む。メインメモリ２２２は、データを記憶可能であり、任意の記憶装置場所がＣＰＵ２２１によって直接アクセスされることを可能にする１つ以上のメモリチップであることができる。メインメモリ２２２は、任意のタイプのランダムアクセスメモリ（ＲＡＭ）または本明細書に説明されるように動作可能な任意の他の利用可能なメモリチップであることができる。図２Ａに示される例示的実施形態では、ＣＰＵ２２１は、システムバス２５０を介して、メインメモリ２２２と通信する。コンピューティングデバイス２００は、視覚的ディスプレイデバイス２２４と、Ｉ／Ｏコントローラ２２３を通して接続される入力／出力（Ｉ／Ｏ）デバイス２３０（例えば、キーボード、マウス、またはポインティングデバイス）とを含むこともでき、両方とも、システムバス２５０を介して通信する。ＣＰＵ２２１が、シリアル通信様式または２地点間通信様式を通して等、システムバス２５０を通して以外の様式でメモリ２２２および他のデバイスと通信することもできることを理解されたい。さらに、（Ｉ／Ｏ）デバイス２３０は、コンピューティングデバイス２００のための記憶および／またはインストール媒体を提供することもできる。
図２Ｂは、ＣＰＵ２２１がメモリポート２０３を介してメインメモリ２２２と直接通信する例示的コンピューティングデバイス２００の実施形態を描写する。ＣＰＵ２２１は、バックサイドバスとも称される二次バス（図示せず）を介して、キャッシュ２４０と通信することができる。ある他の実施形態では、ＣＰＵ２２１は、システムバス２５０を介して、キャッシュ２４０と通信することができる。キャッシュ２４０は、典型的には、メインメモリ２２２より高速の応答時間を有する。図２Ｂに示される実施形態等のいくつかの実施形態では、ＣＰＵ２２１は、Ｉ／Ｏポート（図示せず）を介して、Ｉ／Ｏデバイス２３０と直接通信することができる。さらなる実施形態では、Ｉ／Ｏデバイス２３０は、システムバス２５０と、ＵＳＢバス、Ａｐｐｌｅ Ｄｅｓｋｔｏｐバス、ＲＳ−２３２シリアル接続、ＳＣＳＩバス、ＦｉｒｅＷｉｒｅＴＭバス、ＦｉｒｅＷｉｒｅ８００ＴＭバス、Ｅｔｈｅｒｎｅｔ（登録商標）バス、ＡｐｐｌｅＴａｌｋＴＭバス、Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）バス、Ａｓｈｙｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅバス、ＨＩＰＰＩバス、Ｓｕｐｅｒ ＨＩＰＰＩバス、ＳｅｒｉａｌＰｌｕｓバス、ＳＣＩ／ＬＡＭＰバス、ＦｉｂｒｅＣｈａｎｎｅｌＴＭバス、またはＳｅｒｉａｌ Ａｔｔａｃｈｅｄスモールコンピュータシステムインターフェースバス、またはある他のタイプのデータバス等の外部通信バスとの間のブリッジ２７０であることができる。
図２Ａに示されるように、コンピューティングデバイス２００は、例えば、ＵＳＢデバイス、フラッシュドライブ、ＳＤメモリカード、ハードドライブ、または任意のクライアントエージェント２２０等のソフトウェアおよびプログラムまたはその一部をインストールするために好適な任意の他のデバイス等、１つ以上のコンピュータ読み取り可能な媒体を受け取るためのディスクドライブまたは他の入力ポート等の任意の好適なインストールデバイス２１６をサポートすることができる。コンピューティングデバイス２００は、オペレーティングシステムおよび他の関連ソフトウェア、およびクライアントエージェント２２０に関連する任意のプログラム等のアプリケーションソフトウェアプログラムを記憶するための１つ以上のハードディスクドライブもしくは独立ディスクの冗長アレイ等の記憶デバイス２２８も備えていることができる。随意に、インストールデバイス２１６の任意のものは、記憶デバイス２２８としても使用され得る。
さらに、コンピューティングデバイス２００は、限定ではないが、標準的電話回線、ＬＡＮまたはＷＡＮリンク（例えば、８０２．１１、Ｔｌ、Ｔ３、５６ｋｂ、Ｘ．２５）、ブロードバンドリンク（例えば、ＩＳＤＮ、Ｆｒａｍｅ Ｒｅｌａｙ、ＡＴＭ）、無線接続（Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚ−Ｗａｖｅ、Ｚｉｇｂｅｅ（登録商標））、または前述の任意もしくは全てのいくつかの組み合わせを含む、種々のリンクを通して、ＬＡＮ、ＷＡＮ、ＭＡＮ、またはインターネットとインターフェースをとるためのネットワークインターフェース２１８を含むことができる。ネットワークインターフェース２１８は、内蔵ネットワークアダプタ、ネットワークインターフェースカード、ＰＣＭＣＩＡネットワークカード、カードバスネットワークアダプタ、無線ネットワークアダプタ、ＵＳＢネットワークアダプタ、モデム、またはコンピューティングデバイス２００を通信可能な任意のタイプのネットワークにインターフェースをとらせ、本明細書に説明される動作を行うために好適な任意の他のデバイスを備えていることができる。
図３Ａは、本開示の実施形態に準拠する、図１に図示される例示的アプライアンス１４０のブロック図である。アプライアンス１４０は、図２Ａのネットワークインターフェース２１８に準拠する１つ以上のネットワークインターフェース２１８Ａ−Ｎと、パケットエンジン３２０と、データ伝送コントローラ３３０とを含むことができる。図３Ａは、ネットワークインターフェース２１８Ａ−２１８Ｎを２つのネットワークインターフェースとして描写するが、インターフェース２１８Ａ−２１８Ｎは、任意の数のネットワークインターフェースを含み得ることを理解されたい。
いくつかの実施形態では、「パケット処理エンジン」、「パケットプロセッサ」、または「データプロセッサ」とも称される、パケットエンジン３２０は、ネットワークインターフェース２１８Ａ−Ｎを介してアプライアンス１４０によって受信および伝送されるデータパケットの処理の制御および管理に責任がある。パケットエンジン３２０は、関連機能の特定のステップに対応する特定の機能（例えば、データパケットの処理の制御および管理）を行う他のコンポーネントまたはプログラムの一部との使用のために設計される１つ以上のパッケージ化された機能ハードウェアユニットであり得る１つ以上のモジュールであることができる。パケットエンジン３２０は、ネットワークスタック（例えば、オープンシステム相互接続通信モデルの層およびプロトコル等）のデータリンク層（層２）、ネットワーク層（層３）、またはトランスポート層（層４）において動作し得る単一パケットエンジンまたは任意の数の複数のパケットエンジンとして具現化されることができる。パケットエンジンは、ＣＰＵ２２１によって実行された後、本明細書に説明されるステップの一部または全部を遂行するように構成されることができる。いくつかの実施形態では、データパケットは、ＩＥＥＥ８０２．３によって対象とされるそれらのプロトコル等、ＷＡＮまたはＬＡＮプロトコルのファミリのいずれかを備えているＥｔｈｅｒｎｅｔ（登録商標）通信プロトコルを介して、データリンク層を経由して搬送される。いくつかの実施形態では、ネットワークスタックは、ＩＥＥＥ８０２．１１および／またはモバイルインターネットプロトコル等の任意のタイプならびに形態の無線プロトコルを有することができる。１つ以上のパケットエンジン３２０は、ＩＰ通信プロトコルを介して等、ネットワーク層においてデータパケットをインターセプトまたは受信する。いくつかの実施形態では、パケットエンジン３２０は、ＴＣＰ通信プロトコルを介して等、トランスポート層においてデータパケットをインターセプトまたは受信し、トランスポート層の上方の任意のセッションまたは任意のアプリケーション層において動作することができる。
パケットエンジン３２０は、データパケットの処理中に１つ以上のデータパケットを待ち行列に入れるためのバッファを含むことができる。加えて、パケットエンジン３２０は、１つ以上の通信プロトコルを介して通信し、ネットワークインターフェース２１８Ａ−Ｎを介して、１つ以上のリンクを横断して複数のネットワークデータパケットを伝送および受信することができる。リンクは、アプライアンス１４０を、例えば、アプライアンス１４０から遠隔に位置する別のアプライアンス等の他のデバイスに接続する。パケットエンジン３２０は、フローに関するデータを取得し、取得されたデータを動作可能に接続されるコンピュータメモリ内に記憶するように構成されることができる。１つ以上のリンクを横断して動作する送信および受信されたデータパケットは、「データフロー」または「フロー」と見なされ得る。
いくつかの実施形態では、パケットエンジン３２０は、アクティブフローの動作を示すデータを収集することができる。例えば、データは、同一パケット（またはその肯定応答）の送信および受信の両方のためのパケット送信時間、パケット受信時間、ラウンドトリップ時間を示す情報、データパケットの損失イベントを示す情報、送信および受信されたパケットの総数、および／またはリンクを横断して動作する１つ以上のアクティブフローの輻輳および／または動作側面を示す他の情報を含むことができる。データに基づいて、パケットエンジン３２０は、フローの１つ以上のＴＣＰ特性を動的に決定することができる。フロー特性は、例えば、パケットラウンドトリップ時間、パケットのための待ち行列遅延、輻輳ウィンドウサイズ情報等を含み得る。
いくつかの実施形態では、データ伝送コントローラ３３０は、他のエンティティ（例えば、ソフトウェアアプリケーション、別の物理的デバイス等）からネットワークの中に受信され得るデータの伝送の制御に責任がある。データ伝送コントローラ３３０は、データ伝送制御コーディネータ３４０と、レートベースのデータ伝送コントローラ３５０と、輻輳ウィンドウベースのデータ伝送コントローラ３６０とをさらに含む。以下に説明されるように、レートベースのデータ伝送コントローラ３５０は、データ伝送制御コーディネータ３４０の調整下、ネットワークの中へのデータの伝送を制御することにおいて輻輳ウィンドウベースのデータ伝送コントローラ３６０と協働することができる。
いくつかの実施形態では、レートベースのデータ伝送コントローラ３５０は、ネットワーク性能を反映する情報に基づいて、データがネットワークインターフェース２１８Ａ−Ｎを介してネットワークに伝送されるべき場合、１つ以上の伝送時間を決定することができる。レートベースのデータ伝送コントローラ３５０は、例えば、ネットワーク性能情報に基づいて、データパケットのペイロードサイズおよびネットワークの中に伝送されるべきデータパケットの数を決定することによって、前述の伝送時間において伝送されるべきデータのサイズを決定することもできる。いくつかの実施形態では、ネットワーク性能情報は、パケットエンジン３２０によって計算された前のデータフローの１つ以上のＴＣＰ特性から導出されることができる。例えば、以下に説明されるように、レートベースのデータ伝送コントローラ３５０は、パケットエンジン３２０によって提供されるデータパケットの伝送時間および肯定応答の受信時間に基づいて、ネットワーク内のデータパケットの伝送レートを推定することができる。レートベースのデータ伝送コントローラ３５０は、次いで、データパケットの複数のグループを複数の対応する伝送時間において伝送するようにパケットエンジン３２０を制御することができ、伝送時間は、伝送レートを反映する時間間隔によって分離される。いくつかの実施形態では、データパケットの各グループのサイズは、同じであることができる。以下に説明されるように、前述のデータパケットサイズおよび時間間隔は、ネットワーク内の伝送レートならびにＲＴＴに基づいて決定されることができる。
いくつかの実施形態では、前述のように、伝送レートは、データパケットの伝送時間および関連付けられた肯定応答の受信時間に基づいて決定されることができる。ここで、伝送レートを決定する例示的方法を図示する図４を参照する。例証的例として、パケット４０５Ａ−Ｄ、４０６Ａ−Ｄ、４０７Ａ−Ｄ、および４０８Ａ−Ｄは、例えば、パケットエンジン３２０のバッファにおいて待ち行列に入れられる。パケット４０５Ａ−Ｄの各々は、それぞれ、ＤＡ、ＤＢ、ＤＣ、およびＤＤのデータサイズを有する。パケット４０５Ａ−Ｄの各々は、時間４１０Ａにおいて実質的に同時にデータ受信機４１２に伝送される。データ受信機４１２がパケットを受信すると、データ受信機４１２は、受信されたパケットの各々のための肯定応答を伝送し、ａｃｋ４１５Ａは、パケット４０５Ａに対応し、ａｃｋ４１５Ｂは、パケット４０５Ｂに対応し、ａｃｋ４１５Ｃは、パケット４０５Ｃに対応し、ａｃｋ４１５Ｄは、パケット４０５Ｄに対応する。図４に示されるように、アプライアンス１４０は、ａｃｋ４１５Ａを時間４２０Ａにおいて、ａｃｋ４１５Ｂを時間４２０Ｂにおいて、ａｃｋ４１５Ｃを時間４２０Ｃにおいて、ａｃｋ４１５Ｄを時間４２０Ｄにおいて受信する。
この例証的例では、伝送レートは、以下の式に基づいて決定されることができる。
レート＝（ＤＢ＋ＤＣ＋ＤＤ）／（時間４２０Ｄ−時間４２０Ａ）
状態テーブル等の他の手段も、この決定を行うために使用されることができることを理解されたい。
複数のデータパケットに対応する遅延させられた肯定応答が受信された場合、レート計算は、その遅延させられた肯定応答によって肯定応答された全てのデータパケットを含むように調節されることができる。例証的例として、ａｃｋ４１５Ｂおよび４１５Ｃが、受信されず、ａｃｋ４１５Ｄが、パケット４０５Ｂ、４０５Ｃ、および４０５Ｄに対応する、遅延させられた肯定応答である場合、伝送レート計算は、ａｃｋ４１５Ｄによって肯定応答されたパケット４０５Ｂ、４０５Ｃ、および４０５Ｄのサイズを考慮するように調節されることができる。この特定の例では、上記と同一式が、依然として、伝送レートを計算するために使用されることができる。
いくつかの実施形態では、伝送レートは、最小パスＲＴＴ等の他のパラメータに基づいて計算されることもでき、輻輳ウィンドウ値が、フローのＴＣＰ特性内に含まれる。そのような計算は、肯定応答の受信時間が伝送レート決定のためにまだ利用可能ではないとき、初期伝送レートを計算するために使用されることができる。
パケット４０５Ａ−Ｄが伝送された後、対応する肯定応答の受信を待つことなく、パケットグループの残りも、伝送レートに基づいて決定される伝送時間において、待ち行列の順序に従って伝送されることができる。例えば、図４に示されるように、パケット４０６Ａ−Ｄは、時間４１０Ｂにおいて伝送され、パケット４０７Ａ−Ｄは、時間４１０Ｃにおいて伝送され、パケット４０８Ａ−Ｄは、時間４１０Ｄにおいて伝送される。時間４１０Ａ、４１０Ｂ、４１０Ｃ、および４１０Ｄの各々は、ある時間間隔によって分離されることができる。ある場合、データパケット４０５Ａ−Ｄ、４０６Ａ−Ｄ、４０７Ａ−Ｄ、および４０８Ａ−Ｄの各グループは、同一サイズであることができるが、必須ではない。ある時間間隔の時間長と、データパケット４０５Ａ−Ｄ、４０６Ａ−Ｄ、４０７Ａ−Ｄ、および４０８Ａ−Ｄのデータサイズとの組み合わせは、伝送レートを反映することができる。例証的例として、データパケット４０５Ａ−Ｄ、４０６Ａ−Ｄ、４０７Ａ−Ｄ、および４０８Ａ−Ｄの各グループが同一サイズであり、時間４１０Ａ、４１０Ｂ、４１０Ｃ、および４１０Ｄ間の時間間隔の時間長が同じである場合、伝送レートは、データパケット４０５Ａ−Ｄのサイズと、データパケット４０５Ａ−Ｄの伝送時間（時間４１０Ａ）とデータパケット４０６Ａ−Ｄの伝送時間（時間４１０Ｂ）との間の時間間隔の時間長との間の比率によって反映されることができる。
いくつかの実施形態では、伝送レートは、ＲＴＴあたり約１回、または１ ＲＴＴより長い時間長の間に更新されることができる。例えば、図４を参照すると、パケット４０５Ａ−Ｄの伝送後の１ ＲＴＴの時間長内に受信された肯定応答が、収集されることができ、伝送レートが、それらの肯定応答の受信時間に基づいて計算されることができる。ある場合、ＲＴＴは、前に送信されるパケットの伝送時間と対応する肯定応答の受信時間との間の差異に基づいて、推定されることができる。例えば、ＲＴＴは、時間４２０Ａと４１０Ａとの間の差異（パケット４０５Ａおよびａｃｋ４１５Ａに対して）または他のパケット肯定応答ペアに対する伝送時間と受信時間との間（例えば、パケット４０５Ｂおよびａｃｋ４１５Ｂに対する時間４２０Ｂと４１０Ａとの間、パケット４０５Ｃおよびａｃｋ４１５Ｃに対する時間４２０Ｃと４１０Ａとの間、パケット４０５Ｄおよびａｃｋ４１５Ｄに対する時間４２０Ｄと４１０Ａとの間等）の差異に基づいて、推定されることができる。ＲＴＴは、平均化（例えば、任意の数のパケット４０５Ａ−Ｄに対するＲＴＴの平均化）およびフィルタ処理（例えば、パケット４０５Ａ−Ｄに関連付けられないＲＴＴの破棄、第１のデータパケットの他のＲＴＴと有意に異なるＲＴＴの破棄等）等、後処理されることができる。
有効測定が１ ＲＴＴの時間長内で利用可能ではない（例えば、肯定応答が受信されず、故に、肯定応答の受信時間がサンプリングされることができない）場合、伝送レートの更新は、スキップされることができる。そのような場合では、データパケットの次のグループの伝送時間は、例えば、前のＲＴＴにおいて決定された伝送レートに基づいて決定されることができる。例証的例として、肯定応答が、パケット４０６Ａ−Ｄの伝送時間（時間４１０Ｂ）の１ ＲＴＴ内で受信されない場合、次の伝送時間（時間４１０Ｃ）は、伝送時間４１０Ａと４１０Ｂとの間を分離する時間間隔を決定する同一伝送レートに基づいて決定されることができる。
いくつかの実施形態では、前述のように、伝送レートは、データパケットの同一グループに属する肯定応答のみに基づいて、更新されることができる。肯定応答がデータパケットの同一グループに属するかどうかの決定は、例えば、肯定応答内に含まれるシーケンス番号と対応するパケットの伝送時間とに基づくことができる。データパケットの同一グループに属さない肯定応答が、そのＲＴＴ内で受信される場合、伝送レートは、その肯定応答に対して更新されないであろう。例証的例として、時間４１０Ａ後の１ ＲＴＴ内において、データパケットの前のグループに対するストレッチ肯定応答が、ａｃｋ４１５Ａ−Ｄに加えて受信される場合、伝送レートは、そのストレッチ肯定応答の受信時間に基づいて更新されないであろう。
いくつかの実施形態では、伝送レートは、平均関数に基づいて更新されることができ、現在のＲＴＴに対して計算された伝送レートは、前のＲＴＴにおいて計算された伝送レートと平均される。平均は、ＲＴＴをまたいだ肯定応答の受信時間に基づいて行われることもできる。平均伝送レートは、次いで、パケットエンジン３２０に提供され、ネットワークへのデータの伝送を制御するであろう。いくつかの実施形態では、平均関数は、指数関数移動平均関数であることができ、伝送レートのより最近のサンプルは、例えば、比較的に離れた過去において決定された伝送レートのサンプルより大きい重みに関連付けられる。伝送レートが、現在のＲＴＴに対して計算されない（例えば、肯定応答受信時間の有効測定が、時間４１０Ａの１ ＲＴＴ内で利用可能ではない等）場合、平均伝送レートは、更新されないこともあり、データパケットの次のグループの伝送は、現在の平均伝送レートに基づいて制御されることができる。
いくつかの実施形態では、伝送レートの更新は、１つ以上の伝送されたパケットが、損失され、データ受信機４１２への到達に失敗したことの指示に基づいて、調節されることができる。指示は、例えば、アプライアンス１４０がデータ受信機４１２によって受信されたパケットのシーケンス番号を示す選択的肯定応答（ＳＡＣＫ）を受信することから生じることができる。ＳＡＣＫ内にリストアップされたシーケンス番号が、伝送されたパケットのシーケンス番号を含まない場合、レートベースのデータ伝送コントローラ３５０は、伝送されたパケットが損失されたことを決定することができる。パケット損失の別の可能な指示は、アプライアンス１４０が伝送後のある時間量内に伝送されたパケットに対する肯定応答の受信に失敗したことであり得る。両場合において、レートベースのデータ伝送コントローラ３５０は、計算のレートが現在のＲＴＴ内で受信された肯定応答の受信時間に基づいて計算されないこともあることを決定することができる。代わりに、前のＲＴＴ内で決定された伝送レートが、パケットエンジン３２０に提供され、データパケットの次のグループの伝送を制御することができる。いくつかの実施形態では、提供される伝送レートは、ネットワークのオーバーロードのリスクを軽減するために、所定の係数によってさらに低減させられることができる。
伝送レートが決定された後、レートベースのデータ伝送コントローラ３５０は、データパケットのグループにおいて伝送されるべきデータの総サイズを決定することができる。伝送されるべきデータの総サイズは、例えば、ダウンストリームネットワークノード（例えば、ルータ）の待ち行列サイズによって限定され得る。いくつかの実施形態では、前述のように、パケットエンジン３２０は、ＴＣＰフロー特性の一部として、データパケットの待ち行列遅延を決定することができる。レートベースのデータ伝送コントローラ３５０は、待ち行列遅延に基づいて、待ち行列サイズを推定し、ネットワークノードのオーバーロードおよびネットワークの輻輳のリスクを軽減するために、待ち行列サイズのある比率であるように伝送されるべきデータの総サイズを制御することができる。
データパケットのグループにおいて伝送されるべきデータの総サイズと伝送レートとに基づいて、レートベースのデータ伝送コントローラ３５０は、次いで、データパケットの各グループの伝送時間を分離する時間間隔とデータパケットの各グループのサイズとを決定することができる。ある場合、伝送時間を分離する時間間隔は、同じであることができるが、必須ではない。いくつかの実施形態では、データパケットの各グループは、レートベースのデータ伝送コントローラ３５０が他のエンティティ（例えば、ソフトウェアアプリケーション、別の物理的デバイス等）から受信したデータパケットの数を含むことができる。いくつかの実施形態では、レートベースのデータ伝送コントローラ３５０は、受信されたデータパケットのペイロードを抽出し、抽出されたペイロードを使用して、データパケットのグループを生成することもできる。ある場合、データパケットの各グループのサイズは、同じであることができるが、必須ではない。
図３Ａに戻って参照すると、データ伝送コントローラ３３０は、輻輳ウィンドウベースのデータ伝送コントローラ３６０も含む。いくつかの実施形態では、輻輳ウィンドウベースのデータ伝送コントローラ３６０は、パケットエンジン３２０によって計算される輻輳ウィンドウサイズに基づいて、１ ＲＴＴの時間長内でネットワークの中に伝送されるべきデータのサイズ（例えば、データパケットの数、パケットペイロードのサイズ等によって反映される）を決定することができる。輻輳ウィンドウサイズは、旧来のＴＣＰ輻輳回避アルゴリズムに基づいて、制御されることができる。輻輳ウィンドウベースのデータ伝送コントローラ３６０は、次いで、決定されたサイズのデータを１ ＲＴＴの時間長内でネットワークの中に伝送するように、パケットエンジン３２０を制御することができる。
いくつかの実施形態では、データ伝送制御コーディネータ３４０は、レートベースのデータ伝送コントローラ３５０および輻輳ウィンドウベースのデータ伝送コントローラ３６０の動作を調整することができる。例えば、データ伝送制御コーディネータ３４０は、１つ以上の基準の充足に基づいて、レートベースのデータ伝送コントローラ３５０がパケットエンジン３２０によるデータの伝送を制御することを可能にし、１つ以上の基準がもはや満たされないとき、制御を輻輳ウィンドウベースのデータ伝送コントローラ３６０に動的に与えることを決定することができる。
レートベースのデータ伝送コントローラ３５０がパケットエンジン３２０を制御することを可能にすべきか、輻輳ウィンドウベースのデータ伝送コントローラ３６０がパケットエンジン３２０を制御することを可能にすべきかを決定するための基準は、例えば、ネットワーク内で伝送されているパケットの数が少なくとも閾値と等しいことを含むことができる。例えば、接続が確立されたばかりであり、送信側デバイスが、少数のデータパケットのみを伝送し、少数の対応する肯定応答を受信しているとき、少数のデータパケットの伝送レートは、必ずしも、ネットワークの現在の性能を反映しない。そのような場合、データ伝送制御コーディネータ３４０は、少数の肯定応答の受信時間がネットワーク内のデータの伝送レートの正確な推定を提供しないことを決定することができる。その結果、データ伝送制御コーディネータ３４０は、より多くのデータパケットがネットワーク内で伝送されていることの指示を受信するまで、輻輳ウィンドウベースのデータ伝送コントローラ３６０がパケットエンジン３２０におけるデータパケットの伝送を制御することを可能にすることを決定することができる。いくつかの実施形態では、そのような指示は、例えば、輻輳ウィンドウサイズ（肯定応答が受信されるときに増加し得る）が少なくとも所定の閾値と等しいこと、または少なくとも閾値と等しいいくつかのデータパケットが伝送に成功したことを反映する任意の他のパラメータを含むことができる。
前述の基準は、例えば、１ ＲＴＴ内でレートベースのデータ伝送コントローラ３５０によってネットワークの中に伝送されるべきデータのサイズが少なくとも前述の閾値と等しいことを含むこともできる。データ伝送制御コーディネータ３４０は、例えば、決定された伝送レートに基づいて、決定を行うことができる。そのように決定された１ ＲＴＴ内で伝送されるべきデータのサイズは、レートベースのデータ伝送コントローラ３５０によって伝送されるべきデータパケットのグループの総サイズ（例えば、前述のように、ダウンストリームネットワークノードの待ち行列サイズに基づいて決定されることができる）より大きいことも、より小さいことも可能である。レートベースのデータ伝送コントローラ３５０の制御下で１ ＲＴＴ内で伝送されるべきデータのサイズが、前述の閾値未満である場合、データ伝送制御コーディネータ３４０は、レートベースの伝送を使用してＲＴＴ内でデータパケットのグループの伝送を完了するためにネットワークが遅すぎる（輻輳）ことを決定することができる。その結果、データ伝送制御コーディネータ３４０は、輻輳ウィンドウベースのデータ伝送コントローラ３６０がパケットエンジン３２０におけるデータパケットの伝送を制御することを可能にすることを決定することができる。その場合、輻輳ウィンドウベースのデータ伝送コントローラ３６０は、輻輳ウィンドウサイズを１ ＲＴＴ内で決定された伝送レートで伝送されるべきデータの量と等しくなるように設定することができる。ある場合、輻輳ウィンドウベースのデータ伝送コントローラ３６０は、１ ＲＴＴ内において、輻輳ウィンドウの前述のサイズに基づいて、ある数のデータパケットを伝送することができる。伝送されたデータパケットのうちの少なくとも１つの肯定応答を受信後、輻輳ウィンドウベースのデータ伝送コントローラ３６０は、次いで、輻輳ウィンドウのサイズを増加させ、次いで、輻輳ウィンドウの増加させられたサイズに基づいて、次の組のデータパケットを伝送することができる。
いくつかの実施形態では、データ伝送制御コーディネータ３４０は、レートベースのデータ伝送コントローラ３５０を選択するように事前に構成されることもできる。事前に構成された選択は、前述の基準のいずれかが満たされないとき、無効にされることができる。いくつかの実施形態では、データ伝送制御コーディネータ３４０は、前述の基準のうちの少なくともいくつかが満たされるとき、輻輳ウィンドウベースのデータ伝送コントローラ３６０を選択し、次いで、レートベースのデータ伝送コントローラ３５０に切り替えるように事前に構成されることもできる。
図３Ｂは、本開示の実施形態に準拠する、図３Ａに図示される例示的アプライアンス１４０の一部のブロック図である。いくつかの実施形態では、アプライアンス１４０のオペレーティングシステムは、利用可能なシステムメモリをカーネル空間（システム空間）およびユーザ空間（アプリケーション空間）と称されるものの中に配分、管理、または別様に分離する。カーネル空間は、典型的には、任意のデバイスドライバ、カーネル拡張子、または他のカーネル関連ソフトウェアを含むカーネルを起動させるために確保される。カーネルは、オペレーティングシステムのコアであり、アプライアンス１４０のリソースおよびハードウェア関連要素のアクセス、制御、および管理を提供することができる。アプライアンス１４０のいくつかの実施形態によると、カーネル空間は、パケットエンジン３２０、データ伝送コントローラ３３０、またはその任意の部分と共にいくつかのネットワークサービスまたはプロセス作業を含むことができる。加えて、カーネルの実施形態は、アプライアンス１４０によってインストール、構成、または別様に使用されるオペレーティングシステム次第であることができる。
ユーザ空間は、そうでなければユーザモードで起動する、ユーザモードアプリケーションまたはプログラムによって使用されるオペレーティングシステムのメモリエリアもしくは部分である。ユーザモードアプリケーションは、カーネル空間に直接アクセスすることができず、サービスコールを使用してカーネルサービスにアクセスする。オペレーティングシステムは、アプリケーションの実行または起動およびユーザレベルプログラム、サービス、プロセス、および／またはタスクのプロビジョニングのために、ユーザ空間を使用する。例として、オペレーティングシステムは、ユーザ空間内のネットワークインターフェース２１８Ａ−Ｎのソフトウェアを実行することができる。
図５は、本開示の実施形態に準拠する、データ伝送制御のための例示的実施形態のブロック図である。前述のように、データ伝送コントローラ３３０は、パケットデータ５５０のアクティブフローに関連する情報を含む、ＴＣＰ特性５３０等の１つ以上のＴＣＰ特性をパケットエンジン３２０から受信するように構成されることができる。ＴＣＰ特性５３０は、例えば、１つ以上の待ち行列遅延を含む情報、フロー輻輳を示す情報、１つ以上の輻輳ウィンドウサイズを示す情報、およびアクティブフロー４５０内のパケットに対する１つ以上の平均ラウンドトリップ時間を示す情報を含むことができる。フローは、パケットがＴＣＰリンクを横断して送信および受信されているとき、「アクティブ」である。
いくつかの実施形態によると、１つ以上のプロセッサ（例えば、ＣＰＵ２２１）が、データ伝送コントローラ３３０を実行する。データ伝送コントローラ３３０は、ＴＣＰ特性５３０を受信し、次いで、ＴＣＰ特性５３０（例えば、現在の輻輳ウィンドウサイズ）に基づいて、レートベースのデータ伝送制御がパケットエンジン３２０によるデータパケットの伝送を制御するために使用されるべきか、輻輳ウィンドウベースのデータ伝送制御がそうするために使用されるべきかを決定することができる。レートベースのデータ伝送制御が使用されるべき場合、データ伝送コントローラ３３０は、ＴＣＰ特性５３０（例えば、待ち行列遅延、肯定応答の受信時間等）に基づいて、伝送レートおよびその伝送レートにおいて伝送されるべきデータパケットのグループの総サイズを決定することもできる。データ伝送制御に関連するデータ（例えば、レートベースが使用されるべきか、または輻輳ウィンドウベースの制御が使用されるべきか、伝送時間、伝送されるべきデータのサイズ等）は、伝送構成５４０内に含まれることができ、それは、次いで、パケットエンジン３２０に提供されることができる。
図６は、本開示の実施形態に準拠する、データ伝送制御の例示的方法６００を表すフローチャートである。図示されるプロシージャが、ステップを削除する、またはさらに追加のステップを含むように改変されることができることは、容易に理解されるであろう。方法６００は、アプライアンス（例えば、アプライアンス１４０）によって行われるように説明されるが、方法６００は、単独で、またはアプライアンスと組み合わせて、他のデバイスによって行われることができることを理解されたい。
初期開始後、アプライアンス１４０は、ステップ６０５において、例えば、１つ以上のパケットエンジン（例えば、パケットエンジン３２０）を使用して、１つ以上のＴＣＰ特性を第１のデータパケットの現在の伝送から決定することができる。ＴＣＰ特性は、例えば、輻輳ウィンドウサイズ、ＲＴＴ、第１のデータパケットに対応する肯定応答の受信時間等を含むことができる。
ステップ６１０では、アプライアンス１４０は、次の伝送のための第２のデータパケットの組を受信することができる。アプライアンス１４０は、第２のデータパケットを、例えば、ソフトウェアアプリケーションまたはアプライアンス１４０と通信可能に結合される他の物理的デバイス（例えば、クライアントデバイス１３０Ａ−Ｃ）から受信することができる。いくつかの実施形態では、ステップ６１０は、ステップ６０５の前、後、またはそれと並行して生じることができる。
ステップ６１５では、アプライアンス１４０は、パケットの伝送を制御するために、レートベースのデータ伝送制御がパケットエンジン３２０において使用されるべきかどうかを決定する。前述のように、決定は、１つ以上の所定の基準が満たされるかどうかに基づくことができる。ある場合、基準は、例えば、肯定応答の受信時間がネットワーク内のデータの伝送レートの推定を提供し得るように、十分な数のデータパケットが伝送されているかどうかを含むことができる。そのような決定は、例えば、ＴＣＰ特性内に含まれる輻輳ウィンドウサイズ情報に基づくことができ、輻輳ウィンドウサイズ情報は、伝送および肯定応答されているデータパケットの数を反映し得る。基準は、輻輳ウィンドウサイズが少なくとも所定の閾値と等しいときに満たされることができる。さらに、ある場合、基準は、レートベースのデータ伝送コントローラ３５０によって１ ＲＴＴ内でネットワークの中に伝送されるべきデータのサイズが所定の閾値を超えることを含むこともでき、それは、レートベースのデータ伝送コントローラ３５０によって伝送されるべきデータをハンドリングするためにネットワークが十分な容量を有することを示し得る。いくつかの実施形態では、ステップ６１５は、図３Ａのデータ伝送制御コーディネータ３４０によって行われることができる。
アプライアンス１４０が、レートベースのデータ伝送制御が使用されるべきであることを決定する（ステップ６１５において）場合、ステップ６２０において、アプライアンス１４０は、第２のデータパケットの組を、例えば、パケットエンジン３２０において待ち行列に入れることができる。アプライアンス１４０は、次いで、ステップ６２５において受信された１つ以上のＴＣＰ特性に基づいて、第２のデータパケットの組のための伝送レートを決定することができる。前述のように、伝送レートは、例えば、図４に図示されるように、伝送されるデータパケットのサイズと対応する肯定応答の受信時間とに基づいて決定されることができる。肯定応答の受信時間がまだ利用可能ではない場合（例えば、初期伝送レートを計算するために）、伝送レートは、受信されたＴＣＰ特性内に含まれるＲＴＴおよび輻輳ウィンドウサイズ情報に基づいて決定されることもできる。さらに、伝送レートは、例えば、移動平均関数を使用して、事前に決定された伝送レートに基づいて決定されることもできる。ある場合、第２のデータパケットのための伝送レートは、例えば、肯定応答がパケットのグループの伝送の１ ＲＴＴ内で受信されないとき、またはパケット損失が検出されるとき、事前に決定された伝送レートに基づいて決定されることもできる。
伝送レートがステップ６２５において決定された後、レートベースのデータ伝送コントローラ３５０は、次いで、ステップ６３０において、パケットエンジン３２０における第２のデータパケットの伝送を制御することができる。前述のように、レートベースのデータ伝送コントローラ３５０は、待ち行列に入れられた第２のデータパケット（または第２のデータパケットから導出されるパケット）をグループにおいて伝送するように、パケットエンジン３２０を制御することができ、各グループの伝送時間は、ある時間間隔によって分離され、時間間隔は、ステップ６２５において決定された伝送レートに基づいて決定されることができる。パケットの各グループのサイズは、例えば、伝送レート、伝送されるべきデータの総サイズ等に基づいて決定されることもできる。レートベースのデータ伝送コントローラ３５０は、次いで、時間間隔およびデータサイズ情報をパケットエンジン３２０に伝送構成（例えば、伝送構成５４０）の一部として伝送することができる。パケットエンジン３２０は、次いで、伝送構成に基づいて、データを伝送することができる。
一方、データ伝送制御コーディネータ３４０が、ステップ６１５において、輻輳ウィンドウベースのデータ伝送制御が使用されるべきであることを決定する場合、輻輳ウィンドウベースのデータ伝送コントローラ３６０は、次いで、ステップ６３５において、１ ＲＴＴ内における伝送のためのある数の第２のデータパケットをパケットエンジン３２０に提供することができる。提供される第２のデータパケットの数は、輻輳ウィンドウサイズに基づいて決定されることができる。ある場合、輻輳ウィンドウサイズは、ＴＣＰ特性内に含まれる輻輳ウィンドウサイズ情報に基づいて決定されることができる。ある場合、輻輳ウィンドウサイズは、事前に決定された伝送レートにおける１ ＲＴＴ内で伝送されるべきデータのサイズの推定に基づいて決定されることができる。
図７Ａ−７Ｃは、本開示の実施形態に準拠する、データ伝送制御の例示的方法７００を表す、フローチャートである。図示されるプロシージャが、ステップを削除する、またはさらに追加のステップを含むように改変されることができることは、容易に理解されるであろう。方法７００は、アプライアンス（例えば、アプライアンス１４０）によって行われるように説明されるが、方法７００は、単独で、またはアプライアンスと組み合わせて、他のデバイスによって行われることもできることを理解されたい。
初期開始後、アプライアンス１４０は、ステップ７０５において、例えば、１つ以上のパケットエンジン（例えば、パケットエンジン３２０）を使用して、第１のデータパケットの組を伝送することができる。第１のデータパケットの伝送後、アプライアンス１４０は、ステップ７１０において、第１のデータパケットの組に対応する肯定応答を監視および受信することができる。
ステップ７１０における肯定応答の受信後、アプライアンス１４０は、次いで、ステップ７１５において、受信された肯定応答が、第１のデータパケットのうちの１つ以上のものが、損失され、受信側（例えば、データ受信機４１２）への到達に失敗したことを示すかどうかを決定することができる。前述のように、パケット損失の指示は、例えば、アプライアンス１４０がデータ受信機４１２によって受信されたパケットのシーケンス番号を示すＳＡＣＫを受信することから生じ得る。ＳＡＣＫからの情報に基づいて、アプライアンス１４０は、次いで、第１のデータパケットのうちの１つ以上のものがデータ受信機４１２によって受信されず、損失されたことを決定することができる。パケット損失の指示は、アプライアンス１４０が伝送後のある時間量（例えば、予期されるＲＴＴ）内に伝送されたパケットに対する肯定応答を受信しないことからも生じ得る。
アプライアンス１４０が、伝送された第１のデータパケットのうちのいずれも損失されていないことを決定する場合（ステップ７１５）、アプライアンス１４０は、次いで、図７Ｂのステップ７２２に進むことができ、そこで、アプライアンス１４０は、次の伝送のための第２のデータパケットの組を受信することができる。アプライアンス１４０は、次いで、ステップ７２４において、第１のデータパケットの伝送のＲＴＴを決定することができる。決定は、例えば、第１のデータパケットの伝送時間および対応する肯定応答の受信時間に基づくことができる。ＲＴＴは、平均（例えば、ある数の第１のデータパケットに対するＲＴＴの平均）およびフィルタ処理（例えば、第１のデータパケットに関連付けられないＲＴＴの破棄、第１のデータパケットの他のＲＴＴと有意に異なるＲＴＴの破棄等）等、後処理されることができる。いくつかの実施形態では、受信ステップ７２２は、決定ステップ７２４後に生じることができる。
第１のデータパケットの伝送のＲＴＴが、決定された後（ステップ７２４）、アプライアンス１４０は、次いで、ステップ７２６において、レートベースの伝送制御が第２のデータパケットの次の伝送のために使用されるべきかどうかを決定することができる。上で議論されたように、決定は、異なる要因に基づくことができる。例えば、接続が確立されたばかりであるとき、レートベースの伝送制御は、輻輳ウィンドウサイズが、測定された伝送レートが実際のネットワーク性能を反映し得るように、十分な数のパケットがネットワーク内で伝送されていることを示し得る所定の閾値に到達するまで使用されない。決定は、例えば、アプライアンス１４０がレートベースの伝送を使用するように事前に構成されるかどうかに基づくことができる。いくつかの実施形態では、ステップ７２６は、データ伝送制御コーディネータ３４０によって行われることができる。
データ伝送制御コーディネータ３４０が、レートベースの伝送制御が第２のデータパケットの伝送のために使用されるべきことを決定する場合（ステップ７２６）、レートベースのデータ伝送コントローラ３５０は、次いで、ステップ７２８において、伝送レートを決定することができる。決定は、例えば、図４に図示されるように、第１のデータパケットのサイズおよび対応する肯定応答の受信時間に基づくことができる。肯定応答の受信時間がまだ利用可能ではない場合（例えば、初期伝送レートを計算するために）、伝送レートは、ＲＴＴおよび輻輳ウィンドウサイズに基づいて決定されることができる。さらに、伝送レートは、例えば、移動平均関数を使用して、事前に決定された伝送レートに基づいて決定されることができる。ある場合、第２のデータパケットのための伝送レートは、例えば、肯定応答が第１のデータパケットの伝送の１ ＲＴＴ内で受信されないとき、事前に決定された伝送レートに基づいて決定されることができる。
第２のデータパケットのための伝送レートが決定された後（ステップ７２８）、レートベースのデータ伝送コントローラ３５０は、次いで、ステップ７３０において、１ ＲＴＴ（ステップ７２４おいて決定された）が、例えば、第１のデータパケットの伝送から経過したかどうかを決定することができる。上で議論されるように、伝送レートは、ＲＴＴ毎に１回または１ ＲＴＴより長い時間長の間に更新されることができる。いくつかの実施形態では、レートベースのデータ伝送コントローラ３５０が、ステップ７３０において、１ ＲＴＴが経過していないことを決定する場合、１ ＲＴＴが経過するまで、ステップ７２８において決定された伝送レートを使用せずに、終了に進むことができる。
一方、レートベースのデータ伝送コントローラ３５０が、ステップ７３０において、少なくとも１ ＲＴＴが経過したことを決定する場合、ステップ７３２において、伝送されるべき第２のデータパケットの各グループの伝送時間およびサイズを決定することができる。上で議論されるように、第２のデータパケットは、グループにおいて送信されることができ、各グループの伝送時間は、ある時間間隔によって分離される。レートベースのデータ伝送コントローラ３５０は、例えば、ステップ７２８において決定された伝送レートに基づいて、伝送時間を決定することができる。例えば、上で議論されるように、伝送されているデータパケットのグループのサイズと時間間隔の時間長との間の比率は、伝送レートを反映することができる。レートベースのデータ伝送コントローラ３５０は、例えば、ネットワークノードにおける待ち行列遅延を反映し得るステップ７２４において決定されたＲＴＴ情報に基づくそのダウンストリームネットワークノード（例えば、ルータ）における待ち行列サイズの推定に基づいて、伝送されるべきデータパケットのグループのサイズを決定することができる。ある場合、パケットの各グループのデータサイズは、同じであることができる。ある場合、伝送時間は、同じ時間間隔によって分離されることができる。パケット情報の伝送時間およびサイズが、ステップ７３２において決定された後、レートベースのデータ伝送コントローラ３５０は、次いで、情報をパケットエンジン３２０に構成データ（例えば、伝送構成５４０）の形態で提供することができる。パケットエンジン３２０は、次いで、ステップ７３４において、第２のデータパケットをグループで伝送することができる。
一方、データ伝送制御コーディネータ３４０が、ステップ７２６において、レートベースの伝送制御が第２のデータパケットの次の伝送のために使用されるべきではないことを決定する場合（例えば、輻輳ウィンドウベースの伝送制御を使用するための事前構成に起因して）、次いで、ステップ７３６において、１ ＲＴＴ中にレートベースの伝送を使用して伝送されるデータのサイズ（ステップ７２４において決定された）が少なくとも閾値と等しいかどうかを決定することができる。前述のように、決定は、ネットワークが決定された伝送レートにおいて伝送されるデータをハンドリングするための容量を有するかどうかについての指示を提供することができる。データ伝送制御コーディネータ３４０が、ステップ７３６において、１ ＲＴＴ中にレートベースの伝送を使用して伝送されるデータのサイズが少なくとも閾値と等しいことを決定する場合、ステップ７２８に進み、レートベースのデータ伝送コントローラ３５０が第２のデータパケットの伝送を制御することを可能にすることができる。
データ伝送制御コーディネータ３４０が、１ ＲＴＴ中にレートベースの伝送を使用して伝送されるデータのサイズが閾値を超えないことを決定する場合（ステップ７３６）、輻輳ウィンドウベースのデータ伝送コントローラ３６０が第２のデータパケットの伝送を制御することを可能にするように進むことができる。パケットエンジン３２０は、例えば、旧来のＴＣＰ輻輳回避アルゴリズムに従って受信された肯定応答に基づいて、または事前に決定された伝送レートにおいて１ ＲＴＴ内で伝送されるべき推定されたデータのサイズに基づいて、輻輳ウィンドウサイズを決定することができる。輻輳ウィンドウベースのデータ伝送コントローラ３６０は、次いで、輻輳ウィンドウサイズに基づいて、伝送のために、ある数の第２のデータパケットをパケットエンジン３２０に提供することができる。パケットエンジン３２０は、次いで、ステップ７３８において、その数の第２のデータパケットを伝送することができる。いくつかの実施形態では（図７Ｂには図示せず）、ステップ７３８において、その数の第２のデータパケットが伝送される、１ ＲＴＴ中、増加させられた輻輳ウィンドウサイズが所定の閾値を超えるように、輻輳ウィンドウが増加させられる場合（例えば、ステップ７３８に先立って、またはその間、伝送されるデータパケットに対応する肯定応答の受信に起因して）、データ伝送制御コーディネータ３４０は、レートベースの伝送に切り替わることを決定し、ステップ７２８に戻ることができる。
図７Ａに戻って参照すると、アプライアンス１４０が、ステップ７１５において、伝送される第１のデータパケットのうちの少なくとも１つが損失されていることを決定する場合、アプライアンス１４０は、図７Ｃのステップ７５２に進むことができ、そこで、アプライアンス１４０は、次の伝送のために、第２のデータパケットの組を受信することができる。アプライアンス１４０は、次いで、ステップ７５４において、前のＲＴＴにおいて決定された伝送レートに基づいて、第２のデータパケットのための伝送レートを決定することができる。ある場合、決定された伝送レートは、ある係数によってさらに低減させられ、ネットワークのオーバーロードのリスクを軽減することができる。
伝送レートが決定された後、アプライアンス１４０（例えば、データ伝送制御コーディネータ３４０）は、次いで、ステップ７５６において、１ ＲＴＴ中にレートベースの伝送を用いて伝送されるデータのサイズ（ステップ７２４において計算される）が少なくとも閾値と等しいかどうかを決定することができる。ステップ７５６における決定は、図７Ｂのステップ７３６に説明されるものと類似し、その詳細は、ここでは繰り返されない。
データ伝送制御コーディネータ３４０が、１ ＲＴＴ中にレートベースの伝送を用いて伝送されるデータのサイズが少なくとも閾値と等しいことを決定する場合（ステップ７５６）、次いで、レートベースのデータ伝送コントローラ３５０が、ステップ７５４において決定された伝送レートに基づいて、第２のデータパケットの伝送を制御することを可能にするように進むことができる。ステップ７５８では、レートベースのデータ伝送コントローラ３５０は、レートベースの伝送のための第２のデータパケットのグループの伝送時間およびサイズを決定することができる。パケットエンジン３２０は、次いで、ステップ７６０において、第２のデータパケットのグループを伝送することができる。ステップ７５８および７６０は、図７Ｂのステップ７３２および７３４に類似し、その詳細は、ここでは繰り返されない。
一方、データ伝送制御コーディネータ３４０が、ステップ７５６において、１ ＲＴＴ中にレートベースの伝送を用いて伝送されるデータのサイズが閾値を超えないことを決定する場合、輻輳ウィンドウベースのデータ伝送コントローラ３６０が第２のデータパケットの伝送を制御することを可能にするように進むことができる。パケットエンジン３２０は、例えば、旧来のＴＣＰ輻輳回避アルゴリズムに従って受信された肯定応答に基づいて、またはステップ７５４において決定された伝送レートにおいて１ ＲＴＴ内で伝送されるべき推定されたデータのサイズに基づいて、輻輳ウィンドウサイズを決定することができる。輻輳ウィンドウベースのデータ伝送コントローラ３６０は、次いで、ステップ７６２において、輻輳ウィンドウサイズに基づいて、１ ＲＴＴ内における伝送のために、ある数の第２のデータパケットをパケットエンジン３２０に提供することができる。いくつかの実施形態では（図７Ｃには図示せず）、ステップ７６２において、その数の第２のデータパケットが輻輳ウィンドウを使用して伝送される１ ＲＴＴ中、増加させられた輻輳ウィンドウサイズが所定の閾値を超えるように輻輳ウィンドウが増加させられる場合（例えば、ステップ７６２に先立って、またはその間、伝送されるデータパケットに対応する肯定応答の受信に起因して）、データ伝送制御コーディネータ３４０は、レートベースの伝送に切り替わることを決定し、ステップ７５８に戻ることができる。
本開示の実施形態を用いることで、データは、実際のネットワーク性能を反映する伝送レートで伝送されることができる。その結果、データの伝送は、帯域幅および待ち時間変動、不規則パケット、ストレッチ肯定応答等によって殆ど影響されず、それらは、旧来のＴＣＰ輻輳制御機構下において、無線ネットワークに一般的であり、パケット損失がネットワーク輻輳および輻輳ウィンドウサイズの対応する変化に起因するという正しくない決定につながり得る。データの伝送レートは、次いで、ランダムパケット損失に照らして、維持されることができ、ネットワークのオーバーロードおよび過小利用の両方が、回避されることができる。そのような配置は、ネットワーク性能も劣化させ得る接続における主なバーストを回避することができる。ネットワークデータフローの効率は、その結果、改良されることができる。
前述の明細書では、実施形態が、実装毎に変動し得る多数の具体的詳細を参照して説明された。説明される実施形態のある適応および修正が行われることができる。他の実施形態は、本明細書に開示される実施形態の仕様および実践の検討から当業者に明白となり得る。明細書および実施例は、例示にすぎないものとして見なされることが意図される。また、図に示されるステップのシーケンスは、例証目的のために意図されるものであり、ステップの任意の特定のシーケンスに限定されることを意図するものではない。したがって、当業者は、これらのステップが、同一方法を実装しながら、異なる順序で行われることができることを理解し得る。

Claims (33)

  1. データ伝送を制御するためのアプライアンスであって、前記アプライアンスは、
    リンクを経由した第１のデータパケットのフローに関するデータを取得し、前記フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定するように構成されているパケットエンジンと、
    データ伝送コントローラと
    を備え、
    前記データ伝送コントローラは、
    第２のデータパケットを受信することと、
    前記ＴＣＰ特性に基づいて、伝送レートを決定することと、
    １つ以上の基準に基づいて、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきかどうかを決定することと、
    レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきであることの決定に応答して、前記パケットエンジンに前記第２のデータパケットをグループで伝送させることと
    を行うように構成され、
    前記第２のデータパケットの各グループの伝送時間は、前記伝送レートに基づいて決定される、アプライアンス。
  2. 前記ＴＣＰ特性は、前記リンクに関連付けられたネットワークノードにおける待ち行列遅延についての情報を含み、前記第２のデータパケットの前記グループのサイズは、前記待ち行列遅延に基づいて決定される、請求項１に記載のアプライアンス。
  3. 前記ＴＣＰ特性は、前記リンクのラウンドトリップ時間（ＲＴＴ）および輻輳ウィンドウサイズについての情報を含み、前記伝送レートは、前記ＲＴＴおよび前記輻輳ウィンドウサイズに基づいて決定される、請求項１または２に記載のアプライアンス。
  4. 前記ＴＣＰ特性は、前記第１のデータパケットのうちの少なくともいくつかに対応する肯定応答の受信時間を含み、前記伝送レートは、前記第１のデータパケットのうちの前記少なくともいくつかのデータサイズと前記受信時間のうちの少なくともいくつかとに基づいて決定される、請求項１−３のいずれか１項に記載のアプライアンス。
  5. 前記伝送レートは、前に決定された１つ以上の伝送レートを使用して決定される、請求項１−３のいずれか１項に記載のアプライアンス。
  6. 前記データ伝送コントローラは、パケット損失の検出に基づいて、前記伝送レートが前に決定された前記１つ以上の伝送レートに基づいて決定されるべきであることを決定するように構成されている、請求項５に記載のアプライアンス。
  7. 前記データ伝送コントローラは、前記伝送レートがストレッチ肯定応答の受信時間に基づいて決定されるべきではないことを決定するように構成されている、請求項５または６に記載のアプライアンス。
  8. 前記データ伝送コントローラは、前記第１のデータパケットのうちの１つ以上のものの伝送後、前記第１のデータパケットのうちのいずれかに対応する肯定応答が前記リンクのラウンドトリップ時間（ＲＴＴ）に関連する期間内に受信されないことの決定に基づいて、前記伝送レートが前に決定された前記１つ以上の伝送レートに基づいて決定されるべきであることを決定するように構成されている、請求項５−７のいずれか１項に記載のアプライアンス。
  9. 前記１つ以上の基準は、前記輻輳ウィンドウサイズが少なくとも閾値と等しいことを含み、前記データ伝送コントローラは、前記輻輳ウィンドウサイズが前記閾値より小さいことの決定に応答して、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことを決定するように構成されている、請求項３に記載のアプライアンス。
  10. 前記１つ以上の基準は、前記決定された伝送レートで前記ＲＴＴ内に伝送されることが可能なデータの第１のサイズが少なくとも閾値と等しいことを含み、前記データ伝送コントローラは、
    前記第１のサイズを決定することと、
    前記第１のサイズが前記閾値より小さいかどうかを決定することと、
    前記第１のサイズが前記閾値より小さいことの決定に応答して、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことを決定することと
    を行うように構成されている、請求項３または９に記載のアプライアンス。
  11. 前記データ伝送コントローラは、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことの決定に応答して、前記パケットエンジンにある数の前記第２のデータパケットを伝送させ、前記数は、前記輻輳ウィンドウサイズに基づいて決定されるように構成されている、請求項３、９、または１０のいずれか１項に記載のアプライアンス。
  12. データ伝送を制御する方法であって、前記方法は、
    リンクを経由した第１のデータパケットのフローに関するデータを取得することと、
    前記フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定することと、
    第２のデータパケットを受信することと、
    前記ＴＣＰ特性に基づいて、伝送レートを決定することと、
    １つ以上の基準に基づいて、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきかどうかを決定することと、
    レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきであることの決定に応答して、前記第２のデータパケットをグループで伝送することと
    を含み、
    第２のデータパケットの各グループの伝送時間は、前記伝送レートに基づいて決定される、方法。
  13. 前記ＴＣＰ特性は、前記リンクに関連付けられたネットワークノードにおける待ち行列遅延についての情報を含み、前記第２のデータパケットの前記グループのサイズは、前記待ち行列遅延に基づいて決定される、請求項１２に記載の方法。
  14. 前記ＴＣＰ特性は、前記リンクのラウンドトリップ時間（ＲＴＴ）および輻輳ウィンドウサイズについての情報を含み、前記伝送レートは、前記ＲＴＴおよび前記輻輳ウィンドウサイズに基づいて決定される、請求項１２または１３に記載の方法。
  15. 前記ＴＣＰ特性は、前記第１のデータパケットのうちの少なくともいくつかに対応する肯定応答の受信時間を含み、前記伝送レートは、前記第１のデータパケットのうちの前記少なくともいくつかのデータサイズと前記受信時間のうちの少なくともいくつかとに基づいて決定される、請求項１２−１４のいずれか１項に記載の方法。
  16. 前記伝送レートは、前に決定された１つ以上の伝送レートを使用して決定される、請求項１２−１５のいずれか１項に記載の方法。
  17. パケット損失の検出に基づいて、前記伝送レートが前に決定された前記１つ以上の伝送レートに基づいて決定されるべきであることを決定することをさらに含む、請求項１６に記載の方法。
  18. 前記伝送レートがストレッチ肯定応答の受信時間に基づいて決定されるべきではないことを決定することをさらに含む、請求項１６または１７に記載の方法。
  19. 前記第１のデータパケットのうちの１つ以上のものの伝送後、前記第１のデータパケットのうちのいずれかに対応する肯定応答が前記リンクのラウンドトリップ時間（ＲＴＴ）に関連する期間内に受信されないことの決定に基づいて、前記伝送レートが前に決定された前記１つ以上の伝送レートに基づいて決定されるべきであることを決定することをさらに含む、請求項１６−１８のいずれか１項に記載の方法。
  20. 前記１つ以上の基準は、前記輻輳ウィンドウサイズが少なくとも閾値と等しいことを含み、前記輻輳ウィンドウサイズが前記閾値より小さいことの決定に応答して、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことを決定することをさらに含む、請求項１４に記載の方法。
  21. 前記１つ以上の基準は、前記決定された伝送レートで前記ＲＴＴ内に伝送されることが可能なデータの第１のサイズが少なくとも閾値と等しいことを含み、前記方法は、
    前記第１のサイズを決定することと、
    前記第１のサイズが前記閾値より小さいかどうかを決定することと、
    前記第１のサイズが前記閾値より小さいことの決定に応答して、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことを決定することと
    をさらに含む、請求項１４または２０に記載の方法。
  22. レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことの決定に応答して、ある数の前記第２のデータパケットを伝送することをさらに含み、前記数は、前記輻輳ウィンドウサイズに基づいて決定される、請求項１４、２０、または２１のいずれか１項に記載の方法。
  23. アプライアンスの少なくとも１つのプロセッサによって実行可能である命令の組を記憶している非一過性コンピュータ読み取り可能な記憶媒体であって、前記命令の組は、前記アプライアンスにデータ伝送を制御する方法を行わせ、前記方法は、
    リンクを経由した第１のデータパケットのフローに関するデータを取得することと、
    前記フローに対するトランスポート通信プロトコル（ＴＣＰ）特性を決定することと、
    第２のデータパケットを受信することと、
    前記ＴＣＰ特性に基づいて、伝送レートを決定することと、
    １つ以上の基準に基づいて、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきかどうかを決定することと、
    レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきであることの決定に応答して、前記第２のデータパケットをグループで伝送することと
    を含み、
    前記第２のデータパケットの各グループの伝送時間は、前記伝送レートに基づいて決定される、非一過性コンピュータ読み取り可能な記憶媒体。
  24. 前記ＴＣＰ特性は、前記リンクに関連付けられたネットワークノードにおける待ち行列遅延についての情報を含み、前記第２のデータパケットの前記グループのサイズは、前記待ち行列遅延に基づいて決定される、請求項２３に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  25. 前記ＴＣＰ特性は、前記リンクのラウンドトリップ時間（ＲＴＴ）および輻輳ウィンドウサイズについての情報を含み、前記伝送レートは、前記ＲＴＴおよび前記輻輳ウィンドウサイズに基づいて決定される、請求項２３または２４に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  26. 前記ＴＣＰ特性は、前記第１のデータパケットのうちの少なくともいくつかに対応する肯定応答の受信時間を含み、前記伝送レートは、前記第１のデータパケットのうちの前記少なくともいくつかのデータサイズと前記受信時間のうちの少なくともいくつかとに基づいて決定される、請求項２３−２５のいずれか１項に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  27. 前記伝送レートは、前に決定された１つ以上の伝送レートを使用して決定される、請求項２３−２６のいずれか１項に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  28. 前記アプライアンスの前記少なくとも１つのプロセッサによって実行可能である前記命令の組は、
    パケット損失の検出に基づいて、前記伝送レートが前に決定された前記１つ以上の伝送レートに基づいて決定されるべきであることを決定することを前記アプライアンスにさらに行わせる、請求項２７に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  29. 前記アプライアンスの前記少なくとも１つのプロセッサによって実行可能である前記命令の組は、
    前記伝送レートがストレッチ肯定応答の受信時間に基づいて決定されるべきではないことを決定することを前記アプライアンスにさらに行わせる、請求項２７または２８に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  30. 前記アプライアンスの前記少なくとも１つのプロセッサによって実行可能である前記命令の組は、前記第１のデータパケットのうちの１つ以上のものの伝送後、前記第１のデータパケットのうちのいずれかに対応する肯定応答が前記リンクのラウンドトリップ時間（ＲＴＴ）に関連する期間内に受信されないことの決定に基づいて、前記伝送レートが前に決定された前記１つ以上の伝送レートに基づいて決定されるべきであることを決定することを前記アプライアンスにさらに行わせる、請求項２７−２９のいずれか１項に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  31. 前記１つ以上の基準は、前記輻輳ウィンドウサイズが少なくとも閾値と等しいことを含み、前記アプライアンスの前記少なくとも１つのプロセッサによって実行可能である前記命令の組は、前記輻輳ウィンドウサイズが前記閾値より小さいことの決定に応答して、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことを決定することを前記アプライアンスにさらに行わせる、請求項２５に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  32. 前記１つ以上の基準は、前記決定された伝送レートで前記ＲＴＴ内に伝送されることが可能なデータの第１のサイズが少なくとも閾値と等しいことを含み、前記アプライアンスの前記少なくとも１つのプロセッサによって実行可能である前記命令の組は、
    前記第１のサイズを決定することと、
    前記第１のサイズが前記閾値より小さいかどうかを決定することと、
    前記第１のサイズが前記閾値より小さいことの決定に応答して、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことを決定することと
    を前記アプライアンスにさらに行わせる、請求項２５または３１に記載の非一過性コンピュータ読み取り可能な記憶媒体。
  33. 前記アプライアンスの前記少なくとも１つのプロセッサによって実行可能である前記命令の組は、レートベースのデータ伝送制御が前記第２のデータパケットの伝送を制御するために使用されるべきではないことの決定に応答して、ある数の前記第２のデータパケットを伝送することを前記アプライアンスにさらに行わせ、前記数は、前記輻輳ウィンドウサイズに基づいて決定される、請求項２５、３１、または３２のいずれか１項に記載の非一過性コンピュータ読み取り可能な記憶媒体。
JP2018516778A 2015-10-21 2016-10-18 ネットワークを介するレートベースパケット伝送のためのシステムおよび方法 Expired - Fee Related JP6510142B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/919,317 2015-10-21
US14/919,317 US9992120B2 (en) 2015-10-21 2015-10-21 System and method for rate-based packet transmission over a network
PCT/US2016/057549 WO2017070119A1 (en) 2015-10-21 2016-10-18 System and method for rate-based packet transmission over a network

Publications (3)

Publication Number Publication Date
JP2018531552A true JP2018531552A (ja) 2018-10-25
JP2018531552A6 JP2018531552A6 (ja) 2018-12-13
JP6510142B2 JP6510142B2 (ja) 2019-05-08

Family

ID=57209927

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018516778A Expired - Fee Related JP6510142B2 (ja) 2015-10-21 2016-10-18 ネットワークを介するレートベースパケット伝送のためのシステムおよび方法

Country Status (6)

Country Link
US (2) US9992120B2 (ja)
EP (1) EP3366013B1 (ja)
JP (1) JP6510142B2 (ja)
KR (1) KR102059283B1 (ja)
CN (1) CN108353032B (ja)
WO (1) WO2017070119A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017079412A (ja) * 2015-10-20 2017-04-27 富士通株式会社 パケット解析プログラム、パケット解析装置およびパケット解析方法
CN110300069B (zh) * 2018-03-22 2022-03-29 华为技术有限公司 数据传输方法、优化装置及系统
WO2019222880A1 (zh) * 2018-05-21 2019-11-28 华为技术有限公司 网络设备的配置方法及装置、存储介质
KR102139378B1 (ko) 2018-11-20 2020-07-29 울산과학기술원 혼잡 제어 방법 및 장치
CN110048906B (zh) * 2019-03-27 2021-04-02 网宿科技股份有限公司 一种判断节点传输质量的方法、系统、装置及服务器
US10999206B2 (en) 2019-06-27 2021-05-04 Google Llc Congestion control for low latency datacenter networks
CN113285891B (zh) * 2020-02-20 2022-10-28 瑞昱半导体股份有限公司 用于过载式网络交换的带宽分配装置与相关网络交换装置
US11979330B2 (en) 2020-06-22 2024-05-07 Google Llc Rate update engine for reliable transport protocol
CN112019447B (zh) * 2020-08-19 2024-06-25 博锐尚格科技股份有限公司 数据流量控制方法、装置、系统、电子设备、及存储介质
CN112333680B (zh) * 2020-10-20 2023-06-20 迅镭(广州)智能科技股份有限公司 基于蓝牙底座的数据传输方法及相关设备
US11616730B1 (en) * 2021-10-01 2023-03-28 Compira Labs Ltd. System and method for adapting transmission rate computation by a content transmitter
CN115277556A (zh) * 2022-06-21 2022-11-01 网宿科技股份有限公司 拥塞控制方法、电子设备及可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009089416A (ja) * 2008-11-21 2009-04-23 Sony Corp 通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラム
WO2014069642A1 (ja) * 2012-11-05 2014-05-08 日本電気株式会社 通信装置、送信データ出力制御方法、及びそのプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512066B2 (en) * 2004-03-30 2009-03-31 Hewlett-Packard Development Company, L.P. Congestion control system
US7983156B1 (en) * 2004-11-12 2011-07-19 Openwave Systems Inc. System and method for controlling network congestion
US8553540B2 (en) * 2010-03-05 2013-10-08 Microsoft Corporation Congestion control for delay sensitive applications
US8570864B2 (en) 2010-12-17 2013-10-29 Microsoft Corporation Kernel awareness of physical environment
EP2684390A4 (en) * 2011-03-10 2015-02-25 Optis Cellular Technology Llc HYBRID OVERLOAD CONTROL
US20140281018A1 (en) * 2013-03-13 2014-09-18 Futurewei Technologies, Inc. Dynamic Optimization of TCP Connections

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009089416A (ja) * 2008-11-21 2009-04-23 Sony Corp 通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラム
WO2014069642A1 (ja) * 2012-11-05 2014-05-08 日本電気株式会社 通信装置、送信データ出力制御方法、及びそのプログラム
US20150304226A1 (en) * 2012-11-05 2015-10-22 Nec Corporation Communication device, transmission data output control method, and program for same

Also Published As

Publication number Publication date
CN108353032A (zh) 2018-07-31
US9992120B2 (en) 2018-06-05
EP3366013B1 (en) 2020-08-19
US20180262430A1 (en) 2018-09-13
JP6510142B2 (ja) 2019-05-08
US20170118120A1 (en) 2017-04-27
WO2017070119A1 (en) 2017-04-27
CN108353032B (zh) 2022-03-04
US10659367B2 (en) 2020-05-19
EP3366013A1 (en) 2018-08-29
KR20180054800A (ko) 2018-05-24
KR102059283B1 (ko) 2019-12-24

Similar Documents

Publication Publication Date Title
US10659367B2 (en) System and method for rate-based packet transmission over a network
JP2018531552A6 (ja) ネットワークを介するレートベースパケット伝送のためのシステムおよび方法
US11470011B2 (en) System for bandwidth optimization with traffic priority determination
US10594609B2 (en) System and method of providing improved throughput control under delay-based congestion situation in a network
US11582163B2 (en) System for early system resource constraint detection and recovery
US9929956B2 (en) System for bandwidth optimization with initial congestion window determination
US10158575B2 (en) System for bandwidth optimization with high priority traffic awareness and control
JP2020502948A (ja) パケット伝送システムおよび方法
JP2019520745A (ja) 同時接続の総スループットを改善するためのシステム及び方法
JP5867160B2 (ja) 通信制御装置、通信制御方法および通信制御プログラム
EP3961981A1 (en) Method and device for congestion control, communication network, and computer storage medium
US20180070263A1 (en) Supporting Delivery of Data Packets Using Transmission Control Protocol in a Wireless Communication Network
EP4145780A1 (en) Method for controlling network congestion and network device
US9819591B2 (en) System and method of providing compression technique for jitter sensitive application through multiple network links
US20160255004A1 (en) System for dynamic selection and application of tcp congestion avoidance flavors
US9544249B2 (en) Apparatus and method for aligning order of received packets
JPWO2014171543A1 (ja) データ送信装置、データ送信方法、及びそのプログラム
JP6200870B2 (ja) データ転送制御装置、方法及びプログラム
WO2017041569A1 (zh) 业务数据传输方法及装置
Tekala et al. Throughput analysis of Scalable TCP congestion control

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180528

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190307

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: 20190314

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190403

R150 Certificate of patent or registration of utility model

Ref document number: 6510142

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees