JP2022545179A - データパケット通信を管理するためのシステムおよび方法 - Google Patents
データパケット通信を管理するためのシステムおよび方法 Download PDFInfo
- Publication number
- JP2022545179A JP2022545179A JP2022506839A JP2022506839A JP2022545179A JP 2022545179 A JP2022545179 A JP 2022545179A JP 2022506839 A JP2022506839 A JP 2022506839A JP 2022506839 A JP2022506839 A JP 2022506839A JP 2022545179 A JP2022545179 A JP 2022545179A
- Authority
- JP
- Japan
- Prior art keywords
- data packets
- packets
- packet
- data
- timestamps
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
- H04L45/245—Link aggregation, e.g. trunking
-
- 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
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
- H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- 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
- 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/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
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
-
- 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/41—Flow control; Congestion control by acting on aggregated flows or links
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
種々の実施形態において、1つ以上のデータパケットが、マルチパスネットワークリンクのセットにわたって通信されているデータパケット送達フローを管理するためのシステムが説明され、システムは、一緒に動作するマルチパスネットワークリンクのセットを介して提供される総スループットを監視し、1つ以上のデータパケットが監視された総スループットよりも速い速度で通信されている場合、1つ以上のデータパケットを遅延させ、それにより1つ以上のデータパケットが必要なペースで通信されているように見えるように、少なくとも監視された総スループットに基づいて、1つ以上のデータパケットのうちの少なくとも1つのデータパケットに対応する特性を変更することによって、パケット間隔操作を実行するように適合されている。【選択図】図5A
Description
関連出願の相互参照
本出願は、参照によりその全体が本明細書に組み込まれる、「SYSTEMS AND METHODS FOR MANAGING DATA PACKET COMMUNICATIONS」と題された、2019年8月8日に提出された米国特許出願第62/884514号の優先権を含む、非暫定的な利益であり、すべての利益を主張する。
本出願は、参照によりその全体が本明細書に組み込まれる、「SYSTEMS AND METHODS FOR MANAGING DATA PACKET COMMUNICATIONS」と題された、2019年8月8日に提出された米国特許出願第62/884514号の優先権を含む、非暫定的な利益であり、すべての利益を主張する。
本出願は、2017年12月21日に出願され、同じくその全体が参照により本明細書に組み込まれる、「PACKET TRANSMISSION SYSTEM AND METHOD」と題された米国特許出願第16/482972号にも関連する、PCT出願第PCT/CA2017/051584号に関連する。
本開示の実施形態は、概して電子データ通信の分野に関し、より具体的には、実施形態は、データパケット通信を管理するためのデバイス、システム、および方法に関する。
はじめに
通信リンクにわたるデータパケット伝送は、例えば、種々の通信ボトルネックに起因する輻輳の問題によって影響を受けている。そのため、ネットワーク化された通信は、輻輳の問題を低減するために、バッファリングおよびペーシングのアプローチを利用して、データパケット通信の改善(例えば、損失パケットの削減、全体的なスループットの改善)に役立てている。
通信リンクにわたるデータパケット伝送は、例えば、種々の通信ボトルネックに起因する輻輳の問題によって影響を受けている。そのため、ネットワーク化された通信は、輻輳の問題を低減するために、バッファリングおよびペーシングのアプローチを利用して、データパケット通信の改善(例えば、損失パケットの削減、全体的なスループットの改善)に役立てている。
例えば、TCPデータパケットペーシングは、ACKクロックされている(すなわち、特定の伝送レートではなく、輻輳ウィンドウに基づいてインフライトにパケットを送信する)TCP送信機によって送信されるパケットのバースト性を制御する機構として利用することができる。
輻輳の問題は、通信ネットワークを通じたサービス品質の低下の主因となる。特に、ペーシングの問題は、パケットの紛失または順不同によって影響を受け得る特定の受信要件がある「ハンドシェイク」または他の誤り訂正プロトコルに関して、上記で述べたような特定の技術的問題を生じさせるネットワークの輻輳をもたらす。
特定のプロトコルベースの要件は、中断されると、紛失したと考えられるパケットの不注意な再伝送などのさらなる下流の問題を引き起こし、パフォーマンスをさらに低下させる。したがって、一部のシナリオでは、永続的にパフォーマンスが低下し続ける可能性がある。
本明細書に記載されるように、データ通信変更アプローチは、データパケットペーシングおよび/またはタイミングに関連する個別の技術的問題を解決するために提案されている。これらのアプローチは、元のペーシングを復元する/新しいペーシングを確立するためにデータパケットペーシングを変更するように適合された特定の技術的ソリューションを提供し、それによって、輻輳を減らすか、または「バースト的な」通信の影響を減らすなどの全体的なデータ伝送特性を改善する。改善されたペーシングは、例えば、バーストが非常に大きく、バッファ制限を超え、結果としてパケットが誤ってドロップされる状況(早期ドロップ)で役立つ。
また、代替の提案された実施形態は、例えば、実際のデータペイロードと冗長ペイロード(例えば、フォワード誤り訂正ペイロード)とを区別するためのパケット監視またはフラグ付けアプローチの使用に基づいてペーシングを決定/確立するための特定のアプローチについて説明される。種々のアプローチにより、ペーシングが無効化、有効化、変更された種々のシナリオのテストを通じて実験的に検証され、バーストのタイミングがネットワーク全体の通信品質にどのように影響するかが監視され、検証された。
本明細書に記載のアプローチは、物理ネットワークデバイス(例えば、ルータ、シーケンサ、ハブ、マルチパスゲートウェイ、スイッチ、データパケットフォワーダ)、物理デバイスによって実行されるコンピュータ実装方法、および/または結合されたプロセッサ(複数可)上で実行するための非一時的コンピュータ可読媒体上で符号化された機械解釈可能命令セットの形態のソフトウェアまたは組み込みファームウェアとして確立することができる。
特に、物理ネットワークデバイスは、物理ネットワークデバイスによって遭遇したデータパケットの指示および/またはルーティングを制御するデータリポジトリ/ストレージ媒体に記憶されたルーティングテーブルまたはルーティングポリシーを変更または別様で確立するように適合され得る。
一部の実施形態では、物理ネットワークデバイスは、インフライト変更のために適合される。他の実施形態では、物理ネットワークデバイスは、受信機ノードに適合または結合され得、受信機ノードへのプロビジョニングの前に(例えば、再シーケンサとして)シーケンス修正/ペーシング変更を行う。これは、既存のネットワークインフラストラクチャが後付けに適合している場合に特に有用である。さらなる実施形態では、インフライト変更デバイスおよびエンドポイントリシーケンサデバイスの両方を協働して使用することができる。
例示的な説明が本明細書に提供される。単一の通信リンクシナリオでは、データパケット通信プロトコルは、送信デバイスと受信デバイスとの間の直接的な交渉として行われ得る。しかしながら、例えば、ボンディングされた接続セットとして一緒に利用される複数の通信リンクがある場合、データパケットバッファリングおよびデータパケットペーシングに関する技術的課題が増加する。共に利用される複数の通信リンクは、単一の通信パスが信頼できないか、またはそれ自体で適切な送信を提供しないシナリオにおいて特に有用である。
例示的なシナリオは、大規模なビデオまたはバルクデータの送信が必要とされるシナリオ(例えば、大量のネットワークトラフィックも存在する大規模スポーツイベントでのライブキャスティング)、地方での通信(例えば、地理的距離および地理的特徴からのスペクトル干渉に起因する)、または緊急対応状況(例えば、プライマリ通信リンクが動作可能ではなく、セカンダリ通信リンクが必要とされる)を含む。
データパケット管理は、スループットがデータパケット損失率に逆相関する関数としてモデル化され得るため、有益である(例えば、TCPスループットは、損失確率の平方根に反比例するように一般的にモデル化される)。しかしながら、単一のリンクにわたる通信間で利用されるパケット管理アプローチは、複数の通信リンクが一緒に使用される場合には最適ではない。
本明細書に記載されるように、物理ネットワークデバイス(例えば、改善されたルータ)、ネットワークトラフィックコントローラ、ならびに一緒に利用される複数の通信リンクでの使用に適合された、対応する方法およびコンピュータプログラム製品(例えば、プロセッサ上で実行するための機械解釈可能な命令を記憶する非一時的コンピュータ可読媒体)を含む、技術データパケットおよびデータバッファ/キュー管理機構に関して、技術ソリューションが提案されている。例えば、一部の実施形態のパケット間隔操作は、データパケットが単一のネットワークリンクを介して通信された場合、ペーシングと実質的に同様のパケット通信ペースでデータパケットに復元されるように適合される。パケットモニタ/パケット監視デバイスを使用することによって接続フローを改善するように適合される種々の実施形態に関連して、特定の技術的アプローチが本明細書で説明される。
これらのパケット監視/変更ソリューションは、データ通信の特性を変更することによって全体的なスループットを改善するように適合されている。デバイスは、種々の実施形態に従って、送信側(例えば、伝送側)、受信側(例えば、受信機側)、通信リンクコントローラ上(例えば、インフライト)で、またはそれらの組み合わせで動作するように構成されてもよい。例えば、パケットペーシング(例えば、パケット間隔)は、送信側(もしくはインフライト)で変更されてもよく、またはパケットは、受信機側でのバッファリングまたは仲介機構によって離間して配置されてもよい。
通信を要求または受信する上流または下流デバイスについて、データパケット管理アクティビティは、透明であり得る(例えば、伝送が要求かつ送信されており、上流または下流デバイスは、通信の態様が成功し、特定の期間を必要としたことを観察するだけである)。
例えば、データパケットが、マルチパスネットワークリンクのセットからデータパケットを受信し、元のデータフローシーケンスを再生成するように構成された接続デボンディングデバイスで受信されたときに、パケット間隔操作を実行することができ、かつ/またはデータパケットが、元のデータフローシーケンスまたは間隔配置に基づいて、マルチパスネットワークリンクのセットにわたって伝送するためにデータパケットを割り当てるように構成された接続ボンディングデバイスで伝送されたときに、パケット間隔操作を実行することができる。
第1の実施形態では、データパケット送達フロー(例えば、データパケットペーシング)を管理するためのシステムが説明されており、これは、データパケットがマルチパスネットワークリンクのセット全体で通信されている場合に適合される。マルチパスネットワークリンクのセットは、共に動作することによって、特定のデータ通信に関連するデータパケットを協働して通信するように、共にボンディングすることができる。データパケットは、通信(例えば、伝送)中に互いに離間され、一部の実施形態では、この間隔は、データパケットが伝送機、仲介ルータ、受信機、またはそれらの組み合わせによってどのように扱われるかを変更するタイムスタンプなどの情報をデータパケットに添付することによって提供される。
このアプローチにおけるマルチパスネットワークリンクの利用における技術的課題は、ペーシングが確立されにくく、ペーシング不良がデータパケットを失うことである。データパケットを紛失すると、上層プロトコルに表示されるレイテンシが増加する可能性がある。例えば、アプリケーション層は、ペースの悪いパケットがドロップされ、TCP層が再伝送する必要があるため、よりレイテンシが高くなる。
一部のデータ転送プロトコルでは、ペースの悪いパケットは、望ましくない動作をもたらし得る。例えば、送信機は、ペーシング不良で発生するパケットの大きなバーストにより、中間ルータまたは他のネットワークホップによってドロップされるパケットを再伝送する必要がある。
システムは、共に動作するマルチパスネットワークリンクのセットを介して提供される総スループットを監視するように構成されたプロセッサを含む。例えば、それぞれが異なる通信特性を提供する3つのネットワークリンクが存在してもよい。第1のネットワークリンクは5Mbpsの帯域幅を有し、第2は15Mbps、および第3は30Mbpsの帯域幅を有し、合計で50Mbpsになり得る。総スループットは、必ずしもマルチパスネットワークリンクのセットのすべてに及ぶ必要はない。例えば、総スループットは、サブセットにわたって追跡され得るか、または複数の総スループットは、ネットワークリンクの1つ以上のサブセットにわたって監視され得る。
パケットペーシングは、1つ以上のデータパケットが監視された総スループットよりも速い速度で通信されている場合、データパケットが必要なペースで通信されている/通信されているように見えるように遅延されるように、少なくとも監視された総スループットに基づいてデータパケットの特性を変更することによって行われる。例えば、変更される特性は、少なくとも監視された総スループットに基づいているデータパケットの各々の受信タイムスタンプ間の(例えば、相対的または絶対的な)パケット間の間隔(例えば、アイデアのパケット間の間隔を通じて確立される必要なペース)であり得る。一部の実施形態では、タイムスタンプの変更は、少なくとも1つのタイムスタンプが未来のタイムスタンプを反映するように修正されることを含み得る。
監視された総スループットの変化に応答して、プロセッサは、タイムスタンプの理想的なシーケンスが何であるべきであったか(例えば、何が監視された総スループットの変化について事前に知られていたはずであったか)を判定し、変更された理想的なタイムスタンプが持続時間にわたって整列するように、まだ通信されていないデータパケット上のタイムスタンプのパケット間の間隔を修正するようにさらに構成され得る。
一部の実施形態では、バッファは、タイムスタンプされたデータパケットを記憶するために使用され、データパケットが通信される順序を示すキューを定義する固定サイズが存在しないように、サイズを動的に増減するように適合され、データパケットのサブセットは、キュー内のデータパケットの対応する経年(タイムスタンプに基づいて計算される)に基づいてバッファから定期的に削除される。かかるバッファは、意図されたサイズ制限を有していない場合があるが、予想される挙動では、パケットのバーストをバッファリングし、ペーシングレートでそれらを宛先にメータリングすると、ACKクロックされたバースト的なアプリケーションが、ペーシングレートでその後続のパケットを伝送することを間接的にもたらすため、その結果、後続のパケットのバッファ消費がはるかに小さくなる。しかしながら、実際の実施形態では、ACKクロックされていないアプリケーションを扱うために、実際のバッファ制限を課さなければならない。これらのアプリケーションは、ペーシングレートに関係なく伝送レートを有するため、最終的に、バッファはその制限に達し、パケットは、任意の数のアクティブキュー管理(AQM)アプローチ(例えば、RED、FIFO、CoDelなど)に従ってドロップされる必要がある。
図において、実施形態は、例として示される。説明および図面は、例示の目的のためにのみおよび理解の補助としてのみであることが明示的に理解されるべきである。
ここで、実施形態は、例としてのみ、添付の図面を参照して説明される。
本開示の実施形態は、概して電子通信の分野に関し、より具体的には、実施形態は、データパケット通信を管理するためのデバイス、システム、および方法に関する。
単一の通信リンクシナリオでは、データパケット通信プロトコルは、送信デバイスと受信デバイスとの間の直接的な交渉として行われ得る。しかしながら、例えば、ボンディングされた接続セットとして一緒に利用される複数の通信リンクがある場合、データパケットバッファリングおよびデータパケットペーシングに関する課題が増加する。共に利用される複数の通信リンクは、単一の通信パスが信頼できないか、またはそれ自体で適切な送信を提供しないシナリオにおいて特に有用である。
例示的なシナリオは、大規模なビデオまたはバルクデータの送信が必要とされるシナリオ(例えば、大量のネットワークトラフィックも存在する大規模スポーツイベントでのライブキャスティング)、地方での通信(例えば、地理的距離および地理的特徴からのスペクトル干渉に起因する)、または緊急対応状況(例えば、プライマリ通信リンクが動作可能ではなく、セカンダリ通信リンクが必要とされる)を含む。
データパケット管理は、スループットがデータパケット損失率に逆相関する関数としてモデル化され得るため、有益である(例えば、TCPスループットは、損失確率の平方根に反比例するように一般的にモデル化される)。しかしながら、単一のリンクにわたる通信間で利用されるパケット管理アプローチは、複数の通信リンクが一緒に使用される場合には最適ではない。
このアプローチにおけるマルチパスネットワークリンクの利用における技術的課題は、ペーシングが確立されにくく、ペーシング不良がデータパケットを失うことである。一部のデータ転送プロトコルでは、ペースの悪いパケットは、望ましくない動作をもたらし得る。例えば、送信機は、ペーシング不良で発生するパケットの大きなバーストにより、中間ルータまたは他のネットワークホップによってドロップされるパケットを再伝送する必要がある。
利用可能な接続間のレイテンシ、帯域幅、および信頼性の差異を正規化するために、パケットのバッファリングおよび並べ替えを必要とするマルチパスネットワーキングシステムは、例えば、参照によりその全体が本明細書に組み込まれる、「PACKET TRANSMISSION SYSTEM AND METHOD」と題された出願人の米国特許出願第16/482972号/PCT出願第PCT/CA2017/051584号に記載されている。
このバッファリングは、TCPなどのACKクロックされたプロトコルと組み合わせると、パケットのバースト的な伝送を引き起こす可能性がある。例えば、マルチパスシステムは、TCPパケットが順番になるまでバッファ/遅延し、次いでそれらをバーストで宛先に解放し得る。宛先は、バーストでTCPセグメントを受信し、バーストでTCP ACKも生成する。これらは、バーストでTCP送信機に到着する。ACKクロックされたTCP送信機、特に低速開始フェーズの送信機は、確認されたバーストと同様のサイズの新しいパケットのバーストと、ネットワークがより多くのデータを送達できるかどうかを検出するのに役立つ同様のサイズの新しいパケットの追加のバーストとを伝送することによって、ACKのバーストに応答する。全体的な結果は、ACKのバーストに応答して、さらに大きなパケットインフライトのバースト(確認されたバーストの2倍のサイズ)を伝送することである。これは、いくつかのサイクルにわたって繰り返され、最終的に、バーストが非常に大きくなり、マルチパスネットワークシステムのバッファリング制限を超え、TCPセグメントの一部をドロップさせる可能性がある。TCP送信機は、これらのドロップを輻輳と誤って解釈し、伝送レートを低下させる。
予期しないドロップは、マルチパスシステムのサイズベースのバッファリング制限に起因し得る。この制限は、早期のドロップを防止または遅延させるために増加され得るが、大量のデータバーストをバッファリングすることは、マルチパスシステムの利用可能な接続が、妥当な時間内にバッファをクリアするのに十分な伝送容量を有する場合にのみ許容される。その容量が利用できないか、または著しく変動する場合、大きなバーストを受け入れるが、それらを迅速にクリアしないと、過度のバッファブロートが生じ、ここで、インフライトパケットが長時間にわたってバッファリングされ、これは、通信アプリケーションによって、高レイテンシまたは送達タイムアウトとして見られる。
このトレードオフに対処するために、サイズによってバッファを制限するのではなく、キュー内のパケットの滞在(待機)時間に基づいてバッファを制限することは、不十分なパケットペーシングの効果を遅延させるのに役立つ一つの手法である。マルチパスシステムに大量の総伝送容量がある場合、ペーシング不良による大きなバーストは速やかにクリアでき、早期のドロップは発生しない。
しかし、この無制限のサイズ、滞在時間の制限されたキューは、避けられない遅延を引き起こすだけである。前述の例に続いて、最終的に送信機は、マルチパスシステムのバッファ内のパケットの滞在時間が制限を超え、サイズ制限されたキューで起こるのと同じようにドロップされるように、非常に大きなバーストでTCPセグメントを伝送する。例えば、ネットワークが8Mb/秒のドレインレートおよび500msの滞在時間制限を有するバッファを有すると仮定する。かかるネットワークによる1MBのパケットバッファのバーストには、1秒間のドレインが必要になる。したがって、そのバーストの末尾にある一部のパケットは、500msの滞在時間制限を超え、ネットワークを終了する機会を得る前にバッファによってドロップされる。パケットペーシングの目的は、マルチパスシステムがバッファからパケットを強制的にドロップされないように、アプリケーションを1秒間にわたって1MBのパケットバーストのより均等に配置するように誘導することである。システム全体のスループットは、(アプリケーションではロスが発生しないために)向上して、マルチパスシステムのバッファ稼働率も低下する。
本明細書に記載されるように、物理ネットワークデバイス(例えば、改善されたルータ)、ネットワークトラフィックコントローラ、および対応する方法ならびにコンピュータプログラム製品(例えば、プロセッサ上で実行するための機械解釈可能な命令を記憶する非一時的コンピュータ可読媒体)を含む、技術データパケットおよびデータバッファ/キュー管理機構に関して、技術ソリューションが提案されている。例えば、一部の実施形態のパケット間隔操作は、データパケットが単一のネットワークリンクを介して通信された場合、ペーシングと実質的に同様のパケット通信ペースでデータパケットに復元されるように適合される。変形実施形態では、異なるペーシングまたは新しいペーシングも同様に確立することができる(例えば、すべての実施形態が実質的に同様のペーシングに限定されるわけではない)。ペーシングは、ルーティングテーブルまたはルーティングポリシーの変更、遅延の注入、タイムスタンプの変更などによって確立することができる。
本システムは、一部の実施形態では、単一の接続ケースで自然に発生するペーシングアクティビティを人工的に再現するように適合される。多重接続シナリオでは、ある程度の調整が必要であり、一部の状況では、通信システムは、データパケットのペーシングをある程度制御する。しかしながら、データパケットのペーシングの制御をアサートすることで、制御機構を課すことによって発生する計算コスト、構成要素コスト、およびデバイス複雑性コストも生じる。
図1は、一部の実施形態による、データパケット送達フローを管理するための例示的なシステムのブロック概略図である。変形が可能であり、システムは、種々のハードウェア構成要素を有する適切に構成された物理的ハードウェアデバイスであり得る。
図1に示されるように、システム100は、データパケット間のパケット間隔を改善し、変更されたパケット通信ペースを確立することで、システムの伝送部分上の改善されたスケジューリングアプローチおよび受信端上のバッファリングシステムを利用するように構成されている。
一実施形態では、図示される構成要素は、互いに相互作用するように構成されたハードウェア構成要素である。別の実施形態では、構成要素は別個の構成要素ではなく、2つ以上の構成要素を特定のハードウェア構成要素(例えば、構成要素のうちの2つ以上の機能を実行するコンピュータチップ)上に実装することができる。プロセッサは、機械可読命令セットを実行するように構成される。一部の場合では、システムは、パケットペーシングを修正するように特別に適合された特別な目的のコンピュータである。一部の場合では、システムは、コンピュータサーバである。一部の場合では、システムは構成されたネットワークデバイスである。
いくつかの実施形態では、構成要素は、同じプラットフォーム(例えば、同じ印刷回路基板)上に存在し、システム100は、輸送可能であり、データセンター/フィールド携帯可能なデバイス(例えば、頑強なモバイル伝送機)などに接続可能である、単数のデバイスである。別の実施形態では、構成要素は分散されており、すべてが近接して配置されているわけではなく、むしろ、電気通信を通じて電子的に通信する(例えば、ローカルで実行されるのではなく、処理および制御は、分散されたリソース環境(例えば、クラウド)に常駐する構成要素によって行われる)。構成要素は、例えば、集積回路またはプリント基板上に結合するためのチップまたはチップセット上のシステムの形態で提供され得る。
ボンディングされた接続性の提供は、信号品質、ネットワークの可用性、品質ネットワークなどが最適ではないモバイルシナリオにおいて特に望ましい(例えば、プロフェッショナルのニュース収集/ビデオ作成は、強力なネットワークインフラストラクチャのない場所で行われ得る)。
1つ以上のネットワーク(またはネットワークチャネル)を表す複数の異なるデータ接続106(例えば、「パス」)が示され、接続1、接続2...接続Nとしてラベル付けされる。単一のネットワークにわたって複数のデータ接続/パスが存在してもよく、1つ以上のネットワークを使用し得る複数のデータ接続が存在してもよい。
システム100は、種々のエンドポイント102、110またはアプリケーションに通信するように構成されてもよく、これらは、データを要求および受信するために使用される複数のパス/接続106に関する任意の情報を有する必要はない(例えば、エンドポイント102、110は、パスまたは接続106とは独立して機能することができる)。例えば、受信されたデータは、元の伝送が、異なるパス/接続106の寄与から再生され得るように再構築され得る(例示的な使用シナリオは、改善されたネットワーク機能を提供するために既存のブロードキャストインフラストラクチャと統合して、データセンター施設のサーバラックにスロットするように構成された受信機によるビデオの再生である)。
システム100は、ソースエンドポイント102から入力(データフロー)を受信し、種々の接続106にわたって改善されたデータパケットの送達をスケジュールし、次いで、宛先エンドポイントアプリケーション110に伝送する前に、システム108の他方の端部でデータパケットをシーケンスする。そうすることによって、システム100は、利用可能な種々のパスの最大帯域幅の合計に近づくために帯域幅を増加させるように構成される。単一の接続を使用することと比較して、システム100はまた、改善された信頼性を提供する。これは、イベントが発生しているときにライブイベントでニュースを収集するなど、時間制限のある、非常に機密性の高いシナリオにおける重要な考慮事項となり得る。これらのイベントでは、高信号の輻輳(スポーツイベントなど)、または1つ以上のパスにわたる低信頼性(自然災害後のニュースの報告など)が存在し得る。
種々の実施形態では、スケジューラおよびシーケンサの両方は、クラウドコンピューティングの実装形態から、またはエンドポイントで(データがエンドポイントでアプリケーションによって消費される前に)、またはそれらの種々の組み合わせで提供され得る。
システム100は、とりわけ、パフォーマンス、最良のレイテンシ、最良のスループット、最小のジッタ(2つのシステム間のパケットフローのレイテンシの変動)、接続のコスト、特定のフローに対する接続の組み合わせを最適化および/または優先順位付けするように調整されてもよい(例えば、システム100が伝送(データフロー)がコンテンツタイプXであるという情報を有する場合、システム100は、同様のレイテンシを有するデータ接続のみを使用するように構成されてもよく、一方でコンテンツタイプYは、データ接続のより広範な混合を可能にしてもよい(またはデータ接続の組み合わせでのみ実現され得るより大きな正味容量を必要としてもよい))。この調整は、一般的に、または各フロー(または、位置、開始点もしくはエンドポイントのいずれかの所有者、またはそれらの組み合わせ、伝送時間、利用可能な通信リンクのセット、伝送に必要なセキュリティなどに基づくフローのセット)に特有のシステムに提供されてもよい。
システム100は、各ゲートウェイ104、108が、一般に、TCPトラフィック(またはUDPトラフィック、もしくはTCPとUDPトラフィックの組み合わせ、または任意の種類の一般的なIPトラフィック)を扱うためのスケジューラおよびシーケンサを有するという点で、概して双方向であり得るが、一部の実施形態では、1つのゲートウェイのみが必要とされ得る。
システムのスケジューリング部分の特徴は、所与の接続の帯域幅を推定するための新しいアプローチである。推定は、例えば、冗長(例えば、FECパケット)および非冗長ペイロードが、推定の目的のために互いに区別される、改善された監視アプローチに基づき得る。
システム100は、種々のシナリオ、例えば、既存のインターネット接続(例えば、VoIP電話システムまたはウェブへの企業接続)のためのフェールオーバーまたは補足として利用されてもよく、それによって追加のネットワーク(またはパス)が追加されて、ドロップされたプライマリインターネット接続をシームレスに置き換えるか、またはボンディングが使用されて、プライマリインターネット接続が飽和している場合にのみコストの高いネットワークが含まれる。別の用途として、異なる属性を有する他のデータ接続へのトラフィックのオフロードを可能にすることによって、衛星などの高コスト(しばしばサンクコスト)、高信頼性データ接続の使用を最大化する手段を提供することがある。
一部の実施形態では、システムは、複数のネットワーク接続にわたってデータフローをルーティングするように構成されたネットワークゲートウェイである。
図1は、2つのゲートウェイ104および108を有するシステムの概要を提供しており、それぞれ、バッファマネージャ150、動作エンジン152、接続コントローラ154、フロー分類エンジン156(フロー識別および分類に関与する)、スケジューラ158、シーケンサ160、およびネットワーク特性監視ユニット161を含み、N個のデータ接続106によってリンクされ、各ゲートウェイは、特定のエンドポイント102、110に接続される。参照文字AおよびBは、2つのゲートウェイ104および108の各々の構成要素を区別するために使用される。
各ゲートウェイ104および108は、複数のネットワーク接続を介してデータを伝送するための複数のネットワークインターフェースを含むように構成されており、複数のネットワーク接続の時間変動ネットワーク伝送特性を監視することと、データフローのためにデータフロークラスを識別するためにパケットのデータフローの少なくとも1つのパケットを解析することであって、データフロークラスは、データフローのために少なくとも1つのネットワークインターフェース要件を定義するか、またはそれ以外の場合、関連付けられている、解析することと、データフロークラスおよび時間変動ネットワーク伝送特性に基づいて複数のネットワーク接続にわたってデータフロー内のパケットをルーティングすることと、を行うために構成されたプロセッサを含むデバイス(例えば、構成されたハードウェア、ソフトウェア、または組み込みファームウェアを含む)である。
バッファマネージャ150は、(個々のフローと、システムを通過する複数の同時フローの組み合わせとの両方の)トラフィックをより効率的に管理するように適合されたゲートウェイ内のバッファを設定するように構成されている。一部の実施形態では、バッファマネージャは、別個のプロセッサである。他の実施形態では、バッファマネージャは、他のアクティビティの中でバッファ管理150を実行するように構成されたプロセッサによって提供されるコンピューティングユニットである。
動作エンジン152は、受信した入力データセット(例えば、フィードバック情報、ネットワーク輻輳情報、伝送特性)に基づいて1つ以上の決定論的方法および/または論理動作を適用し、ユーザ/クライアント、宛先/サーバ、接続(例えば、レイテンシ、スループット、コスト、ジッタ、信頼性)、フロータイプ/要件(例えば、FTP対HTTP対ストリーミングビデオ)のいずれかごとに、ボンディングされた接続に適用される制約についてシステムに通知するように構成される。例えば、動作エンジン152は、1つのインスタンスにおけるコストに基づいて、特定のタイプのフローを特定の接続またはデータ接続のセットに制限するように構成されてもよいが、異なるユーザまたはフロータイプに対しては、信頼性および低レイテンシがより重要であり得る。異なる条件、トリガ、方法は、例えば、既知の情報の1つ以上の要素に応じて利用されてもよい。動作エンジン152は、例えば、バッファマネージャ150と同じまたは異なるプロセッサ上に提供されてもよい。
動作エンジン152は、N個のデータ接続106上のルーティングが制御される論理動作を決定する1つ以上のルールセットを生成するか、適用するか、もしくは別様で操作するか、または使用するように構成されてもよい。
フロー分類エンジン156は、伝送のためにマルチパスゲートウェイ104によって受信された各データフローを評価するように構成され、既知でない場合、送信されているトラフィックのタイプおよびその要件を決定するためにフロー分類アプローチを適用するように構成される。一部の実施形態では、ディープパケット検査技術は、判定を実行するように適合される。別の実施形態では、評価は、生成されたときにマーキングまたはラベル付けされたヒューリスティックな方法またはデータフローに基づく。別の実施形態では、評価は、システムのユーザ/管理者によって提供されるルールに基づいている。別の実施形態では、方法の組み合わせが使用される。フロー分類エンジン156は、1つ以上のネットワークインターフェースと相互作用するように構成され、電子回路またはプロセッサを使用して実装され得る。
例えば、フロー識別は、データフローのパケットで提供される情報の分析、パケットヘッダ情報(例えば、ソース/宛先IP、トランスポートプロトコル、トランスポートプロトコルポート番号、DSCPフラグ)の検査を通じて行われ得る。一部の状況では、送信デバイスは、例えば、ヘッダフラグまたは他のメタデータにおいて、ペイロード内にどのような種類の情報があるかを単純に示すことができる。これは、例えば、ペイロードが暗号化された情報を搬送し、送信されているペイロードの種類を確認することが困難である場合に有用であり得る。一部の実施形態では、(例えば、どのタイプの情報がペイロード内にあるかが不確かな場合)ディープパケット検査アプローチも使用することができる。
一部の実施形態で提供されるように、差別化されたレベルの識別が生じてもよい。例えば、パケット本体のコンテンツは、例えば、ディープパケット検査技術を使用してさらに検査されてもよい。
フローが特定されると、分類は、その要件に基づいてフローを分類することを含み得る。分類の例としては、以下のようなものがある。
1.低レイテンシ、低~中ジッタ、順不同であり得るパケット、高帯域幅(ライブHDビデオブロードキャスト)。
2.低レイテンシ、低~中ジッタ、順不同であり得るパケット、中帯域幅(Skype(商標)、FaceTime(商標))など(ジッタは、アーチファクトまたは通信の劣化を引き起こす可能性があるため、リアルタイム通信で問題となる)。
3.低レイテンシ、低~中ジッタ、順不同であり得るパケット、低帯域幅(DNS、VoIP)。
4.低レイテンシ、ジッタ要件なし、パケットは順序どおりであることが望ましい、低帯域幅(インタラクティブSSH)。
5.レイテンシ要件なし、ジッタ要件なし、パケットは順序どおりであることが望ましい、中~高帯域幅(例えば、SCP、SFTP、FTP、HTTP)。
6.レイテンシ要件なし、ジッタ要件なし、パケットは順序どおりであることが望ましい、帯域幅要件なし、持続的なバルクデータ転送(例えば、ファイル/システムバックアップ)など。
2.低レイテンシ、低~中ジッタ、順不同であり得るパケット、中帯域幅(Skype(商標)、FaceTime(商標))など(ジッタは、アーチファクトまたは通信の劣化を引き起こす可能性があるため、リアルタイム通信で問題となる)。
3.低レイテンシ、低~中ジッタ、順不同であり得るパケット、低帯域幅(DNS、VoIP)。
4.低レイテンシ、ジッタ要件なし、パケットは順序どおりであることが望ましい、低帯域幅(インタラクティブSSH)。
5.レイテンシ要件なし、ジッタ要件なし、パケットは順序どおりであることが望ましい、中~高帯域幅(例えば、SCP、SFTP、FTP、HTTP)。
6.レイテンシ要件なし、ジッタ要件なし、パケットは順序どおりであることが望ましい、帯域幅要件なし、持続的なバルクデータ転送(例えば、ファイル/システムバックアップ)など。
分類を行い得る1つ以上の次元には、以下が含まれるが、これらに限定されない。
a.レイテンシ
b.帯域幅/スループット
c.ジッタ
d.パケットの順序
e.データ転送量
a.レイテンシ
b.帯域幅/スループット
c.ジッタ
d.パケットの順序
e.データ転送量
以下にさらに説明するように、これらの分類次元は、効率的な通信フローを改善するのに有用である。レイテンシおよび帯域幅/スループットの考慮事項は、競合する要件を有するフローがある場合に特に重要である。ジッタが扱われる例示的な実施形態は、以下でさらに説明されており、システムは、例えば、スケジューラでのバッファリングを通して、またはフローを特定の接続に固定することによって、ジッタに対応するように構成され得る。パケット順序付けは、具体的にはTCPのための例を用いてさらに以下に説明されており、データ量は、1つのタイプ(低レイテンシ、低帯域幅)から別のタイプ(レイテンシの影響を受けない、高帯域幅)へのフローを再分類し得るインジケータとしてデータ量が使用され得る場所に関連する。
他の分類次元および分類が可能であり、上記は例示的な分類として提供される。異なる次元もしくは分類、および/またはその組み合わせを、上記のうちから作成することができる。例えば、メディアブロードキャストにおいて、システムは、ビデオデータおよびクリップに関連付けられたメタデータ(例えば、GPS情報、タイミング情報、ラベル)、またはビデオストリームに関連付けられたFECデータを分類するように構成されてもよい。
フロー分類は、システムが発生を防止するように構成された伝送(例えば、一部の例では、ピアツーピアのファイル共有、もしくは著作権の保護下にあることが既知である資料)、またはシステムが階層化されたサービスを提供する文脈で好むように構成され得るトラフィック(例えば、別のユーザまたはソフトウェアプログラムより上位の特定のユーザまたはソフトウェアプログラム)を削除および/またはフィルタリングするために利用され得る。
例えば、インターネットバックアップの使用シナリオでは、ボンディングされたバックアップでも可用性が制限され得るため、システムは、サポート組織との間のVoIP呼び出しが、組織内の呼び出しよりも高いレベルのサービスを受信するように構成され得る(この場合、システムは、制約下にあるとき、エンドポイントに他の呼び出しよりも一部の呼び出しの音声品質を低下させるか、または帯域幅の制約を考慮して特定の呼び出しを完全にドロップする命令を生成することができる)。
スケジューラ160は、どのパケットをどの接続106に送信するべきかに関する判定を実行するように構成されている。スケジューラ160は、改良されたQoSエンジンとみなされ得る。一部の実施形態では、スケジューラ160は、1つ以上のプロセッサ、または比較器回路もしくはFPGAなどのスタンドアロンチップもしくは構成回路を使用して実装される。スケジューラ160は、決定を実行するために確認された一連の論理ゲートを含んでもよい。
典型的なQoSエンジンは、単一の接続を管理するが、フロー識別および分類を実行するように構成することができ、最終的な結果は、QoSエンジンが1つの接続で送信される前にパケットを並べ替えることになる。
対照的に、スケジューラ160は、フロー識別、分類、およびパケット並べ替えを実行するように構成されるが、一部の実施形態のスケジューラ160は、データフローの伝送特性を改善するために、どの接続でパケットを送信するかの判定を実行するように、かつ/またはユーザ/管理者によってフローのために設定されたポリシーを満たすように(または種々のルールで設定されるように)さらに構成される。スケジューラ160は、例えば、ネットワークインターフェースに制御信号のセットを伝送してそれらをオンもしくはオフに切り替えるか、またはデータをルーティングするために使用されるべきであることを示すことによって、ネットワークインターフェース動作特性を変更してもよい。制御信号は、パケットタイミング、特定のタイプのトラフィックに対するネットワークインターフェースの予約など、所望のルーティングの特定の特性を示す命令セットであってもよい。
例えば、以下の特性を有する2つの接続を考慮する。
1)接続1:1msのラウンドトリップタイム(RTT)、0.5Mbpsの推定帯域幅。
2)接続2:30msのRTT、10Mbpsの推定帯域幅。
2)接続2:30msのRTT、10Mbpsの推定帯域幅。
スケジューラ160は、DNSトラフィック(小さなパケット、低レイテンシ)専用の接続1を予約しようと試み得る。この例では、接続1の容量に達するほど多くのDNSトラフィックが存在してもよく、スケジューラ160は、トラフィックを接続2にオーバーフローするように構成されてもよいが、スケジューラ160は、他の判定または要因に基づいて選択的に行うことができる。例えば、スケジューラ160が公正な判定を提供するように構成されている場合、スケジューラ160は、過去X秒間に、既にかなりの量のDNSトラフィックを送信したIPアドレスからの最初のオーバーフロートラフィックを構成してもよい。
スケジューラ160は、例えば、1つ以上のプロセッサまたはハードウェア(例えば、FPGA)における類似の実装形態と併せて動作するプロセスまたは方法に基づいて、判定を処理するように構成され得る。これらのデバイスは、動作エンジン152の制御下で動作するように構成され得、これは、データストリームをデータパケットに分解し、次にデータ接続の特性を考慮しながらパケット送達を最適化しようとするルールに従ってデータパケットをデータ接続に供給するバッファ(バッファマネージャによって管理される)にデータパケットをルーティングする。
一次基準は、一部の実施形態では、レイテンシおよび帯域幅に基づいているが、一部の実施形態では、パス最大伝送ユニット(PMTU)も利用され得る。例えば、一方の接続が他方よりも著しく小さい(例えば、1500バイトに対して500バイト)PMTUを有する場合、その接続上で送信されるパケットは断片化される必要がある(例えば、回避または優先順位の緩和され得る)ため、それはオーバーフローの悪い候補として指定される。
スケジューラ160は、一部の実施形態では、正しい順序でパケットを通信するように構成される必要はなく、むしろ、所望のQoS/QoEメトリック(そのうちの一部は、ネットワークコントローラによって定義されてもよく、他のものは、ユーザ/顧客によって定義されてもよい)を満たすか、または超えるように、多様な接続にわたってパケットを通信するように構成される。パケットが順不同で通信されてもよい場合、シーケンサ162およびバッファマネージャを利用して、受信したパケットを並べ替えてもよい。
パケットの連続的バーストは、ネットワークインターフェースを介して伝送され、パケットの連続的バースト内のパケットが受信ノードで受信されるときに記録されるタイムスタンプ、およびパケットのサイズに基づいて、第1のネットワークインターフェースの帯域幅の推定値が生成される。次いで、推定値は、第1のネットワークインターフェースの生成された帯域幅に基づいて、ネットワーク接続のセット全体のシーケンシャルパケットのデータフロー内のパケットをルーティングするために利用される。以下に説明するように、一部の実施形態では、帯域幅の推定値は、バースト内の初期パケットまたは最終パケットと合体されていないバースト内のパケットのタイムスタンプに基づいて生成され、より低い帯域幅の値を推定することができ、(例えば、パケットの置換を通じて)より高い帯域幅の値を推定することができる。送信されるパケットは、テストパケット、データパケット上のテストパケット「ピギーバック」、またはハイブリッドパケットであり得る。データパケットが「ピギーバック」のために使用される場合、一部の実施形態には、冗長性を増加させるために(例えば、特に帯域幅テスト目的で使用されるパケットのために、損失パケットに対する許容度を強化するために)かかるデータパケットにフラグを立てることが含まれる。
シーケンシャルパケットは、順番に、またはシーケンサ162が消費のためにパケットを再配置することができるように、順序からの許容可能な偏差内で受信され得る。一部の実施形態では、シーケンサ162は、信号を受信し、再組み立てされた信号である出力信号を生成するブロードキャストインフラストラクチャに組み込まれ得る物理的ハードウェアデバイスである。例えば、物理的ハードウェアデバイスは、信号受信および再組み立ての第1の段階として機能するラックマウント型アプライアンスであってもよい。
シーケンサ162は、フローに対する不必要なパケット再要求または他の誤り訂正を低減するために、受信したパケットを順序付けし、許容できる順序でエンドポイントでそれらをアプリケーションに伝送するように構成されている。この順序は、一部の実施形態では、元の順序に従っている。他の実施形態では、順序は、受信エンドポイントが依然としてデータフローを利用することができるように、許容可能な誤差の範囲内である。シーケンサ162は、例えば、受信フローのレイテンシおよびジッタを平滑化するためのバッファまたは他の機構を含んでもよく、一部の実施形態では、複数のネットワーク接続の伝送特性の監視、およびシーケンシャルパケットのデータフローの受信における不均一な分布に基づいて、パケットの確認応答およびストレージの伝送を制御するように構成されてもよい。
シーケンサ162は、例えば、プロセッサ上に提供され得るか、または、バッファから抽出された受信データパケットからのデータフローを再組み立てするように構成された、動作エンジン152の制御下で提供されるハードウェア(例えば、フィールドプログラマブルゲートアレイ)に実装され得る。
シーケンサ162は、フローごとに、各フローに許容されない複数の接続間のレイテンシの差異を隠すように構成される。
動作エンジン152は、他の構成要素(154を含む)によって提供される情報の集計器として動作可能であり、シーケンサ162が所与のフローでどのように動作するべきかを示す1つ以上の制御信号を通してシーケンサ162に指示する。
TCPなどのプロトコル用に構成されたシステムがパケットを受信するとき、システムは、概して、パケットが順番に到着することを予測する(ただし、要求しない)ように構成される。しかしながら、システムは、順不同パケットが到着すると予想されるとき(通常、ラウンドトリップタイムまたはRTTの数倍)に、制限時間を確立するように構成されている。システムはまた、ヒューリスティックに基づいて制限された時間よりも早く欠落したパケットを再伝送(例えば、3つのDUP ACKによってトリガされる高速再伝送)するように構成され得る。
パケットが著しく異なるレイテンシを有する接続上でシーケンサ162に到着する場合、シーケンサ162は、パケットを宛先に送信する前に、(フローごとに)パケットがおよそ同じ経年(遅延)になるまでパケットをバッファリングするように構成されてもよい。例えば、フローに一貫したレイテンシおよび低ジッタの要件がある場合、これを実行する。
シーケンサ162は、必ずしもデータパケットの信頼できる、厳密に順序立った送達を提供する必要はなく、一部の実施形態では、プロトコルを使用するシステム(例えば、TCPまたはUDPの上のアプリケーション)が、パケットがネットワークによって失われたことを早期に判定しないように、必要なものを提供するように構成される。
一部の実施形態では、シーケンサ162は、(動作エンジン152によって維持されるデータに基づいて)各データ接続のレイテンシ変動(ジッタ)をパケット損失と共に監視し、接続の信頼性に基づいて、どのデータ接続がフローによって予想されるものを超えてパケットを遅延させる可能性が高いかを予測するように構成される(つまり、エンドポイント102および110がそれらを損失とみなし、誤り訂正ルーチンを呼び出すであろうことを意味する)。
順不同の状況のために、シーケンサ162は、例えば、より大きなレイテンシ変動を示す接続上のより大きなジッタバッファを利用し得る。パケット再伝送のために、シーケンサ162は、「最良」(最も信頼性が高く、最小のレイテンシ)接続を介してすぐに損失パケットを要求するように構成されてもよい。
例示的なシナリオでは、帯域幅遅延積の推定は完全に正確ではなくてもよく、接続において、レイテンシスパイクが生じる。結果として、パケットは仲介ゲートウェイで順不同で受信される。
これらの実施形態では、シーケンサ162は、プロトコル(および/または関連アプリケーション)が誤って並べ替えられたパケットに関してどのように挙動するかに関する予測的判定を実行し、下流システムがネットワークが容量に達した(したがって、その伝送レートを引き戻す)と誤って仮定する可能性が低いようなパケットを並べ替える命令を生成し、かつ/または失われていないパケットの再伝送を不必要に要求するように構成されてもよい。
例えば、多くのTCP実装形態は、DUP ACKの後のパケットが失われる可能性が高いことを示すヒントとして、複数の(例えば、3つの)連続した重複確認応答(DUP ACK)を使用する。これらの確認応答は、例えば、パケット監視機構によって追跡され得る。この例では、受信機がパケット1、2、4、5、6を受信した場合、ACK(2)を3回(パケット4/5/6の各1回)送信する。次いで、送信機は、このイベントが、パケット3がネットワーク内で失われている可能性が高いことをヒントにし得ることを認識するように構成され、任意の通常の再伝送タイムアウト(RTO)タイマーが期限切れになる前に、それを先制的に再伝送する。
一部の実施形態では、シーケンサ162は、かかる予測的判定を説明するように構成され得る。上記の例に従って、シーケンサ162がパケット1、2、4、5、6、3をバッファリングしている場合、シーケンサ162は次いで、パケットが適切な順序で伝送されることを確実にするために、パケットを並べ替えてもよい。しかしながら、パケットが1、2、4、3、5、6の順番で既にバッファリングされている場合、予測判定は(パケット3の位置決めが与えられた)この例ではトリガされないので、シーケンサ162は、伝送前にそれらをわざわざ並べ替えないように構成され得る。
接続コントローラ154は、異なる接続パス106間で実際のルーティングを実行するように構成され、例えば、ボンディングされたリンクへの接続106が物理ゲートウェイ104、108上に存在する必要がないことを示すために提供される(例えば、物理ゲートウェイは、他の場所にあり得る(およびアンテナなどの異なる場所であり得る)物理的な伝送/受信デバイスまたは衛星機器への一部のリンク(イーサネットまたは他の方法で)を有し得る)。したがって、エンドポイントは、論理的に接続され、種々の方法で物理的に分離され得る。
一実施形態では、システム100は、TCPアクセラレーションとして知られているものを提供するように構成され、ゲートウェイは、パケットを受信するとプリバッファを作成し、受信エンドポイントが既にパケットを受信したかのように、送信エンドポイントに確認応答信号(例えば、ACKフラグ)を提供し、実際のパケットがエンドポイントに送達される前に、送信エンドポイント102がより多くのパケットをシステム100に送信することを可能にする。一部の実施形態では、プリバッファリングは、TCPアクセラレーション(結果として生じるデータのバッファリングと組み合わせられる機会的確認応答(ACKing))のために使用される。
このプリバッファは、送信エンドポイント102への第1のリンクの前に、またはエンドポイント110へのチェーン内の任意の他の場所に存在し得る。このプリバッファのサイズは、一部の実施形態では帯域幅遅延積の推定または測定であるマルチパスネットワークからのフィードバックに応じて変化してもよく、または一連の所定の論理演算に基づいて変化してもよい(ここで、特定のアプリケーションまたはユーザは、速度、レイテンシ、スループットなどの特定の特性を有するプリバッファを受信する)。
プリバッファは、例えば、実装形態内の種々のポイントに存在してもよく、例えば、プリバッファは、ゲートウェイ104へのエントリポイントに存在してもよく、またはラインを下って(最終的な宛先の前ではあるが)110までの任意の場所に存在してもよい。実施形態では、エンドポイント1からエンドポイント2へのデータフローとして、一連のプリバッファ、例えば、ゲートウェイAおよびゲートウェイBの両方のプリバッファが存在する。
プリバッファに受け入れられ、エンドポイント102に日和見的にACKされたデータは、エンドポイント110に確実に伝送するシステム100の責任となる。ACKは、エンドポイント110がデータを受信したことを元のエンドポイント102に伝えるので、その通常のTCP機構を介した再伝送を扱う必要はない。
プリバッファリングおよび日和見的ACKは、接続106の損失および他の非理想的な挙動を処理するためにシステム100が利用可能な時間制限を取り除くので、有利である。TCP加速なしの時間制限は、エンドポイント102によって計算されるTCP RTOに基づいており、これは、システム100の制御に含まれない値である。この時間制限を超えた場合、エンドポイント102は、a)システム100が既にバッファリングしている可能性のあるデータを再伝送し、b)そのcwndを低減し、それによりスループットを低減する。
プリバッファのサイズは、メモリ使用量にバインドを配置するために制限される必要があり得、マルチパスゲートウェイ104と108との間のフロー制御情報の通信を必要とする。例えば、ゲートウェイ108とエンドポイント110との間の通信リンクが、すべての接続106の総スループットよりも低いスループットを有する場合、108でバッファリングされたデータの量は、継続的に増加する。
バッファリングされた量が制限を超える場合、フロー制御メッセージを104に送信し、エンドポイント102から送信されたACKデータを一時的に停止するように伝える。
最終的にバッファリングされた量が制限を下回ると、フロー制御メッセージが104に送信され、機会的にACKを再開するように通知される。制限は、静的閾値であってもよく、または例えば、すべての接続106の総BDP、およびシステムによって現在処理されているデータフローの総数などの要因を考慮して動的に判定/計算されてもよい。フロー制御開始/停止メッセージが送信される閾値は、同じである必要はない(例えば、ヒステリシスが存在する可能性がある)。
同様に、マルチパスゲートウェイ自体内にフロー制御シグナリング情報が存在してもよい。例えば、接続106の総スループットが、エンドポイント102とゲートウェイ104との間のスループットよりも小さい場合、104内のプリバッファは、継続的に増加する。制限を超えた後(これは前述のように計算され得る)、エンドポイント102から来るデータの日和見ACKは、一時的に停止され、次いでデータの量が適切な閾値を下回ったときに再開される必要があり得る。
前述の例は、エンドポイント102から110に送信されるデータに対するTCPアクセラレーションを説明している。同様の説明は、データが反対方向に送信される場合にも適用される。
別の実施形態では、バッファマネージャは、接続ネットワークの挙動のばらつきと、ネットワーク上の他のアクティビティの潜在的な「バースト的な」性質と、送信元の送信の性質とを考慮して、通信リンクごとの発信伝送上でオーバーバッファリングを提供するように構成される。
オーバーバッファリングは、例えば、出力側の接続のBDPが扱うことができるよりも多くのパケットを意図的に入力側で受け入れることを対象とし得る。「オーバーバッファリング」と「バッファリング」との違いは、バッファマネージャが、フロー要件に基づいて、接続BDPがリアルタイムでどのように変化するかに基づいて異なる量をバッファリングし得ることである。
このオーバーバッファリングにより、ゲートウェイ104は、伝送エンドポイント102からのデータを、それ以外の場合収容するために準備されるよりも多く(例えば、それが「快適である」よりも多く)受け入れ、バッファリングすることになる。オーバーバッファリングは、全体的に実行され得る(例えば、システムは、システム推定値が総スループットで利用可能であるよりも多くを取るように構成される)か、もしくは接続コントローラに移動され、接続ごとに管理され得るか、または両方の組み合わせ(例えば、伝送ごとに複数のオーバーバッファ)で提供され得る。
例えば、システム100は、所与のリンクのセットにわたって20Mbpsを送信することができると推定し得るだけであっても、ネットワーク条件が、ネットワーク特性監視ユニット161によって提供されるネットワーク特性の統計的、履歴的な知識に基づいて変化する可能性があるという判定、または伝送エンドポイント102(または他の入出力伝送)がそのデータ伝送速度を遅くする可能性がある時間があるという判定に基づいて、一時は20Mbpsを超えるもの(例えば、30Mbps)を伝送エンドポイント102から受け入れ、直ちに送信できないものをバッファリングすることができる。
フロー分類エンジン156は、一部の実施形態では、特定のタイプのトラフィックにフラグを立てるように構成され、動作エンジン152は、一部の実施形態では、バッファマネージャに、フローごとに事前バッファリングおよび/またはオーバーバッファリングをサイズ設定および管理するように指示し、任意の数の基準(データ型、ユーザ、挙動に関する履歴データ、フローの要件)に基づいてバッファのサイズを選択するように構成され得る。
一部の実施形態では、(一度にゲートウェイを通ってルーティングされる伝送が多数存在し得るため)これらのバッファのサイズは、伝送ごと、およびゲートウェイごとに決定される。一実施形態において、プレバッファリングおよびオーバーバッファリング技術は、連動して利用される。
一部の実施形態では、オーバーバッファリングのサイズは、帯域幅遅延積(BDP)に実質的に比例すると判定される。例えば、システムは、ネットワークが高いBDP(例えば、10Mbps@400ms=>500KB)を有する場合、バッファは、パケットで満たされたネットワーク/パイプラインを維持するのに十分なデータを常に利用できるように、バッファを大きくする必要があるように構成されてもよい。逆に、低いBDPネットワークでは、システムは、過度のバッファブロートを導入しないように、バッファリングが少なくなるように構成されてもよい。
バッファブロートは、例えば、ネットワーク内の過剰なバッファリングを指し得、高レイテンシおよびスループットの低下をもたらす。より安価でより容易に利用可能なメモリの出現を考慮すると、多くのデバイスは、現在、かかるバッファの影響を考慮することなく、過剰なバッファを利用する。バッファブロートは、バッファの膨張については、国際計算機学会が発行した論文で詳しく説明されており、これには、例えば、「BufferBloat:What’s Wrong with the Internet?」と題する2011年12月7日の論文、および「Bufferbloat:Dark Buffers in the Internet」と題する2011年11月29日の論文が含まれ、どちらも参照により本明細書に組み込まれる。
ビットレートおよびレイテンシに関連してオーバーバッファリングサイズを決定する例として、ルールは、システムがオーバーバッファリングに起因してネットワークのベースレイテンシに50%を超えて追加してはならないという要件に関連して実装され得る。この例では、ルールは、オーバーバッファリングのサイズがBitrate*BaseLatency*1.5であることを示している。他のルールも可能である。
一実施形態では、動作エンジン152は、マルチパスゲートウェイ104、108に含まれてもよい。別の実施形態では、動作エンジン152は、クラウドに常駐し、1つ以上のゲートウェイ104、108に適用してもよい。一実施形態では、単一のマルチパスゲートウェイ104、108に接続する複数のエンドポイント102、110が存在してもよい。一実施形態では、エンドポイント102、110およびマルチパスゲートウェイ104、108は、同じデバイス上に存在してもよい。
一実施形態では、接続コントローラ154は、マルチパスゲートウェイ104、108(および1つ以上の接続デバイス(例えば、無線インターフェース、または有線接続)に物理的に関連付けられている)とは異なってもよい。別の実施形態では、接続コントローラは、ゲートウェイ上に存在し得るが、物理的接続(例えば、インターフェースまたは有線接続)は、別個のユニット、デバイス、またはデバイス上に存在し得る。
エンドポイントは、論理的に接続される必要があるが、それらは、接続106に依存しないように接続されてもよい(例えば、マルチパスゲートウェイ104、108によって処理される通信)。一部の実施形態では、所与のゲートウェイに利用可能な接続のセット106は、動的であってもよい(例えば、特定の時間にのみ利用可能な特定のネットワーク、または特定のユーザ)。
一実施形態では、エンドポイント102から来るトラフィックは、システム100からの動的フィードバックに基づいて、システム100によって制御可能であってもよい(例えば、システムは、エンドポイントで発生するビデオ伝送のビットレートを変更するように構成されてもよい)。別の実施形態では、エンドポイント102から来るトラフィックは、システム100(例えば、エンドポイントから発信されるウェブ要求)によって制御可能ではない場合がある。
別の実施形態では、伝送チェーン(例えば、図13)内に、2つ以上のマルチパスゲートウェイ104、108のセットが存在してもよい。例えば、一部の実装形態では、クラウド内のゲートウェイに接続するリモートマルチパスゲートウェイを備えたTCP伝送が存在してもよく、伝送は次に、クラウドのエッジ上の別のマルチパスゲートウェイへの非マルチパス接続を提供し、伝送は次に、別のマルチパスリモートゲートウェイへの非マルチパス接続を提供する。
種々の使用例が可能であり得、これには、リモートフィールドオペレータが大量のデータを別の遠隔地に伝送する必要性があり得る軍事的な使用例が含まれる。オペレータのシステム100は、複数のパスを利用して、より広範なインターネットにデータを提供する伝送機構を備えてもよい。次に、システム100は、大容量バックホールを使用してインターネットの端部の別の場所に送信し、そこでシステム100は、第2の遠隔エンドポイントに到達するために別のマルチパス伝送を必要とする。
一実施形態では、ゲートウェイA104およびB108は、利用可能な接続パスの1つを介して互いの間で制御情報を送信するように構成されてもよい。
これらのソリューションは、データ通信の特性を変更することによって全体的なスループットを向上させるように適合されており、図1に示す例に限定されない。例えば、デバイスは、種々の実施形態に従って、送信側(例えば、伝送側)、受信側(例えば、受信機側)、通信リンクコントローラ上(例えば、インフライト)で、またはそれらの組み合わせで動作するように構成されてもよい。
例えば、パケット間の間隔は、所望のペーシングレートを反映する各パケットのタイムスタンプの形態でメタデータを受信機に通信することによって、送信側(またはインフライト)で変更され得る。次いで、受信機は、タイムスタンプに基づいて、各パケットの伝送決定を行うことができる。
通信を要求または受信する上流または下流デバイスについて、データパケット管理アクティビティは、透明であり得る(例えば、伝送が要求かつ送信されており、上流または下流デバイスは、通信の態様が成功し、特定の期間を必要としたことを観察するだけである)。
例えば、データパケットが、マルチパスネットワークリンクのセットからデータパケットを受信し、元のデータフローシーケンスを再生成するように構成された接続デボンディングデバイスで受信されたときにパケット間隔操作を実行することができ、かつ/またはデータパケットが、元のデータフローシーケンスに基づいて、マルチパスネットワークリンクのセットにわたって伝送するためにデータパケットを割り当てるように構成された接続ボンディングデバイスで伝送されたときに、パケット間隔操作を実行することができる。
第1の実施形態では、データパケット送達フローを管理するためのシステムが説明され、データパケットがマルチパスネットワークリンクのセット全体で通信されている場合に適合される。マルチパスネットワークリンクのセットは、共に動作することによって、特定のデータ通信に関連するデータパケットを協働して通信するように、共にボンディングすることができる。
システムは、共に動作するマルチパスネットワークリンクのセットを介して提供される総スループットを監視するように構成されたプロセッサを含む。例えば、それぞれが異なる通信特性を提供する3つのネットワークリンクがあってもよい。第1のネットワークリンクは5Mbpsの帯域幅を有し、第2は15Mbps、および第3は30Mbpsの帯域幅を有し、合計で50Mbpsになり得る。
パケットペーシングは、1つ以上のデータパケットが監視された総スループットよりも速い速度で通信されている場合、特性が1つ以上のデータパケットが必要なペースで通信されているように見えるように変更されるように、少なくとも監視された総スループットに基づいてデータパケットの特性を変更することによって行われる。例えば、変更される特性は、マルチパス送信機によって受信されるデータパケットの各々に対応するメタデータ内のタイムスタンプであり得る。一部の実施形態では、タイムスタンプの変更は、少なくとも1つのタイムスタンプが未来のタイムスタンプを反映するように修正されることを含み得る。
プロセッサは、マルチパスネットワークリンクの各々上で伝送される異なるタイプのパケットを監視するようにさらに構成され得る。例えば、送信機が受信機に通信しようとしているデータペイロードパケットは、監視された総スループットに寄与するべき1つのタイプのパケットである。送信機がネットワークリンクのネットワークプロパティを評価するために使用できるテストパケットは、貢献しないオーバーヘッドパケットの一種である。損失レポートに応答して送信された、または損失の可能性または予測された損失を防ぐために先制的に送信された過去に伝送されたデータパケットの複製である再伝送パケットは、寄与してはならない冗長パケットの一種である。複数の他のタイプのパケットが存在し得る。所与の時点で、これらのすべてのタイプのパケットの混合物は、マルチパスネットワークリンクの1つ以上にわたって同時にインフライトであり得る。したがって、監視された総スループットは、データパケットによって具体的に使用されている部分(非オーバーヘッドおよび非冗長パケット)を反映するように調整され得る。
一実施形態では、プロセッサは、アカウンティング/パケット特性判定機能、例えば、パケットカウントまたはバイトカウントを実行し、スライドウィンドウ期間にわたって結果を平均化して、データパケットが消費している監視された総スループットの一部を判定することができる。前述の例に続いて、総スループットが30Mbpsの第3のネットワークリンクが、20Mbpsのデータパケット(例えば、前の1秒で20Mb)、6Mbpsのテストパケット(例えば、同じ1秒で6Mb)、および4Mbpsの伝送パケット(例えば、同じ1秒で4Mb)を伝送していた場合、データパケットのペーシングを行うときに、20Mbps部分のみが考慮される。この例では、ペーシング目的で監視された総スループットは、40Mbpsに調整される。これらは、例えば、パケットモニタによって追跡され得る。
他の実施形態では、インフライトバイトカウントをビットレートに変換することは、接続の総推定ビットレートおよび総輻輳ウィンドウ(CWND)に基づいている。例えば、合計推定ビットレートが30Mbps、合計CWNDが500KB、インフライトデータパケットが100KBの接続は、
の総スループットに寄与することになる。
監視された総スループットの変化に応答して、プロセッサは、タイムスタンプの理想的なシーケンスが何であるべきであったか(例えば、何が監視された総スループットの変化について事前に知られていたはずであったか)を決定し、変更された理想的なタイムスタンプが持続時間にわたって整列するように、まだ通信されていないデータパケット上のタイムスタンプのパケット間の間隔を修正するようにさらに構成され得る。ネットワークリンクの変更が検出または測定されるとき、例えば、デボンダからフィードバックが受信されるとき、またはインフライトパケットの混合が変更されるとき、例えば、過去に送信されたパケットが確認され、おそらく異なるタイプの他のパケットがそれに応じて送信されるとき、監視された総スループットの変更が生じる。
一部の実施形態では、データパケットのためのバッファであって、バッファは、データパケットが通信される順序を示すキューを定義する固定サイズが存在しないように、サイズを動的に増減するように適合され、データパケットのサブセットは、キュー内のデータパケットの対応する経年(例えば、滞在時間)に基づいてバッファから定期的に削除される。滞在時間は、タイムスタンプを比較することによって決定することができる。
図2は、データバッファに関するパケットを示すパケットペーシング図200である。
図200は、ペースの良い送信機が、同じネットワークを介してバースト的な送信機よりも高いスループットを実現することができる方法を示している。図は、2つの送信機を示しており、1つはペースが良く、もう他方はバースト的である。両方の送信機は、10MB/秒の速度で1MBのパケットを伝送し、そのパケットは、最大バッファサイズが5MB、およびドレインレートが10MB/秒のボトルネックリンクを通過する。
ペースの良い送信機は、100ミリ秒ごとに1MBのパケットを伝送する。これらのパケットがボトルネックリンクに到着すると、5MBのネットワークバッファに短時間滞在し、すぐにボトルネックレートで排出される。この送信機が実現した平均スループットは、完全な10MB/秒である。
バースト的な送信機は、毎秒10個の1MBパケットを伝送する。すべてのバーストの第1の5パケットは、ボトルネックリンクの5MBバッファにキューに入れられ、第2の5パケットはバッファが満杯になるとドロップされる。ボトルネックリンクはその後、10MB/秒の速度でバッファを排出し、これは、100ミリ秒ごとに1MBのパケットを意味する。1秒ごとに、第1の500msはボトルネックリンクがアクティブであるが、伝送するパケットがない(ドロップされた)ため、第2の500msはアイドル状態である。このバースト的な送信機が実現した平均スループットは5MB/秒である。
TCP輻輳制御アルゴリズム(例えば、Reno、CUBIC)は、ACKクロックされる。つまり、特定のビットレートでパケットを伝送せず、代わりに輻輳ウィンドウ(cwnd)の概念を維持することを意味する。
インフライトのバイト数(受信機によって未確認)がcwnd未満である限り、それらはできるだけ速く伝送される(新しいバイトが伝送可能であると仮定する)。インフライトがcwndになると、送信機は伝送を停止する。インフライトバイトの確認応答(ACK)が受信されたときにのみ再開される。したがって、伝送のビットレートおよびバースティック性は、ACKが到達する速度によって完全に支配される。
以下の説明では、TCP送信機がアプリケーションに制限されることはないと仮定する。つまり、インフライトがcwnd未満であるため、TCP送信機がバイトを伝送することを望むたびに、バイトが利用可能であることを意味する。また、TCP送信機が受信機ウィンドウ(rwin)に制限されていないと仮定する。つまり、TCP受信機は常に、少なくともcwndからインフライトを引いたバイト数を受け入れることができるとアドバタイズする。
図3は、シングルパス接続のボトルネックリンクが、TCP RenoおよびCUBICなどのACKクロックされたプロトコルのパケットを自然にペーシングすることができる方法を示す図300である。
新しいTCPフローのcwndは、低い妥当な値(初期のcwndと称される)で開始される。図では、これは時刻t=0msで示されている。この送信機の初期cwndは5パケットである。インフライトは最初は0に等しいため、送信機は最初のcwndに等しいパケットのバーストを送信する。これらのパケットがネットワーク(この図では、合計100msの一方向レイテンシを有する)を通過するとき、各ホップは、そのボトルネックレート(物理的に維持可能なビットレート)でのみバイトを伝送することができる。
最終的に、パケットはボトルネックであるホップに到着する。この例では、ボトルネックは、9パケットのバッファサイズ、および10msごとの5パケットのドレインレート(すなわち、2msのパケット間の間隔)を有する。このボトルネックは、パケットが受信機に到着すると、5つのパケットがボトルネックレートを反映するパケット間の間隔を有する(t=102、104、106、108、および110msに到着する)ように、パケットを時間内に「自然に」離間する。パケットは、ボトルネックリンクの自然なペーシング、5パケット/10msを使用している。
TCP受信機は、パケットが到着するとACKを生成するため、ACKは同じペースで伝送される(t=102、104、106、108、および110msで伝送される)。ACKは同じペースでTCP送信機に戻り(t=202、204、206、208、および210msに到着)、インフライトが同じペースで減少する。
結果として、インフライトが最初に0であったときのt=0での最初の伝送中のように、バーストではなく、ボトルネックレートで、インフライトをcwndに戻すためのTCP送信機による後続の伝送が自然に発生する。
それはまた、インフライトを減少させることに加えて、TCP送信機が受信した各ACKについて、cwndへの増加をもたらす可能性がある。増加の速度および大きさは、輻輳制御アルゴリズムとその内部状態に依存する。この例では、送信機はTCP Renoを使用しており、「スロースタート」フェーズにある。このように、cwndは、ACKされるパケットの数と同じ数だけ増加する。
これにより、「ペーシングバースト」が発生し、ACKされた各パケットでは、インフライトが1減少し、cwndが1増加し、TCP送信機が次のバーストで2パケットを伝送できるようになる。これらの小さなバーストは、上述の機構に従って、ボトルネックリンクによって再び「離間」(ペーシング)される。例えば、パケット6および7は、t=202msで伝送された2つのパケットの最初の「ペーシングバースト」であるが、1パケット/2msのボトルネックレートによって離間された受信機に到着する。したがって、t=304msおよびt=306msに到達する。
このサイクルは、TCP送信機が伝送レートを増加させる原因となる。TCP送信機がボトルネックリンクのスループットよりも高いビットレートに達すると、ボトルネックバッファにパケットを伝送するレートが、ボトルネックがバッファをドレインするレートを超え、バッファが充填される。やがてバッファが満杯になり、TCPフローが引き戻される(cwndを減らす)ことを知らせるパケットがドロップされる。
TCPフローは、後で同様の方法でスループットを増やそうと繰り返し試みる。したがって、TCPフローのスループットは、ボトルネックリンクのスループットの周りで変動する。
図4Aは、TCP RenoまたはCUBICフローが、ペーシングを明示的に考慮しないナイーブマルチパスボンディングシステム100を通過するときに何が起こるかを示す図400Aである。システムには、次の3つのパスがある。
500msレイテンシ、1パケット/10msドレインレート、2パケットバッファ
120msレイテンシ、2パケット/10msドレインレート、3パケットバッファ
50msレイテンシ、2パケット/10msドレインレート、4パケットバッファ
前述と同様に、初期インフライトは0パケットであり、初期cwndは5パケットであるため、TCP送信機は時刻t=0msで5パケットのバーストを伝送する。マルチパスボンディングシステムの例は、パケットをパスのドレインレートに比例して分割し、第1の接続にわたって1パケット、および他の接続にそれぞれ2パケットを意味する。
各接続は、異なるスループットおよびレイテンシを有するため、シーケンサ162は、宛先TCP受信機にそれらを解放する前に、パケットをバッファリングし、並べ替える必要がある。この例では、パケット番号1は、時刻t=510msでシーケンサ162に最後に到着し、この時点で、5つすべてのパケットが宛先TCP受信機にフラッシュされる。この動作は、非マルチパスシナリオで前述した「自然な」ペーシングを除去する。
ナイーブシーケンサ162を有するTCP受信機によって見られるパケットのバーストは、ACKのバーストを生成する。この例では、マルチパスシステムは、最速リンク上でACKを送信するので、それらはすべて、時間t=560でバーストとしてTCP送信機に到着する。前述の例のように、TCP送信機は「スロースタート」フェーズにあるため、このときcwndは最大10パケットを開放する。
図4Bは、次に何が起こるかを示す図400Bである。インフライトが0であり、cwndが10であるため、TCP送信機は、マルチパスシステムを通じてバーストで10のパケットを伝送する。また、10個のパケットを帯域幅に比例したパスに分割する。ただし、第2の接続には3つのバッファスロットしかないため、4つのパケットを伝送するには不十分であることを想起されたい。このように、パケット番号11はドロップされる。
TCP送信機は、これらのドロップを輻輳と解釈し、cwndを制限することによって、例えばその値を半分にするなどして、直ちにこの認識された輻輳を解決するためにアクションを実行する。ただし、この認識された輻輳は、ペーシングの欠如によって引き起こされる誤検知であることに留意されたい。それによって、cwndの早期縮小は、伝送レートを低下させ、このTCP接続上で実行されるアプリケーションは、スループットを低下させる。この例は、固定サイズバッファによるパケットのドロップを示すマルチパス接続を示しているが、マルチパスシステム自体がドロップのソースになる可能性もある。接続速度の異なる混合については、TCP送信機バーストサイズが十分に大きくなると、マルチパスシステムの入力バッファ(バッファサイズではなくパケット滞在時間に基づいてドロップするバッファであっても)がパケットをドロップすることができる。
TCPスループットに対するパケットバーストの負の副作用を回避するために、ボンディングシステム100がパケットへのペーシングを復元することが不可欠である。次の段落では、種々のアプローチが提案されている。
ボンディングされた接続は、単一の接続としてTCPフローに表示される。したがって、ボンディング接続の場合、パケットは、ボンディング接続の総スループットに等しいスループットを有する単一の接続上でパケットが伝送された場合に観察されるペーシングと同様のペーシングを示す必要がある。
図5Aは、元のパケットへのペーシングを復元するマルチパスシステムを示す図500Aである。これまでと同様に、パケット番号1はシーケンサ162に最後に到着するが、今回は、5つのパケットをすべて一度にフラッシュするのではなく、各パケットを遅延させることによってペーシングを復元し、最悪の接続のレイテンシ(510ms)によってすべて遅延され、すべての接続の総レート(5パケット/10ms)で伝送されたように見える。これは、2msのパケット間の間隔を意味する。
一実施形態では、これらの遅延の実装形態は、パケット上のタイムスタンプの形態のメタデータを使用して、送信機および受信機を通じて実現される。タイムスタンプを使用できるが、必ずしも送信機と受信機との間のクロックから同期させる必要はない。図5Aの例の目的のために、クロックは同期される。
マルチパス送信機は、0、2、4、6、および8msのタイムスタンプで5つのTCPデータセグメントをマーキングする。マルチパス受信機では、これらのパケットが受信され、バッファ内に配置されると、それらの現在の経年は、常に現在の時間からそれらのタイムスタンプを減算することによって計算することができる。この例では、マルチパス受信機は、各TCPセグメントがシステム内で510msを消費するまで、そのバッファ内の各TCPセグメントを保持する(遅延させる)。これは、マルチパス受信機が、その経年が510、512、514、516、および518msに達したときにのみ、それらを(それぞれ)TCP受信機エンドポイントに伝送することを意味する。
結果として、TCP ACKは、同じペーシングレートでTCP受信機によって生成および送信され、結果として、同じ2msのパケット間の間隔で(マルチパスシステムを介して)TCP送信機に戻る。次に、2msごとに1パケットのレートでインフライトを減らし、2msごとに1パケットのレートでcwndを増加させる。
図5Bは、図3の単一パスの例と同様に、適切なペースのACKがどのように適切なペースのバーストをもたらすかを示す図500Bである。イベントのタイムラインは次のとおりである。
ACKはt=560msに到達し、インフライト時間を1時間短縮し、cwndを1時間増加させ、2つのパケットを伝送することができる。
パケット番号6および7は、伝送され、その伝送レートに比例して利用可能なパスに分割される。すなわち、第1のパス上のパケット6、第2のパス上のパケット7である。
ACKはt=562msに到着し、さらに2つのパケットを伝送することができる。
パケット番号8および9は、利用可能なパスに比例して分割されて伝送される。すなわち、第3のパスのパケット8、第2のパスのパケット9である。最初のパスは、他の2つのパスの容量の半分に比例しているため、スキップされる。
プロセスは繰り返され、今回は図4Bとは異なり、第2のパスのバッファサイズ制限に達することはないため、パケットはドロップされない。結果として、TCP送信機はこの時点で輻輳を認識しないので、cwndを早期に減少させず、したがって伝送レートを早期に引き戻さない。TCP送信機は、cwndをインクリメントし続け、最終的には、ボンディングされたネットワークの完全な集約機能を真に反映する正しい大きな値に落ち着き、それによって全体的なスループットが向上する。
他の実施形態では、これは、シーケンサ162内の受信側で、送信機から受信側に直接または間接的に通信されるボンディングされた接続の総スループットに基づいて実現される。
一実施形態では、監視された総スループットは、独立制御チャネルを介して送信機から受信機に直接通信される。
別の実施形態では、送信機は、欠落した情報の一部を受信機に通信し、受信機は、次いで、送信機と同じアルゴリズムを実行して、総スループットを間接的に判定する。欠落情報は、総スループットの値よりもサイズが小さくてもよい。この代替アプローチは、ネットワークの使用量および遅延を節約できるが、受信機において複雑なコンピュータ処理機能を必要とする。かかるアプローチの一例は、参照によりその全体が本明細書に組み込まれる、IETFドラフトのdraft-cheng-iccrg-delivery-rate-estimation-00に記載されている。これは、送達速度、すなわち、一定期間に送信機から受信機に送達されるバイト数を計算することによって、ネットワークリンクのスループットを決定する。送達レートを正確に計算するには、
1)受信機に送達されたバイト数、
2)これらのバイトが送達された期間、および
3)伝送イベントごとに送信機でバイトが利用可能かどうか、の3つの情報が必要である。それ以外の場合はリンクが完全に利用されず(「アプリケーション制限」と称される)、計算された送達速度はリンクの実際のスループットよりも低い。
1)受信機に送達されたバイト数、
2)これらのバイトが送達された期間、および
3)伝送イベントごとに送信機でバイトが利用可能かどうか、の3つの情報が必要である。それ以外の場合はリンクが完全に利用されず(「アプリケーション制限」と称される)、計算された送達速度はリンクの実際のスループットよりも低い。
最初の2つの情報は、受信機がパケットを受信する際に、受信機によって決定される。任意の2つのパケット受信イベントが与えられた場合、受信機に送達されるバイト数は、最初のイベントのパケットを除外し、最後のイベントのパケットを含めた、これら2つのイベント間で受信されたすべてのパケットの合計サイズ(バイト単位)である。これらのバイトが送達された期間は、これら2つのイベントが発生した時間の差である。
ただし、第3の情報は、純粋に送信機のイベントに関連しているため、受信機で個別に決定することはできない。この欠落している情報は、1ビットで表すことができる。例えば、0のビット値は、送信機がすべての伝送イベントで利用可能なバイトを有していなかったことを示し(すなわち、スループット推定値が不正確であり得る)、1のビット値は、伝送機がすべての送信イベントで利用可能なバイトを有していたことを示す(すなわち、スループット推定値が正確である)。1ビットがネットワークリンクを介して通信可能な情報の最小量であることを考えると、スループット推定値を直接通信するための任意の代替のアプローチでは、少なくとも同等以上の量のビットが消費される。
受信機が総帯域幅の値を有すると、外部機構を使用してシーケンサ162バッファを排出することができる。例えば、一部のネットワークインターフェースは、特定のビットレートでパケットをリリースするようにハードウェアまたはドライバレベルで構成することができる。デボンダは、パケットを書き込むネットワークインターフェースを構成して、総スループットでパケットを解放することができる。別の実施形態では、受信機は、必要なペーシングを実現するために、パケットのサイズおよび総スループットを使用して、適切な時間にパケットを解放することができる。
別の実施形態では、マルチパス送信機は、自然なペーシングを得るために、利用可能な接続の特性を利用することができる。例えば、特定のTCPフローに属するパケットは、利用可能な接続のサブセット上でのみ伝送されてもよい。これらの接続のプロパティが同じ場合(またはサブセットに1つの接続しか含まれていない場合)、送信機または受信機による明示的な通信またはその他の意図的なアクションがなければ、ペーシングは自然に発生する。
別の実施形態では、パケットペーシングは、送信側のスケジューラ160内のパケットを変更することによっても復元され得る。このアプローチは、受信側でのデボンダへの総ボンディングスループットの通信を必要としないという利点を有する。フロー分類エンジン156は、送信側からのパケットに、エンドポイント102から受信される時間を含むメタデータをスタンプする。したがって、シングルバーストで受信されたパケットは、すべて同じタイムスタンプでスタンプされる。
前述のように、デボンダバッファでのシーケンサ162は、ジッタおよび並べ替えを低減するために、リリース前にパケットを再順序付けし、保持する。これは、メタデータのタイムスタンプに対するパケットの経年を比較することによって行われる。したがって、ペーシングなしの一実施形態では、フロー分類エンジン156でシングルバーストで受信されたパケットは、最終的に、シーケンサ162によって同時にすべて解放される。ボンダのスケジューラ160がパケットのタイムスタンプを変更し、デボンダのシーケンサ162が必要なペーシングを反映する異なる時間にそれらを解放するように、パケットペーシングを実現することができる。
一実施形態では、スケジューラ160によって使用される機構は、入力パケットのタイムスタンプを、ボンディングされた接続の総スループットと比較することである。パケット間の間隔が、パケットが総スループットよりも速い速度で受信されていることを示す場合、それらのタイムスタンプは、それらが必要なペースで受信されたように見えるように修正される。これらの修正は、タイムスタンプを未来にプッシュする可能性があることに留意されたい。
これは、正確には、図5Aに記載されているとおりである。パケット1~5はすべて、0msのパケット間の間隔であるt=0で受信されている。この例では、実際の総スループットは5パケット/10msで、パケット間の間隔は2msである。スケジューラ160は、パケット1=0ms、パケット2=2ms、パケット3=4ms、パケット4=6ms、およびパケット5=8msとなるように、パケット上のタイムスタンプを調整する。パケット2~5はいずれも未来のタイムスタンプが付されている。この調整は、例えば、調整されているタイムスタンプを含む、送信機での各パケットに関連付けられたメタデータを変更することによって行われ得る。調整は、パケットをカプセル化するオーバーヘッドフィールドでも実行できる。これらのフィールドは、正しい時間に受信エンドポイントにパケットを送達するためにシーケンサ162によって使用される。
その後の総スループットの変更は、未来から使用される過去に修正されたタイムスタンプの一部が異なるはずであることを意味し得る。パケットがインフライト(すでに送信済み)である場合、これらのタイムスタンプは変更できなくなる。かかる場合、アルゴリズムは、タイムスタンプの理想的なシーケンスが何であるべきであったかを判定する。その結果は、変更されたタイムスタンプと理想的なタイムスタンプとが最終的に整列するように、まだインフライトしていないパケットのタイムスタンプのパケット間の間隔を修正する際に考慮される。
図6は、図600であり、アプローチが、総スループットが減少するとき、例えば、寄与するネットワークインターフェースの1つが電源を切るとき、または寄与するセルラーインターフェースが、セルラーサービスプロバイダのユーザの数が増加したために、より少ないスループットを提供するときに、どのように動作させることができるかの例を示している。時間t1において、8つのパケットがフロー分類エンジン156に到着する。スケジューラ160は、t1における総帯域幅を反映するようにそれらのタイムスタンプのパケット間の間隔を調整し、パケットは伝送される(それらはインフライトである)。理想的なタイムスタンプと変更されたタイムスタンプとは、この時点で等しい。
t2(インフライトパケット5のタイムスタンプと一致する)の後の時点で、総帯域幅は50%減少する。パケット5~8はインフライトであり、新規かつより遅い総帯域幅を反映するようにそれらのタイムスタンプを変更することはできない。しかしながら、タイムスタンプの理想的なセットは、新しいより遅い総帯域幅に従ってパケット5~8が離間されたかのようにシミュレートすることによって決定/計算され得る(遅い帯域幅は、パケット間の間隔が増加し、パケットを未来にさらに押し込むことを意味する)。
まだインフライトされていないパケットは、スケジューラ160によってタイムスタンプが修正され、パケット8が修正可能である場合に受信するはずの理想的な未来のタイムスタンプの後に開始される。このようにして、平均ペーシングレートは、時間t2における新たに検出された値と一致する。
図7Aは、総スループットが増加したときのアプローチの動作の例を示す図700Aである。パケット1~8は、時間t1でフロー分類エンジン156によって受信され、それらのタイムスタンプのパケット間の間隔は、t1での総帯域幅と一致するように、スケジューラ160によって補正され、パケットは伝送される(それらはインフライトである)。理想的なタイムスタンプと変更されたタイムスタンプとは、この時点で等しい。
時間t2(インフライトパケット5のタイムスタンプと一致する)で、総帯域幅は50%増加する。パケット5~8はインフライトであり、帯域幅の新たな増加を反映するためにそれらのタイムスタンプを変更することはできない。しかしながら、理想的なセットのタイムスタンプを計算することができ、新しいより高い総帯域幅に従ってパケット5~8が離間して配置されているかのようにシミュレートする(帯域幅が広いということは、パケット間の間隔が狭くなり、理想的なタイムスタンプが未来から現在に近づくことを意味する)。
時間t2において、パケット9~12もフロー分類エンジン156によって受信される。スケジューラ160は、パケット12のターゲット理想的なタイムスタンプを決定するために、インフライトパケット5~8の新しい理想的なタイムスタンプに対するこれらのパケットのパケット間の間隔を決定する。しかしながら、インフライトパケット5~8の実際のタイムスタンプは変更できないため、パケット9~12は、パケット8の実際のタイムスタンプとパケット12の理想的なタイムスタンプとの間のどこかで変更されたタイムスタンプを割り当てる必要がある。一実施形態は、タイムスタンプを、それらの2つの時間点の間に均等に配置する。理想的なタイムスタンプおよび変更されたタイムスタンプは、この操作の後に等しくなり、その後のパケット(13+)が理想的なタイムスタンプに対してペーシングされることを可能にする。
いくつかの実施形態は、未来のパケットの理想的なケースを対象とするように、変更されたタイムスタンプを必ずしも修正しない。図7Bの図700Bからわかるように、変更されたケースは、パケットのタイムスタンプが非常に小さいパケット間の間隔を有する(またはパケット間の間隔がない)ことを強制する可能性があるため、過度のバーストをもたらす可能性がある(これは、このアプローチが回避しようとしている元の問題である)。
目的はバーストを減らすことであるため、最小の許容パケット間の間隔の下限が適用され、パケットの現在のバーストのタイムスタンプが理想的なポイントを超えて(および再び未来に)移動する可能性がある。
フロアが現在の総スループットの理想的なパケット間の間隔よりも小さい限り、パケットの変更されたタイムスタンプは、より多くのパケットのペースと送信が行われるため、最終的に理想的なポイントと一致する(例えば「キャッチアップ」する)。
一部の実施形態では、最小の許容パケット間の間隔のフロアは、管理者の好みまたはアプリケーション要件などの入力に基づいて構成または決定することができるパラメータである。このパラメータで生じるトレードオフでは、総帯域幅が増加すると、より小さいフロアは、パケットの短期バーストを犠牲にして、増加した総帯域幅をより早く使用することを可能にする(これは、前述のように、ACKクロックされたプロトコルのパケット損失を引き起こす可能性がある)。
一部の実施形態では、シーケンサ162は、遅延パケットまたは損失パケットをどのように扱うべきかについて構成され得る。例えば、図5Aでは、パケット1がデボンダに到達しない場合、パケット2~5を宛先にフラッシュすることを決定するポイントは、管理上の好み、アプリケーション/プロトコル要件、接続挙動の統計分析などを考慮に入れることができる。例えば、受信アプリケーションが、これらのパケットが送信アプリケーションによって生成された後1秒後に送達されるパケットに対して使用しない場合、シーケンサ162は、パケット1がまだ欠落しているか、またはパケット1の再伝送がまだ到着していない場合であっても、1秒の期限に達する前に、パケット2~5をデボンダにフラッシュ(すなわち送達)する必要がある。言い換えれば、アプリケーションは、遅すぎて使用できなくなったときに5つのパケットすべてを受信するよりも、合理的な時間枠で5つのパケットのうち4つを受信する方がよい。重要なことは、パケット2~5のパケット間の間隔は、このプロセスの結果として変化しないことである。修正されたペーシングは維持される、すべてのパケットは、同じ量だけ時間的にオフセットされる。
パケット1が最終的に到着した場合、それを宛先に遅く転送するか、それともそれをドロップするかの決定は、管理者の好み、アプリケーション/プロトコル要件、接続挙動の統計分析なども考慮に入れることができる。遅延パケットを宛先に転送することが決定された場合、その前後に順次伝送されたパケットはすでに宛先に伝送されていたため、そのペーシングは保持されない。一部の実施形態では、遅延パケットのペーシングは、シーケンサ162によって考慮されてもよく、例えば、過度のバーストを防止するために遅延パケットの伝送をさらに遅延させる。
さらに別の実施形態では、マルチパス送信機および受信機は、所望のペーシングを実現するために一緒に動作することができる。例えば、スケジューラ160は、図6、7A、および7Bについて先に説明したように、現在の所望のペーシングレートを反映するようにパケットメタデータ内のタイムスタンプを変更することによって、パケット間の間隔を変更することができる。ペーシングレートがその後変化する場合、スケジューラ160は、インフライトパケット上のタイムスタンプが何らかの形で修正されたことにして、パケット間の間隔を変更し続けることができる。総帯域幅が増加する場合、これは、非単調タイムスタンプ(すなわち、時間を遡るように見えるタイムスタンプ)を有する連続パケットをもたらす。非単調タイムスタンプの修正は、パケットを宛先にフラッシュする前にシーケンサ162で行われ得る。
さらに別の実施形態では、マルチパス送信機および受信機は、所望のペーシングを実現するために一緒に動作することができる。例えば、スケジューラ160は、図6、7A、および7Bについて先に説明したように、現在の所望のペーシングレートを反映するようにパケットメタデータ内のタイムスタンプを変更することによって、パケット間の間隔を変更することができる。ペーシングレートがその後変化する場合、スケジューラ160は、インフライトパケット上のタイムスタンプが何らかの形で修正されたことにして、パケット間の間隔を変更し続けることができる。総帯域幅が増加する場合、これは、非単調タイムスタンプ(すなわち、時間を遡るように見えるタイムスタンプ)を有する連続パケットをもたらす。非単調タイムスタンプの修正は、パケットを宛先にフラッシュする前にシーケンサ162で行われ得る。
図8は、一部の実施形態による、例示的なシステム800の構成要素を示すブロック図である。この例では、上流デバイス802は、下流デバイス810と通信している。通信は、一方向(例えば、上流デバイス802および下流デバイス810の一方が伝送機デバイスとして動作し、反対側が受信機デバイスとして動作する)であっても、双方向であってもよく、上流デバイス802および下流デバイス810の両方が、データパケットを通信するために伝送機および受信機として動作する。
図8の図800の簡略化された例では、マルチパスゲートウェイ機構804および808は、伝送側804および受信側808として示され、806で潜在的なインフライト変更が行われる(破線で示される)。本明細書の種々の実施形態で説明されるように、伝送側804および受信側808として示される1つ以上の、806における潜在的なインフライト変更(破線で示される)を有するものは、データパケット送達フロー変更機構(例えば、プロトコル)を行う(例えば、または強制する)ために使用され得る。
(新規の接続が利用可能になる/実現可能になる、および/または既存の接続が利用不可能になる/利用不可能になるにつれてメンバーシップが動的であり得る)ボンディングされた接続のセットが評価され、全体的なスループットまたは他の総通信特性が確立され、次いで、データパケットペーシング/間隔が変更され得るように、伝送側804および受信側808、またはインフライト変更デバイス806のうちの少なくとも1つに通信される。
特に、データパケットが監視された総スループットまたは他の集約された通信特性よりも速い速度で通信されている場合、データパケットが伝送されている(またはインフライトで、または受信機でバッファリングされている)ことに対応する特性は、少なくとも監視された総スループットに基づいて変更され得る。
図9の図900に示されるように、通常のシーケンサ160と組み合わせて動作するスマートスケジューラ158が存在し得る。この例では、マルチパス伝送機904は、接続1、2、および3を含むことができる接続906にわたる伝送中/伝送前に、入力デバイス902からのデータパケットの特性を変更するように適合される。この例におけるマルチパス受信機908のシーケンサ160は、変更された特性を認識しない場合があり、出力デバイス910に送達するためのデータパケットを受信する。
図10の図1000に示されるような代替の変形例が可能であり、ここで、マルチパス伝送機1004のスケジューラが、接続1006にわたってパケット間隔/ペーシングを行うことなく、クライアント1002からデータパケットを伝送し、マルチパス受信機1008におけるバッファが、シーケンス順序を認識し、タイムスタンプおよび通信された総帯域幅(または他のネットワーク特性)に基づいて、データパケットをサーバ1010にフラッシュする前に、データパケットを並べ替えている。
図11の図1100に示されるような別の代替の変形例が可能であり、入力デバイス1102がデータパケットを伝送機1104に提供して、最終的に受信機1108を介して出力デバイス1110に伝送している。この例では、インフライト変更調整エンジン1112は、データパケットが総帯域幅または他のネットワーク特性に基づいて移動する中間ルータを制御するように適合される。次いで、中間ルータは、種々の実施形態に従って、データパケットペーシング/間隔を変更する。最も遅い中間ルータは、一部の実施形態では、すべてのボンディングされた接続に必要な間隔を確立する。
図12の図1200に示されるように、スマートスケジューラ158は、スマートシーケンサ160と連携して動作することができる。この例では、スマートスケジューラ158がスマートシーケンサ160と協働して、パケット間隔機構を確立および実施するシステムによって、より大きな複雑性が利用される。例えば、複数の接続1206にわたって、入力デバイス1202と出力デバイス1210との間の通信のために双方向のトラフィックフローが離間されるように、異なる役割が割り当てられてもよい。異なる役割には、タイムスタンプを変更するスマートスケジューラ158またはスマートシーケンサ160の一方が含まれ得、他方はバッファリングプロトコルを確立する。
図13は、ステップ1302、1304、1306、および1308を示す、一部の実施形態による、データパケット送達フローを管理する方法を例示するプロセス図1300である。他のステップが可能であり、図1300は例示的な目的のための例である。
図14は、一実施形態の例であるコンピューティングデバイス1400の概略図である。描写されるように、コンピューティングデバイス1400は、少なくとも1つのプロセッサ1402、メモリ1404、少なくとも1つのI/Oインターフェース1406、および少なくとも1つのネットワークインターフェース1408を含む。
各プロセッサ1402は、例えば、マイクロプロセッサまたはマイクロコントローラ、デジタル信号処理(DSP)プロセッサ、集積回路、フィールドプログラマブルゲートアレイ(FPGA)、リコンフィギュラブルプロセッサ、プログラマブル読み取り専用メモリ(PROM)、またはそれらの組み合わせであり得る。
メモリ1404は、例えば、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、コンパクトディスク読み取り専用メモリ(CDROM)、電気光学メモリ、磁気光学メモリ、消去可能プログラマブル読み取り専用メモリ(EPROM)、および電気消去可能プログラマブル読み取り専用メモリ(EEPROM)、強誘電性RAM(FRAM)などの内部または外部のいずれかに位置するコンピュータメモリの組み合わせを含んでもよい。
各I/Oインターフェース1406は、コンピューティングデバイス1400が、キーボード、マウス、カメラ、タッチスクリーン、およびマイクロフォンなどの1つ以上の入力デバイス、またはディスプレイ画面およびスピーカなどの1つ以上の出力デバイスと相互接続することを可能にする。
各ネットワークインターフェース1408は、コンピューティングデバイス1400が、インターネット、イーサネット、プレーンオールドテレフォンサービス(POTS)回線、公衆交換電話ネットワーク(PSTN)、統合サービスデジタルネットワーク(ISDN)、デジタル加入者回線(DSL)、同軸ケーブル、光ファイバ、衛星、モバイル、無線(例えばWi-Fi、WiMAX)、SS7信号通信ネットワーク、固定回線、ローカルエリアネットワーク、ワイドエリアネットワーク、およびこれらの組み合わせを含む他のものを含むデータを搬送し得るネットワーク(または複数のネットワーク)に接続することによって、他の構成要素と通信し、他の構成要素とデータを交換し、ネットワークリソースにアクセスおよび接続し、アプリケーションを提供し、他のコンピューティングアプリケーションを実行することを可能にする。
別の実施形態では、特殊目的機械は、使用のために構成され、提供される。かかる特殊目的機械は、限定された範囲の機能で構成され、組み込みファームウェアまたはソフトウェアからの命令に従って特定の機能を実行するようにプログラムされた効率的なデバイスに特徴を提供するように特別に構成される。この実施形態では、専用機械は、一般的なコンピューティング機能を提供しない。例えば、コントローラボードおよびスケジューラを含む特定のデバイスは、特定用途向け集積回路などの集積回路の形態で提供され得る。
この特定用途向け集積回路は、ゲートの特定の構成を通じて、上述のような複雑な機能を実行するために一緒に組み合わされるプログラムされたゲートを含み得る。これらのゲートは、例えば、互いの間にセルおよび電気的接続を有する下位レベルの構築物を形成し得る。特定用途向け集積回路の潜在的な利点は、効率の向上、伝播遅延の低減、および消費電力の低減である。特定用途向け集積回路は、回路の空間と体積が関連する要因である小型化要件を満たすのにも役立ち得る。
「接続された」または「結合された」という用語は、直接結合(互いに結合された2つの要素が互いに接触する)および間接結合(少なくとも1つの追加の要素が2つの要素の間に位置する)の両方を含み得る。
実施形態は詳細に説明されているが、本明細書では、範囲から逸脱することなく、種々の変更、置換、および改変を行うことができることを理解されたい。さらに、本出願の範囲は、本明細書に記載されるプロセス、機械、製造、物質の組成、手段、方法およびステップの特定の実施形態に限定されることを意図しない。
当業者が本開示から容易に理解するように、本明細書に記載される対応する実施形態と実質的に同じ機能を実行するか、または実質的に同じ結果を実現する、現在存在するか、または後に開発される物質、手段、方法、またはステップのプロセス、機械、製造、組成物が利用され得る。したがって、添付の実施形態は、かかるプロセス、機械、製造、物質の組成物、手段、方法、またはステップをそれらの範囲内に含むことが意図される。
理解され得るように、上記に記載され、例示される実施例は、例示的なものに過ぎないことが意図される。
Claims (28)
- 1つ以上のデータパケットが、マルチパスネットワークリンクのセットにわたって通信されているデータパケット送達フローを管理するためのシステムであって、前記システムが、
プロセッサであって、
一緒に動作する前記マルチパスネットワークリンクのセットを介して提供される総スループットを監視することと、
前記1つ以上のデータパケットが前記監視された総スループットよりも速い速度で通信されている場合、前記1つ以上のデータパケットを遅延させ、それにより前記1つ以上のデータパケットが必要なペースで通信されているように見えるように、少なくとも前記監視された総スループットに基づいてパケット間隔操作を実行することと、を行うように構成されたプロセッサを含む、システム。 - パケット間隔操作が、前記1つ以上のデータパケットのうちの少なくとも1つのデータパケットに対応する1つ以上のタイムスタンプを変更することによって実行される、請求項1に記載のシステム。
- 前記必要なペースが、前記1つ以上のデータパケットの非冗長データパケットの受信から決定されたペースに基づいて確立され、前記非冗長データパケットが、前記1つ以上のデータパケットの検査を通じて前記1つ以上のデータパケットの冗長パケットと区別されている、請求項1に記載のシステム。
- 前記1つ以上のデータパケットが単一のネットワークリンクを介して通信された場合、前記パケット間隔操作が、前記1つ以上のデータパケットに、ペーシングと実質的に同様のパケット通信ペースを復元するように適合されている、請求項1に記載のシステム。
- 前記パケット間隔操作は、前記1つ以上のデータパケットが、前記マルチパスネットワークリンクのセットから前記1つ以上のデータパケットを受信し、元のデータフローシーケンスを再生成するように構成された接続デボンディングデバイスで受信されるときに実行される、請求項1に記載のシステム。
- 前記パケット間隔操作は、前記1つ以上のデータパケットが、元のデータフローシーケンスに基づいて、前記マルチパスネットワークリンクのセット全体にわたって伝送するために前記1つ以上のデータパケットを割り当てるように構成された接続ボンディングデバイスで伝送されるときに実行される、請求項1に記載のシステム。
- 前記監視された総スループットの変化に応答して、前記プロセッサは、タイムスタンプの理想的なシーケンスが何であるかを判定し、変更された理想的なタイムスタンプが持続時間にわたって整列するように、まだ通信されていない1つ以上のデータパケット上の前記1つ以上のタイムスタンプのパケット間の間隔を修正するようにさらに構成されている、請求項2に記載のシステム。
- 前記1つ以上のタイムスタンプの変更が、少なくとも1つのタイムスタンプが未来のタイムスタンプを反映するように修正されることを含む、請求項2に記載のシステム。
- 前記総スループットまたは欠落情報をデータフィールド値として記憶するデータパケットが、独立制御チャネルを介して伝送され、受信機デバイスまたは伝送機デバイスのうちの少なくとも1つに伝送される、請求項1に記載のシステム。
- 前記プロセッサが、受信機デバイスまたは伝送機デバイスのうちの少なくとも一方に結合され、補完システムが、前記システムおよび前記補完システムが、前記総スループットを決定するために実質的に整列したパケット間隔機構を動作させるように、前記受信機デバイスまたは前記伝送機デバイスのうちの他方に結合されている、請求項1に記載のシステム。
- 前記1つ以上のデータパケットが、前記1つ以上のデータパケットのバッファで受信され、前記バッファが、データパケットが通信される順序を示すキューを定義するための固定サイズが存在しないように、サイズを動的に増加または減少させるように適合され、
前記1つ以上のデータパケットのサブセットが、前記キュー内の前記1つ以上のデータパケットの対応する経年に少なくとも基づいて、前記バッファから定期的に削除される、請求項1に記載のシステム。 - 1つ以上のデータパケットが、マルチパスネットワークリンクのセットにわたって通信されているデータパケット送達フローを管理するための方法であって、前記方法が、
一緒に動作する前記マルチパスネットワークリンクのセットを介して提供される総スループットを監視することと、
前記1つ以上のデータパケットが前記監視された総スループットよりも速い速度で通信されている場合、前記1つ以上のデータパケットを遅延させ、それにより前記1つ以上のデータパケットが必要なペースで通信されているように見えるように、少なくとも前記監視された総スループットに基づいて、前記1つ以上のデータパケットのうちの少なくとも1つのデータパケットに対応する特性を変更することによって、パケット間隔操作を実行することと、を含む、方法。 - 前記特性が、前記1つ以上のデータパケットが必要なペースで通信されているように見えるように変更される1つ以上のタイムスタンプを含む、請求項12に記載の方法。
- 前記1つ以上のデータパケットが単一のネットワークリンクを介して通信された場合、前記パケット間隔操作が、前記1つ以上のデータパケットに、ペーシングと実質的に同様のパケット通信ペースを復元するように適合されている、請求項12に記載の方法。
- 前記パケット間隔操作は、前記1つ以上のデータパケットが、前記マルチパスネットワークリンクのセットから前記1つ以上のデータパケットを受信し、元のデータフローシーケンスを再生成するように構成された接続デボンディングデバイスで受信されるときに実行される、請求項12に記載の方法。
- 前記パケット間隔操作は、前記1つ以上のデータパケットが、元のデータフローシーケンスに基づいて、前記マルチパスネットワークリンクのセット全体にわたって伝送するために前記1つ以上のデータパケットを割り当てるように構成された接続ボンディングデバイスで伝送されるときに実行される、請求項12に記載の方法。
- 前記監視された総スループットの変化に応答して、前記プロセッサは、タイムスタンプの理想的なシーケンスが何であるかを判定し、変更された理想的なタイムスタンプが持続時間にわたって整列するように、まだ通信されていない1つ以上のデータパケット上の前記1つ以上のタイムスタンプのパケット間の間隔を修正するようにさらに構成されている、請求項13に記載の方法。
- 前記1つ以上のタイムスタンプの変更が、少なくとも1つのタイムスタンプが未来のタイムスタンプを反映するように修正されることを含む、請求項13に記載の方法。
- 前記総スループットまたは欠落情報をデータフィールド値として記憶するデータパケットが、独立制御チャネルを介して伝送され、受信機デバイスまたは伝送機デバイスのうちの少なくとも1つに伝送される、請求項12に記載の方法。
- 前記プロセッサが、受信機デバイスまたは伝送機デバイスのうちの少なくとも1つに結合され、補完方法は、前記方法および前記補完方法が、前記総スループットを決定するために実質的に整列したパケット間隔機構を動作させるように、前記受信機デバイスまたは前記伝送機デバイスのうちの前記他方に結合されている、請求項12に記載の方法。
- 前記1つ以上のデータパケットが、前記1つ以上のデータパケットのバッファで受信され、前記バッファが、データパケットが通信される順序を示すキューを定義するための固定サイズが存在しないように、サイズを動的に増加または減少させるように適合され、
前記1つ以上のデータパケットのサブセットが、前記キュー内の前記1つ以上のデータパケットの対応する経年に少なくとも基づいて、前記バッファから定期的に削除される、請求項12に記載の方法。 - 機械可読命令を記憶する非一時的コンピュータ可読媒体であって、前記機械可読命令が、プロセッサによって実行されると、前記プロセッサに、1つ以上のデータパケットが、請求項12~20のいずれか一項に記載のマルチパスネットワークリンクのセットにわたって通信されているデータパケット送達フローを管理する方法を実行させる、非一時的コンピュータ可読媒体。
- 前記マルチパスネットワークリンクのセットの1つの端部に結合された送信機デバイスのクロックと、前記マルチパスネットワークリンクのセットの別の端部に結合された受信機デバイスのクロックとが同期されている、請求項2に記載のシステム。
- 前記1つ以上のタイムスタンプを前記変更することが、前記受信機デバイスの観点から、前記1つ以上のパケットのすべてが、前記マルチパスネットワークリンクのセットの最悪の接続のレイテンシによって遅延され、前記マルチパスネットワークリンクのセットのすべての総レートで伝送されたように、前記1つ以上のパケットが到着するように、前記1つ以上のデータパケットのうちの少なくとも1つのデータパケットに遅延を追加することと、パケット間の間隔を確立することと、を含む、請求項23に記載のシステム。
- 前記1つ以上のデータパケットの前記少なくとも1つのデータパケットの前記遅延が、前記追加された遅延に従って再伝送するためのバッファに前記1つ以上のデータパケットを記憶することを含む、請求項24に記載のシステム。
- 前記1つ以上のデータパケットが、ACKクロックプロトコルに従って構成されたパケットである、請求項25に記載のシステム。
- 前記パケット間の間隔が、前記ACKクロックプロトコルに関する最小の許容パケット間の間隔によって確立されたフロア値に基づいている、請求項26に記載のシステム。
- 前記1つ以上のタイムスタンプを前記変更することが、前記1つ以上のタイムスタンプを非単調であるタイムスタンプを有するように変更することをさらに含む、請求項26に記載のシステム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962884514P | 2019-08-08 | 2019-08-08 | |
US62/884,514 | 2019-08-08 | ||
PCT/CA2020/051090 WO2021022383A1 (en) | 2019-08-08 | 2020-08-07 | Systems and methods for managing data packet communications |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2022545179A true JP2022545179A (ja) | 2022-10-26 |
Family
ID=74502395
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022506839A Pending JP2022545179A (ja) | 2019-08-08 | 2020-08-07 | データパケット通信を管理するためのシステムおよび方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US20220294727A1 (ja) |
EP (1) | EP4011046A4 (ja) |
JP (1) | JP2022545179A (ja) |
AU (1) | AU2020326739A1 (ja) |
CA (1) | CA3149828A1 (ja) |
WO (1) | WO2021022383A1 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP4062599B1 (en) * | 2020-01-28 | 2023-07-12 | British Telecommunications public limited company | Routing of bursty data flows |
CN112261491B (zh) * | 2020-12-22 | 2021-04-16 | 北京达佳互联信息技术有限公司 | 视频时序标注方法、装置、电子设备及存储介质 |
CN113965517B (zh) * | 2021-09-09 | 2024-05-28 | 深圳清华大学研究院 | 网络传输方法、装置、电子设备及存储介质 |
WO2023163581A1 (en) * | 2022-02-23 | 2023-08-31 | Petroliam Nasional Berhad (Petronas) | Coherent internet network bonding system |
JP2024017943A (ja) * | 2022-07-28 | 2024-02-08 | 株式会社東芝 | サーバ装置、通信装置、及び制御システム |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7039715B2 (en) * | 2002-05-21 | 2006-05-02 | Microsoft Corporation | Methods and systems for a receiver to allocate bandwidth among incoming communications flows |
US7616585B1 (en) * | 2006-02-28 | 2009-11-10 | Symantec Operating Corporation | Preventing network micro-congestion using send pacing based on end-to-end bandwidth |
FI119310B (fi) * | 2006-10-02 | 2008-09-30 | Tellabs Oy | Menetelmä ja laitteisto aikaleimainformaation siirtämiseksi |
US7796510B2 (en) * | 2007-03-12 | 2010-09-14 | Citrix Systems, Inc. | Systems and methods for providing virtual fair queueing of network traffic |
EP2772028B1 (en) * | 2011-10-28 | 2019-07-17 | Telecom Italia S.p.A. | Control system, gateway and method for selectively delaying network data flows |
US20140269359A1 (en) * | 2013-03-14 | 2014-09-18 | Google Inc. | Reduction of retransmission latency by combining pacing and forward error correction |
EP3278514B1 (en) * | 2015-03-30 | 2019-03-06 | British Telecommunications public limited company | Data transmission |
CA3048055A1 (en) * | 2016-12-21 | 2018-06-28 | Dejero Labs Inc. | Packet transmission system and method |
GB201721779D0 (en) * | 2017-12-22 | 2018-02-07 | Transpacket As | Data communication |
US20190379597A1 (en) * | 2018-06-06 | 2019-12-12 | Nokia Solutions And Networks Oy | Selective duplication of data in hybrid access networks |
-
2020
- 2020-08-07 AU AU2020326739A patent/AU2020326739A1/en active Pending
- 2020-08-07 US US17/633,540 patent/US20220294727A1/en active Pending
- 2020-08-07 WO PCT/CA2020/051090 patent/WO2021022383A1/en unknown
- 2020-08-07 JP JP2022506839A patent/JP2022545179A/ja active Pending
- 2020-08-07 EP EP20849867.5A patent/EP4011046A4/en active Pending
- 2020-08-07 CA CA3149828A patent/CA3149828A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
EP4011046A4 (en) | 2023-09-06 |
EP4011046A1 (en) | 2022-06-15 |
CA3149828A1 (en) | 2021-02-11 |
AU2020326739A1 (en) | 2022-02-03 |
WO2021022383A1 (en) | 2021-02-11 |
US20220294727A1 (en) | 2022-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11876711B2 (en) | Packet transmission system and method | |
US10178035B2 (en) | System and method for providing improved quality of service over broadband networks | |
Al-Saadi et al. | A survey of delay-based and hybrid TCP congestion control algorithms | |
US20220294727A1 (en) | Systems and methods for managing data packet communications | |
Amir et al. | Reliable Communication in Overlay Networks. | |
WO2019104097A1 (en) | Latency increase estimated rate limiter adjustment | |
CA2805105C (en) | System, method and computer program for intelligent packet distribution | |
WO2015021343A1 (en) | System and method for providing improved quality of service over broadband networks | |
EP2883333A1 (en) | System and method for providing improved quality of service over broadband networks | |
Alipio et al. | TCP incast solutions in data center networks: A classification and survey | |
Sisalem et al. | The direct adjustment algorithm: A TCP-friendly adaptation scheme | |
Alins et al. | XPLIT: A cross-layer architecture for TCP services over DVB-S2/ETSI QoS BSM | |
El-Marakby et al. | Towards managed real-time communications in the Internet environment | |
Jain et al. | Towards experimental evaluation of explicit congestion control | |
Venkataraman et al. | A priority-layered approach to transport for high bandwidth-delay product networks | |
Gholizadeh | Congestion Control in Software-Defined Networks: A Simulation Study | |
WO2021237370A1 (en) | Systems and methods for data transmission across unreliable connections | |
Akinyemi et al. | AN IMPROVED NETWORK CONGESTION AVOIDANCE MODEL | |
Ricardo et al. | On Congestion Control for Interactive Real-time Applications in Dynamic Heterogeneous 4G Networks | |
Smith | Responsive vs. Unresponsive Traffic: Active Queue Management for a Better-Than-Best-Effort Service |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20220606 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20220928 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230801 |