JP2023002774A - パケット伝送システムおよび方法 - Google Patents
パケット伝送システムおよび方法 Download PDFInfo
- Publication number
- JP2023002774A JP2023002774A JP2022172589A JP2022172589A JP2023002774A JP 2023002774 A JP2023002774 A JP 2023002774A JP 2022172589 A JP2022172589 A JP 2022172589A JP 2022172589 A JP2022172589 A JP 2022172589A JP 2023002774 A JP2023002774 A JP 2023002774A
- Authority
- JP
- Japan
- Prior art keywords
- packets
- packet
- network
- data
- bandwidth
- 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
- 238000000034 method Methods 0.000 title claims abstract description 94
- 230000005540 biological transmission Effects 0.000 title claims description 115
- 239000000872 buffer Substances 0.000 claims description 94
- 238000012544 monitoring process Methods 0.000 claims description 27
- 230000008569 process Effects 0.000 claims description 13
- 238000009826 distribution Methods 0.000 claims description 8
- 238000012360 testing method Methods 0.000 claims description 6
- 238000003860 storage Methods 0.000 claims description 5
- 230000009467 reduction Effects 0.000 claims description 3
- 238000004891 communication Methods 0.000 description 26
- 230000003139 buffering effect Effects 0.000 description 23
- 238000010586 diagram Methods 0.000 description 18
- 238000007726 management method Methods 0.000 description 13
- 230000006399 behavior Effects 0.000 description 11
- 230000006870 function Effects 0.000 description 11
- 238000012546 transfer Methods 0.000 description 11
- 230000001413 cellular effect Effects 0.000 description 9
- 230000008901 benefit Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 7
- 238000011084 recovery Methods 0.000 description 7
- 102100036409 Activated CDC42 kinase 1 Human genes 0.000 description 6
- 230000001133 acceleration Effects 0.000 description 6
- 238000013459 approach Methods 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 6
- 230000008878 coupling Effects 0.000 description 6
- 238000010168 coupling process Methods 0.000 description 6
- 238000005859 coupling reaction Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 239000000203 mixture Substances 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000008520 organization Effects 0.000 description 5
- 238000009966 trimming Methods 0.000 description 5
- 238000012937 correction Methods 0.000 description 4
- 230000003111 delayed effect Effects 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 102100025799 Protein phosphatase 1K, mitochondrial Human genes 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 3
- 230000003542 behavioural effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000007689 inspection Methods 0.000 description 3
- 238000004513 sizing Methods 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 230000003340 mental effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000035945 sensitivity Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 238000007619 statistical method Methods 0.000 description 2
- 241001522296 Erithacus rubecula Species 0.000 description 1
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000002146 bilateral effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000005562 fading Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000009499 grossing Methods 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000002156 mixing Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000002459 sustained effect Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 230000010415 tropism Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
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/74—Address processing for routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- 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/0852—Delays
-
- 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/0882—Utilisation of link capacity
-
- 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/22—Alternate routing
-
- 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/302—Route determination based on requested QoS
-
- 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
-
- 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/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
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)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
【課題】複数のネットワーク接続を通してデータフローをルーティングするネットワークゲートウェイ、そのための方法及びコンピュータ可読媒体を提供する。【解決手段】複数のネットワーク接続106を通してデータフローをルーティングするためのネットワークゲートウェイであるマルチパスゲートウェイ104、108は、複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースと、少なくとも1つのプロセッサであって、ネットワークインタフェースを通してパケットの順次バーストを送信し、パケットの順次バースト内のパケットが受信ノードにおいて記録されるタイムスタンプおよびパケットのサイズに基づいて、ネットワークインタフェースの帯域幅を生成し、生成した帯域幅に基づいて順次パケットのデータフローを複数のネットワーク接続を通してルーティングするプロセッサと、を備える。【選択図】図1
Description
(関連出願の相互参照)
本出願は、(1)2016年12月21日に出願された「パケット伝送システムおよび方法」という発明の名称の米国特許出願第62/437635号、および(2)2017年9月14日に出願された「パケット伝送システムおよび方法」という発明の名称の米国特許出願第62/558610号の非仮出願であり、かつそれらの優先権を含む全ての利益を主張するものである。これらの出願の両方は全て参照により組み込まれている。
本出願は、(1)2016年12月21日に出願された「パケット伝送システムおよび方法」という発明の名称の米国特許出願第62/437635号、および(2)2017年9月14日に出願された「パケット伝送システムおよび方法」という発明の名称の米国特許出願第62/558610号の非仮出願であり、かつそれらの優先権を含む全ての利益を主張するものである。これらの出願の両方は全て参照により組み込まれている。
本開示は、一般に電子通信の分野に関し、より具体的にはレイテンシ、スループット、ジッターおよびパケットシーケンスなどの競合する要求を有するプロトコルのための向上したパケットの伝送と、個々のデータ接続が損失性であったり、信頼できなかったり、あるいは著しく異なり得るか可変的なレイテンシ、伝送速度またはパケットロスを有し得る状況において向上した伝送速度および信頼性を実現するための複数のデータ接続の結合とに関する。
有線および無線ネットワークを通した電子データの伝送は各種パケット化法を用いて行うことができる。例えばパケットは、ユーザデータグラムプロトコル(UDP)および伝送制御プロトコル(TCP)などの各種プロトコルの下で提供され得る。UDPパケットの場合、パケットは「ベスト・エフォート型」ベースで提供され、これはトランスポート層にパケットごとに送信されるパケットの受信に関する肯定応答が存在しないことを意味する。従って、トランスポート層における効率的な伝送は単純化されており、乱れた順番のパケットまたは失われたパケットを柔軟に取り扱うのをアプリケーションに任せる。TCPパケットの場合、トランスポートプロトコルの一部としてエラー検査が行われ、かつアプリケーションが全てのデータを確実かつ順番通りに受信するのを保証するために、TCPパケットシーケンス番号および肯定応答が利用される。失われたパケットは、例えば明示的に再送される。
TCPを用いる場合、輻輳制御アルゴリズムが誤った順番のパケットをネットワーク伝送エラーによって引き起こされたとみなして伝送速度を落としてこれらの認識されたエラーを補償するので、誤った順番のパケットの受信は、TCPに組み込まれた肯定応答および再要求プロセスにより伝送効率に影響を与える場合がある。この問題は、著しく異なるレイテンシを有するデータ接続を単純に結合させ、これにより著しい伝送速度の低下(「ヘッドオブラインブロッキング(head of line blocking)」問題として知られている)が生じる場合に特に重要である。
異なるネットワークおよび/または接続を互いに結合することは技術的に難しい。単一のネットワークおよび/または接続は、特に伝送エラー、信号損失および冗長性の欠如を引き起こしやすい。結合されたネットワークおよび/または接続は、取材および報道などの様々なシナリオで特に有用であるが、その理由は、これらのシナリオは、個々に信頼できる接続を容易に利用可能でない場合があったり(例えば、農村地域、高地)、あるいは利用可能であったとしても混雑していたり(例えばスポーツイベント)、十分に機能しなかったりする(例えば自然災害後)様々な環境を通る信頼できる高帯域幅伝送を必要とするからである。
出願人らは、いくつかの実施形態では、ハイブリッドネットワーク接続を確立する際のネットワーク技術の技術的特徴の利用に対して非従来的な手法を適用する改良されたデータ伝送管理解決法を開発した。さらに詳細に記載されているように、さらなる技術的用法および手法は、実行可能な接続を確立するという措置が求められるため(例えば、上に記載したように「ヘッドオブライン」ブロッキング問題を回避するため)、TCPは特に結合するのが難しい。これらの改良されたハイブリッド接続は、例えば高帯域幅のビデオ、音声または他のデータを転送するために使用することができる。例えば災害状況では、特に緊急通信を確立し、地上報道を提供し、緊急遠隔医療を可能にするために改良されたハイブリッド接続を利用することができる。
ネットワーク接続を通してデータフローを制御するためのネットワークゲートウェイが、対応する方法、装置およびコンピュータ可読媒体と共に本明細書に記載されている。本ゲートウェイは、いくつかの実施形態では、プログラムコードまたはコンピュータ論理の形態のソフトウェアおよび組み込みファームウェアを代表とする命令セットに従ってデータパケットを受信してルーティングするように構成された、プロセッサ、インタフェース、バス、電源、メモリ(ROM、RAM、フラッシュ)などの構成要素を備えた物理的なハードウェア装置であってもよい。
本ネットワークゲートウェイは一例では、本明細書中のいくつかの例に記載されているように、TCP接続を結合するために特に最適化された専門の計算装置であってもよい。本ネットワークゲートウェイは他の例では、より大きなシステムの一部としてプロセッサおよび/または他のコンピューティングハードウェアを用いて実装されていてもよい。本ネットワークゲートウェイは単一の装置であってもよく、あるいは場合によっては、一斉に動作する複数の装置であってもよい。受信の時点で信号を再構築するために対応する結合解除サーバが設けられていてもよい。
一実施形態では、本ネットワークゲートウェイは複数のネットワーク接続を通してデータフローをルーティングするように構成されており、本ネットワークゲートウェイは、複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースと、少なくとも1つのプロセッサであって、複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、パケットのデータフローの少なくとも1つのパケットを解析してデータフローのためのデータフロークラスを特定することであって、そのデータフロークラスは、データフローの少なくとも1つのネットワークインタフェース要件を定めることと、データフロークラスおよび時変ネットワーク伝送特性に基づいてデータフロー内のパケットを複数のネットワーク接続を通してルーティングすることとのために構成された少なくとも1つのプロセッサとを備える。
別の実施形態では、本ネットワークゲートウェイは、複数のネットワーク接続を通してデータを伝送するための第1のネットワークインタフェースを含む複数のネットワークインタフェースを備える。本ネットワークゲートウェイは、第1のネットワークインタフェースを通してパケットの順次バーストを送信することのために構成されたプロセッサを備える。プロセッサは、パケットの順次バースト内のパケットが受信ノードで受信された場合に記録されるタイムスタンプおよびパケットのサイズに基づいて、第1のネットワークインタフェースの帯域幅を生成し、第1のネットワークインタフェースの生成された帯域幅に基づいて複数のネットワーク接続を通して順次パケットのデータフローをルーティングする。
一態様では、第1のネットワークインタフェースの帯域幅を生成することは、バースト内の最初もしくは最後のパケットと合体されていないバースト内のパケットのタイムスタンプに基づいて帯域幅を生成することを含む。
別の態様では、第1のネットワークインタフェースの帯域幅を生成することは、バースト内の特定のパケットの受信タイムスタンプを特定のパケット後に送信されたパケットの送信タイムスタンプと置き換えることを含む。
別の態様では、受信ノードが定期的な間隔で受信されたパケットを処理する場合、第1のネットワークインタフェースの帯域幅を生成することは、(i)帯域幅決定においてエンドパケットとして選択されたバースト内のパケットの受信タイムスタンプを用いることによって下限帯域幅値を生成することと、(ii)エンドパケットとして選択されたバースト内のパケットの受信タイムスタンプをエンドパケットに先行するバースト内のパケットの受信タイムスタンプと置き換えることによって上限帯域幅値を生成することとを含む。
別の態様では、プロセッサは、データフロー内の順次パケットの各パケットのために、データフロー内のパケットが所望のシーケンスで宛先ノードに到着するように、複数のネットワーク接続の監視されたレイテンシに基づく複数のネットワーク接続およびデータフロー内の他のパケットのネットワーク接続のうちの1つを通してルーティングするためのパケットを提供することのために構成されている。
別の態様では、所望のシーケンスは、データフロー内の順次パケットの元のシーケンスである。
別の態様では、所望のシーケンスは、そのシーケンス内でのパケットの再送をトリガーしないパケットの少なくとも1つの誤順序付けを含むシーケンスである。
別の態様では、プロセッサは、複数のネットワーク接続を介して宛先ノードにルーティングするためにソースインタフェースからパケットを受信することと、パケットを宛先ノードにルーティングする前に肯定応答をソースインタフェースに送信することと、パケットが宛先ノードにルーティングされる前にパケットを少なくとも1つのバッファに格納することとのために構成されている。
別の態様では、少なくとも1つのプロセッサは、複数のネットワーク接続に関連づけられた帯域幅遅延積に基づいて少なくとも1つのバッファのサイズを動的に制御することのために構成されている。
別の態様では、少なくとも1つのプロセッサは、複数のネットワーク接続の伝送特性の監視および順次パケットのデータフローの受信における不均等分配に基づいて、パケットの肯定応答の送信および格納を制御することのために構成されている。
別の態様では、少なくとも1つのプロセッサは、第1のデータ接続の帯域幅およびそれを通してデータフローがルーティングされるネットワーク接続の数の減少のうちの少なくとも1つに基づいてパケットを提供するように構成されている。
別の態様では、少なくとも1つのプロセッサは複数のデータフローのためにパケットをルーティングするように構成されており、ここでは少なくとも1つのプロセッサは、複数のデータフローの分類に基づいて複数のネットワーク接続のうちの1つを通してルーティングするための複数のデータフローのパケットを提供することのために構成されている。
別の態様では、複数のデータフローの1つの分類は、閾値体積のデータがルーティングされた後に変わる。
別の態様によれば、複数の同時データ接続を通した複数のフローに属するデータパケットのルーティングの制御に適したデータ伝送管理装置(「ゲートウェイ」)が提供され、各データ接続は複数のフローに属する複数のパケットを運び、ここでは、複数のフローの少なくとも1つは実質的に順次に伝送されるデータパケットを有し、データ伝送管理装置は、1つ以上の入力データ接続からフロー(入力データパケットのシーケンス)を受信するように構成されたバッファマネージャであって、バッファマネージャは入力データパケットをルーティングのために抽出された1つ以上のバッファに格納し、各入力データパケットはフローまたはシーケンスにおける順番を表す対応するシーケンス番号に関連づけられているバッファマネージャと、データ接続のそれぞれが異なる伝送特性を有する複数のデータ接続とインタフェース接続するように構成された接続制御装置と、複数のデータ接続を介して1つ以上のバッファからの入力データパケットのルーティングを制御するためにバッファマネージャによって実行される命令を生成することによってバッファマネージャの動作を制御するように構成されたスケジューラとを備え、そのルーティングは、各個々の入力データパケットのために、(i)そこを通って個々の入力データパケットが伝送される対応するデータ接続、および(ii)個々の入力データパケットが対応するデータ接続上で伝送される接続固有のタイミングまたはシーケンスを決定する。
別の態様では、上記装置は、一緒または個々に監視される複数のデータ接続のそれぞれを通した伝送特性を監視するように構成されたネットワーク特性監視ユニットをさらに備える。
別の態様では、上記装置は、1つ以上のバッファに格納された入力データパケットのルーティングを制御するためのスケジューラによって実行される命令を生成することによってスケジューラの動作を制御するように構成された動作エンジンをさらに備え、ルーティングは複数のデータ接続を通して監視される伝送特性に基づいて制御され、入力データセットに基づいてルーティングを修正するように構成された動作エンジンは、スループット、パケットロス、レイテンシ、明示的輻輳通知(ECN)コスト、信頼性、ジッター、ユーザ/管理嗜好および他のネットワーク接続制約のうちの少なくとも1つに関する情報を提供する。
別の態様では、上記装置は、入力データパケットのそれぞれのシーケンス番号に基づいてデータ伝送管理装置によって受信された入力データパケットを再構成するように構成されたシーケンサをさらに備える。
別の態様では、上記装置は、固有の特性に基づいてフローを識別し、かつ動作エンジンおよびシーケンサにフロー情報を提供するように設計されたフロー識別エンジンをさらに備える。
別の態様では、上記装置は、入力データフローおよびそれらの要求を分類し、かつフローの特性および要求に基づいて、この情報を入力データフローのルーティングの修正のために動作エンジンに提供し、かつデータパケットを再構成する方法の修正のためにシーケンサに提供するように構成されたフロー分類エンジンをさらに備える。
別の態様では、バッファマネージャは、複数のデータ接続の伝送特性の可変性を補償するための過剰バッファリングと、伝送の不均等分配(「バースト性の伝送」)とを提供するようにさらに構成されている。
別の態様では、動作エンジンは、複数のデータ接続の各データ接続に関して帯域幅遅延積を決定するようにさらに構成されており、帯域幅遅延積はスケジューラによって制御されるようなルーティングを修正するために使用される。
別の態様では、動作エンジンは、不完全な情報が利用可能な場合に帯域幅推定を行うようにさらに構成されている。
別の態様では、1つ以上の種類のデータトラフィック(フロー)は、FTP、DNS、HTTP、SSHおよびSSL/TLSのうちの少なくとも1つを含む。
別の態様では、動作エンジンは、1つ以上のデータフローのどれがレイテンシセンシティブであるかを決定するように構成されており、かつレイテンシセンシティブである1つ以上のデータフローのために、より低いおよび/または同様のレイテンシ特性を有する複数のデータ接続のデータ接続を介して、対応する入力データパケットのルーティングを優先的に維持する。このシナリオでは、動作エンジンは過剰バッファリング/バッファブロートを防止するために、この複数のデータ接続を介するレイテンシセンシティブでないフローのルーティングも防止してもよい。
別の態様では、動作エンジンは、複数のデータ接続を通してそれらの性能を最適化するために公知のプロトコルのヘッダー情報を修正するようにさらに構成されている。例えば、複数のデータ接続が1つ以上の高レイテンシ地上波衛星接続を含む場合、最適化エンジンは、フローが高帯域幅遅延積を利用できる(TCP加速法として知られている)ようにするために、宣伝されているTCPウィンドウサイズを調整してもよい。これらの変更は、フロー毎ベースでさらなるパケットをバッファするためのバッファマネージャをさらに必要としてもよい。別の例は、データパケットの断片化を防止するために複数のデータ接続によってサポートされる最も小さいMSS(最大のセグメントサイズ)に一致させるためのTCP MSSヘッダオプションの修正である。
別の態様では、複数のデータ接続を通してデータフロー(データパケットからなる)のルーティングを制御して複数のデータフローのうちの少なくとも1つが実質的に順次に伝送される改良された伝送性能を提供するためのデータ伝送管理方法が提供され、データ伝送管理方法は、1つ以上の入力データソースから、データフローまたはシーケンスにおける順番を表す対応するシーケンス番号に関連づけられている入力データパケットのストリームまたはシーケンスを受信して、ルーティングのために抽出された1つ以上のバッファに格納することと、データ接続のそれぞれが異なる伝送特性を有する複数のデータ接続とインタフェース接続することと、1つ以上のバッファを制御して入力データパケットを複数のデータ接続を通してルーティングするスケジューラによってルーティング命令を生成することであって、上記命令は各個々の入力データパケットのために、(i)そこを通って個々の入力データパケットが伝送される対応するデータ接続と、(ii)個々の入力データパケットが対応するデータ接続上で伝送される接続固有のタイミングまたはシーケンスとを提供することと、入力データパケットをルーティング命令に従ってルーティングすることとを含む。
別の態様では、命令を格納する非一時的コンピュータ可読媒体が提供され、上記命令は実行されると、プロセスに複数のデータ接続を通したデータフロー(データパケットからなる)のルーティングを制御するためのデータ伝送管理方法の工程を行わせて、複数のデータフローのうちの少なくとも1つが実質的に順次に伝送される改良された伝送性能を提供し、本方法は、1つ以上の入力データソースから、データフローまたはシーケンスにおける順番を表す対応するシーケンス番号に関連づけられている入力データパケットのストリームまたはシーケンスを受信して、ルーティングのために抽出された1つ以上のバッファに格納することと、データ接続のそれぞれが異なる伝送特性を有する複数のデータ接続とインタフェース接続することと、スケジューラによってルーティング命令を生成し、1つ以上のバッファを制御して入力データパケットを複数のデータ接続を介してルーティングすることであって、上記命令は、各個々の入力データパケットのために、(i)そこを通って個々の入力データパケットが伝送される対応するデータ接続と、(ii)個々の入力データパケットが対応するデータ接続上で伝送される接続固有のタイミングまたはシーケンスとを提供することと、入力データパケットをルーティング命令に従ってルーティングすることとを含む。
様々なさらなる態様では、本開示は、対応するシステムおよび装置と、そのようなシステム、装置および方法を実装するための機械実行可能コード化命令セットなどの論理構造を提供する。
この点に関して、少なくとも1つの実施形態を詳細に説明する前に、当該実施形態は適用において、以下の説明に記載されているか図面に図示されている構成の詳細または構成要素の配置に限定されないことを理解されたい。また当然のことながら、本明細書で用いられている表現法および用語は説明のためのものであり、限定するものとしてみなされるべきではない。
本明細書に記載されている実施形態に関する多くのさらなる特徴およびそれらの組み合わせは、本開示を読んだ後に当業者には明らかになるであろう。
図において実施形態は例として示されている。説明および図は単に例示のためのものであって、理解を助けるものであることをはっきりと理解すべきである。
次に実施形態を単なる一例として添付の図を参照しながら説明する。
方法、システムおよび装置の実施形態について図面を参照しながら説明する。
伝送制御プロトコル(TCP)は3ウェイハンドシェイクを利用して接続を確立するものであり、故に信頼できるプロトコルである(無接続プロトコルであるユーザデータグラムプロトコル(UDP)とは対照的)。これらのプロトコルは、例えばRFC793およびRFC7323に記載されており、これらは参照により本明細書に組み込まれる。
TCPは、より複雑な実装を必要とし、かつパケットの保証された順番どおりの配信に適している。この接続は、データ転送の前に最初に送信機と受信者との間で確立されなければならず、かつこの接続はデータ伝送の終了時に終了される場合が多い(割り当てられたリソースを解放するため)。
接続を確立するための最初のハンドシェイクは、データ伝送中に提供されるデータの順番を特定するためにデータ伝送中に使用される最初のシーケンス番号(例えば、任意のシーケンス番号)を提供する。
データ伝送中に、アプリケーションによって生成されたデータはデータパケットにセグメント化され、これらのデータパケットまたはセグメントは、それらが伝送のためにカプセル化されている場合には、頭に追加される情報(例えば、「ヘッダー」)を有する。ヘッダーは、例えばデータの各セグメントに関連づけられたシーケンス番号を示す伝送中に利用される情報を含む。シーケンス番号は、データのセグメントが乱れた順番で受信されたり、失われていたり(例えば、再送が要求される場合がある)、遅延していたり、破損されていたりなどしていても、データのセグメントを再順序付けして再構築することができるように、受信装置によって利用される。
TCP法は、さらなるプロセスを利用して伝送に関する問題を減らすのを助け、これらのプロセスとしては、フロー制御、エラー検出、再送プロトコル、輻輳制御、選択的肯定応答などが挙げられる。
いくつかのシナリオでは、改良されたデータ通信性能は一斉に動作する複数のデータ接続またはネットワークの使用により得てもよい。これらのデータ接続またはネットワークは、ネットワークが論理的に結合または連結されるように互いに「結合されている」ものとみなされてもよい。一斉に動作する2つ以上のネットワークは、特にデータの伝送、エラーの訂正の提供などの1つ以上の通信機能を行ってもよい。この文脈では、1つ以上のネットワークは必ずしも別個のネットワークである必要はないが、同じネットワークを通る異なるチャネル、異なるデータ接続などを含んでもよい。
有利には各ネットワークの組み合わせられた特性を利用するか多岐にわたる特性および能力を用いて得ることができる改良されたデータ伝送特性(向上した信頼性および上昇した速度など)が存在し得るので、結合されたネットワークが望ましい。ネットワークとしては例えば、様々な特性および品質を有する特にセルラーネットワーク、イーサネットネットワーク、WiFi、衛星ネットワークが挙げられる。
例えば特定のネットワーク接続(例えば、パス、チャネル)は、特定の種類の通信(例えば、エラー検出および制御信号のために低レイテンシだが低帯域幅)のために理想的なものになり得、別のネットワーク接続は、別の種類の通信(例えば、高スループットデータ転送のために高帯域幅)にとって理想的なものになり得る。いくつかの実施形態では、エンドポイント(例えば、送信機、受信機)は、データの通信のために利用されている通信パスまたは手法に気づくことを必要としないようなネットワークの結合を提供することができる。
TCPは、かなりの数のネットワークおよびトラフィックのために使用されているプロトコルであるため、改良された転送特性を有する結合されたTCP解決法を有することが特に望ましい。但し、結合されたTCP解決法は実装するのが難しい。
TCPに関する課題(特に各パケットの肯定応答を必要とするため)は、特にデータ接続が異なるレイテンシなどの有意に異なる特性を有するネットワークを通して提供される場合に、TCP接続は互いに「結合する」ことが技術的に難しいという点にある。これらの難点は、ネットワーク化されたTCP通信のために結合を利用する通信システムの効率に影響を与える。
データはデータ接続の組み合わせを通して(例えば、異なるネットワークを通して)1つ以上のエンドポイントに伝送され、データの伝送は、データを再度組み合わせることができ(例えば、「結合解除」システムによって)、かつ元のデータを伝送されたデータから再生成することができるように促進される。
その機能の接続および割当てのそのような「結合」は、例えば出願人の米国特許第8,873,560号に記載されており、この特許は参照により本明細書に組み込まれる。
結合プロセスは典型的に、その結合されたネットワークまたはデータ接続を通して伝送されるデータフローを含むデータパケットのセグメント化を必要とするので、TCPに関する結合の使用という文脈には克服する必要がある特定の技術的課題が存在する。異なる種類のトラフィック(例えば、ボイスデータ、制御パケット、ビデオデータ、エラー制御)は、順序付け要求によって異なって影響される。
データの転送のために結合されたネットワークを実装するシステムの技術的検討事項としては、限定されるものではないが、結合/結合解除の容易性(例えば、利用可能な計算リソースと比較した場合に必要とされる計算リソースおよび総計算時間)、転送レイテンシ、パケットロス、冗長性、セキュリティ、最大スループット、平均スループットおよび輻輳管理が挙げられる。
複数のネットワークまたはデータ接続を使用する単純なラウンドロビン解決法は典型的に、接続が同一もしくはほぼ同一の特性(例えば、レイテンシ、容量)を有する場合にのみ利点を提供する。1つの接続が著しくより高いレイテンシを有する場合は、全ての他のパケットは遅延し、かつ潜在的に送信機および受信機によって失われているか遅延しているものとして扱われ、それにより送信機にその輻輳ウィンドウ(cwnd)を減少させ、その結果としてスループットが低下する。
1つの接続が著しくより高い容量を有する場合、より低い容量の接続がその限界に達すると、その接続上で送信される全ての他のパケットが失われる。
従って、単純なラウンドロビン解決法は典型的にロードバランシングおよび冗長性には役立つが、接続が異なる特性を有する場合には、スループットを犠牲にして成り立つ。
マルチパスTCP(RFC6824)は、WiFiおよびセルラーなどの無線ネットワークを結合するために一般に使用されるトランスポート層解決法である。以下に記載するように、いくつかの実施形態のシステムは、マルチパスTCP(MPTCP)などの他の解決法と比較して有利な性能を提供することができる。その理由は以下のとおりである。
1)MPTCPは、MPTCPを使用して処理することができるようにするために両方のエンドポイント(クライアント(C)およびサーバ(S))を必要とする。両方のエンドポイントは複数のパスについて知っているので、それらのうちのそれぞれの上で独立した輻輳制御アルゴリズムを実行させ、かつエンドポイントは、標準的なTCPスタックに関する上記問題に遭遇しない。対照的に、ここに開示されているシステムは、いくつかの実施形態では、エンドポイントがMPTCPと同時に使用するように構成されていない場合に機能したり、あるいは複数のパスはエンドポイントに直接接続されていなかったりする(すなわち、複数のパスはエンドポイント間の中間ホップにのみ知られている)。
2)MPTCPは、輻輳リンク(「連結された輻輳制御」)を通る他の非MPTCPフローと競合する場合に公平になるように試みる。広範囲にわたって配備されない明示的輻輳通知(ECN)を使用しない場合、MPTCPシステムは自身が見ている任意の輻輳が全てのサブフローによって共有されているリンク上にあるか否かを推測する。それは多くの場合に誤って推測し、予想よりも低いスループットが生じる。
1)MPTCPは、MPTCPを使用して処理することができるようにするために両方のエンドポイント(クライアント(C)およびサーバ(S))を必要とする。両方のエンドポイントは複数のパスについて知っているので、それらのうちのそれぞれの上で独立した輻輳制御アルゴリズムを実行させ、かつエンドポイントは、標準的なTCPスタックに関する上記問題に遭遇しない。対照的に、ここに開示されているシステムは、いくつかの実施形態では、エンドポイントがMPTCPと同時に使用するように構成されていない場合に機能したり、あるいは複数のパスはエンドポイントに直接接続されていなかったりする(すなわち、複数のパスはエンドポイント間の中間ホップにのみ知られている)。
2)MPTCPは、輻輳リンク(「連結された輻輳制御」)を通る他の非MPTCPフローと競合する場合に公平になるように試みる。広範囲にわたって配備されない明示的輻輳通知(ECN)を使用しない場合、MPTCPシステムは自身が見ている任意の輻輳が全てのサブフローによって共有されているリンク上にあるか否かを推測する。それは多くの場合に誤って推測し、予想よりも低いスループットが生じる。
図1に例解されているように、システム100は、本システムの送信部上で改良されたスケジューリング手法を利用し、かつパケットの順序付けを行う受信側でバッファリングシステムを使用するように構成されているものとして図示されている。図示されている構成要素は一実施形態では、互いとの相互動作のために構成されているハードウェア構成要素である。別の実施形態では、当該構成要素は別個の構成要素ではなく、当該構成要素のうちの2つ以上は特定のハードウェア構成要素(例えば、2つ以上の構成要素の機能を実施するコンピュータチップ)上に実装することができる。
いくつかの実施形態では、当該構成要素は同じプラットフォーム(例えば、同じプリント回路基板)上に存在し、システム100は、移動させ、かつデータセンタ/現場に持ち運び可能な(field carry-able)装置(例えば、堅牢なモバイル送信機)などに接続させることができる単一の装置である。別の実施形態では、当該構成要素は分散型であり、全てがごく近接して位置していなくてもよく、それどころか電気通信を通して電子的に通信する(例えば、処理および制御は局所的に行われるのではなく、分散されたリソース環境に存在する構成要素(例えばクラウド)によって行われる。
モバイルシナリオでは、信号品質、ネットワークの利用能、品質ネットワークなどが最適以下である場合に、結合された接続性を提供することが特に望ましい(例えば、専門的な取材/ビデオ作成は強力なネットワークインフラのない位置で行われる場合がある)。
接続1、接続2...接続Nとしてラベルが付された1つ以上のネットワーク(またはネットワークチャネル)を表す多くの異なるデータ接続106(例えば「パス」)が示されている。単一のネットワークを通る複数のデータ接続/パスまたは1つ以上のネットワークを使用することができる複数のデータ接続が存在してもよい。
システム100は、データを要求および受信するために使用される複数のパス/接続106に関する任意の情報を有する必要がない各種エンドポイント102、110またはアプリケーションと通信するように構成されていてもよい(例えば、エンドポイント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つのみのゲートウェイが必要とされてもよい(例えば、サービスとして単純なディザスタリカバリーが示されている図11を参照)。
本システムのスケジューリング部の特徴は、所与の接続の帯域幅を推定するための新しい手法である(例えば図8を参照)。
システム100は、例えば既存のインターネット接続(例えば、VoIP電話システム、またはウェブへの企業接続)のフェイルオーバーまたは追加として様々なシナリオのために利用することができ、それによりドロップされた一次インターネット接続を途切れなく置き換えるためにさらなるネットワーク(またはパス)が追加されるか、あるいは一次インターネット接続が飽和である場合に(図11および図12に示されているように)、より高価なネットワークのみを含めるために結合が使用される。別の使用は、トラフィックを異なる属性を有する他のデータ接続にオフロードするのを可能にすることによって、衛星などの高コスト(多くの場合、埋没原価)の高信頼性データ接続の使用を最大化する手段を提供することである(図9および図10)。
いくつかの実施形態では、本システムは、複数のネットワーク接続を通してデータフローをルーティングすることのために構成されたネットワークゲートウェイである。
図1は、それぞれがバッファマネージャ150と、動作エンジン152と、接続制御装置154と、フロー分類エンジン156(フロー識別および分類に関与する)と、スケジューラ158と、シーケンサ160と、ネットワーク特性監視ユニット161とを備え、かつ各ゲートウェイが特定のエンドポイント102、110に接続された状態でN個のデータ接続106によって連結された2つのゲートウェイ104および108を有するシステムの概略を提供する。参照文字AおよびBは、2つのゲートウェイ104および108のそれぞれの構成要素を区別するために使用されている。
各ゲートウェイ104および108は、複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースを含むように構成されており、かつ複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、パケットのデータフローの少なくとも1つのパケットを解析してデータフローのためのデータフロークラスを特定することであって、そのデータフロークラスは、データフローの少なくとも1つのネットワークインタフェース要件を定めるかまたはそれ以外の方法でそれに関連づけられていることと、データフロークラスおよび時変ネットワーク伝送特性に基づいてデータフロー内のパケットを複数のネットワーク接続を通してルーティングすることとのために構成されたプロセッサを備える(例えば、設定されたハードウェア、ソフトウェアまたは組み込みファームウェアを備える)装置である。
バッファマネージャ150は、トラフィック(本システムを通過する個々のフローおよび複数の同時フローの組み合わせの両方)をより効率的に管理するように構成された本ゲートウェイ内のバッファを設定するように構成されている。いくつかの実施形態では、バッファマネージャは別個のプロセッサである。他の実施形態では、バッファマネージャは、数ある活動の中でもバッファ管理(150)を行うように構成されているプロセッサによって提供される計算ユニットである。
動作エンジン152は、ユーザ/クライアント、宛先/サーバ、接続(例えば、レイテンシ、スループット、コスト、ジッター、信頼性)、フローの種類/要求(例えば、FTP対HTTP対ストリーミングビデオ)ごとのいずれかで、受信された入力データセット(例えば、フィードバック情報、ネットワーク輻輳情報、伝送特性)に基づく1つ以上の決定論的方法および/または論理演算を適用して、結合された接続に適用される制約について本システムに伝えるように構成されている。例えば動作エンジン152は、一例ではコストに基づいて特定の種類のフローを特定の接続またはデータ接続のセットに限定するように構成されていてもよいが、異なるユーザまたはフローの種類の場合、信頼性および低レイテンシがより重要になり得る。例えば、公知の情報の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.レイテンシ要求なし、ジッター要求なし、順番どおりであるのが好ましいパケット、帯域幅要求なし、持続的大容量データ転送(例えば、ファイル/システムのバックアップ)など
である。
1.低レイテンシ、低~中程度のジッター、乱れた順番であってもよいパケット、高帯域幅(ライブHDビデオ放送)、
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のための例と共に以下でさらに説明されており、データの体積を、フローをある種類(低レイテンシ、低帯域幅)から別の種類(レイテンシセンシティブでない、高帯域幅)に再分類することができるインジケータとして使用することができる場合に、データの体積は関連する。
他の分類寸法および分類が可能であり、上記は分類例として提供されている。異なる寸法または分類および/または上記のその中での組み合わせを作成してもよい。例えばメディア放送において、本システムは、クリップ(例えば、GPS情報、タイミング情報、ラベル)に関連づけられたビデオデータおよびメタデータまたはビデオストリームに関連するFECデータを分類するように構成されていてもよい。
フロー分類を利用して、本システムが行うのを防止するように構成されている伝送(例えば、場合によってはピアツーピアファイル共有、または著作権下にあることが知られているマテリアル)、または段階的サービスを提供するという文脈において本システムが好むように構成されていてもよいトラフィック(例えば、別のものも特定のユーザまたはソフトウェアプログラムを好む)を除去および/または濾過して取り除くことができる。
例えばインターネットバックアップ利用のシナリオにおいて、結合されたバックアップが利用能において限られている場合があるとしても、本システムは、サポート組織へ/からのVoIPコールが当該組織内のコールよりも高いレベルのサービスを受けるように、そのように構成されていてもよい(ここでは、本システムは制約下にある場合に、エンドポイントがいくつかのコールの音声品質を他のコールよりも低下させたり、帯域幅制約がある場合に特定のコールをまとめて低下させたりする命令を生成することができる)。
スケジューラ160は、どのパケットがどの接続106に送信されるべきかに関する決定を行うように構成されている。スケジューラ160は改良されたQoSエンジンとみなしてもよい。スケジューラ160は、いくつかの実施形態では、コンパレータ回路またはFPGAなどの1つ以上のプロセッサまたは独立型チップまたは構成された回路を用いて実装されている。スケジューラ160は、決定を行うために確認される一連の論理ゲートを備えていてもよい。
典型的なQoSエンジンは単一の接続を管理するものであり、それはフロー識別および分類を行うように構成されていてもよいが、最終的な結果は、QoSエンジンがパケットを再順序付けした後それらを1つの接続上で送信するというものである。
対照的に、スケジューラ160は、フロー識別、分類およびパケット順序付けを行うように構成されているが、いくつかの実施形態のスケジューラ160は、データフローに改良された伝送特性を与え、かつ/またはユーザ/管理者によってフローのために設定されている(または各種ルールに提示されている)ポリシーを満たすために、どの接続にパケットを送信するかについての決定を行うようにさらに構成されている。スケジューラ160は、制御信号のセットをネットワークインタフェースに伝送してそれらのスイッチをオンまたはオフにするか、あるいはどれを使用してデータをルーティングすべきかを示すことによって、例えばネットワークインタフェース動作特性を修正してもよい。制御信号は、パケットのタイミング、特定の種類のトラフィックのためのネットワークインタフェースの予約などの、所望のルーティングの固有の特性を示す命令セットであってもよい。
例えば、以下の特性を有する2つの接続が検討される。
1)接続1:1msの往復時間(RTT)、0.5Mbpsの推定帯域幅、および
2)接続2:30msのRTT、10Mbpsの推定帯域幅。
1)接続1:1msの往復時間(RTT)、0.5Mbpsの推定帯域幅、および
2)接続2:30msのRTT、10Mbpsの推定帯域幅。
スケジューラ160は、もっぱらDNSトラフィック(小さいパケット、低レイテンシ)のために接続1を予約することを試みることができる。この例では、接続1の容量に達する非常に多くのDNSトラフィックが存在してもよく、スケジューラ160はトラフィックを接続2までオーバーフローさせるように構成することができるが、スケジューラ160は選択的に他の決定または因子に基づいてそのようなことを行うことができる。例えば、スケジューラ160が公正な決定を提供するように構成されている場合、スケジューラ160は最初に、過去X秒以内にかなりの量のDNSトラフィックを既に送信したIPアドレスからのトラフィックをオーバーフローさせるように構成することができる。
スケジューラ160は、例えばハードウェアにおける1つ以上のプロセッサまたは同様の実装(例えばFPGA)と一緒に動作するプロセスまたは方法に基づいて決定を処理するように構成されていてもよい。これらの装置は動作エンジン152の制御下での動作のために構成されていてもよく、データストリームをデータパケットに分割し、次いでデータパケットをバッファ(バッファマネージャによって管理される)の中にルーティングし、バッファはデータ接続の特性を考慮にいれながらパケット配信を最適化しようとするルールに従ってデータパケットをデータ接続に送る。
主要基準は、いくつかの実施形態ではレイテンシおよび帯域幅に基づくものであるが、いくつかの実施形態では、パス最大伝送ユニット(PMTU)も利用されてもよい。例えば、1つの接続が他の接続よりも著しく小さい(例えば、1500バイトに対して500バイトの)PMTUを有する場合、その接続上で送信されるパケットが断片化される必要があるので、それはオーバーフローのための悪い候補として指定される(と共に、例えば回避されるか優先度が下げられてもよい)。
スケジューラ160は、いくつかの実施形態では、パケットを正しい順番で通して通信するように構成されている必要はなく、むしろ所望のQoS/QoEメトリクス(そのうちのいくつかはネットワーク制御装置によって定められてもよく、それ以外はユーザ/顧客によって定められてもよい)を満たすかまたは超えるために、パケットを多様な接続を通して通信することのために構成されている。パケットを乱れた順番で通信し得る場合は、シーケンサ162およびバッファマネージャを利用して受信されたパケットを再順序付けしてもよい。
パケットの順次バーストは、ネットワークインタフェースを通して伝送され、パケットの順次バースト内のパケットが受信ノードで受信された場合に記録されるタイムスタンプおよびパケットのサイズに基づいて、第1のネットワークインタフェースの帯域幅の推定値が生成される。次いで、第1のネットワークインタフェースの生成された帯域幅に基づきネットワーク接続のセットを通る順次パケットのデータフロー内のパケットをルーティングするために、その推定値を利用する。以下に記載するように、いくつかの実施形態では、バースト内の最初もしくは最後のパケットと合体されていないバースト内のパケットのタイムスタンプに基づいて帯域幅の推定値を生成して、下限帯域幅値を推定することができると共に上限帯域幅値を推定することができる(例えば、パケットの置換により)。送信されるパケットは、テストパケット、データパケット上のテストパケット「ピギーバッキング」またはハイブリッドパケットであってもよい。データパケットが「ピギーバッキング」のために使用される場合、いくつかの実施形態は、増加した冗長性についてそのようなデータパケットにフラグを設定することを含む(例えば、失われたパケットのため、特に帯域幅テスト目的のために使用されるパケットのために許容差を増大させるため)。
順次パケットは、シーケンサ162が消費のためにパケットを再構成することができるように、順番通りに、あるいはその順番からの許容される逸脱の範囲内で受信してもよい。いくつかの実施形態では、シーケンサ162は、信号を受信し、かつ再構成された信号である出力信号を生成する放送インフラの中に組み込むことができる物理的なハードウェア装置である。例えば物理的なハードウェア装置は、信号の受信および再構築のための第1段階として機能するラックマウント式のアプライアンスであってもよい。
シーケンサ162は、フローのために不必要なパケットの再要求または他のエラー訂正を減らすために、エンドポイントにおいて受信されたパケットを順序付けしてそれらを許容される順番でアプリケーションに伝送するように構成されている。その順番は、いくつかの実施形態では元の順番に従っている。他の実施形態では、その順番は、シーケンサ162がなおデータフローを再構築することができるような順番の許容限度内である。シーケンサ162は、例えば受信されたフローを滑らかにするためのバッファまたは他の機構を含んでいてもよく、いくつかの実施形態では、複数のネットワーク接続の伝送特性の監視および順次パケットのデータフローの受信における不均等分配に基づいて、肯定応答の送信およびパケットの格納を制御するように構成されている。
シーケンサ162は、例えばプロセッサ上に設けられているか、バッファから抽出された受信されたデータパケットからデータフローを再構築するように構成された動作エンジン152の制御下に設けられているハードウェア(例えば、フィールドプログラマブルゲートアレイ)に実装されていてもよい。
シーケンサ162は、フロー毎ベースで、各フローに許容されない複数の接続間のレイテンシの差を隠すように構成されている。
動作エンジン152は、他の構成要素(154を含む)によって提供される情報のアグリゲーターとして動作可能であり、シーケンサ162が所与のフローに対してどのように動作すべきかを示す1つ以上の制御信号によりシーケンサ162に指示を与える。
TCPなどのプロトコルのために構成されたシステムがパケットを受信するときは、本システムは一般に、パケットが順番通りに到着することを期待する(が要求しない)ように構成されている。但し本システムは、乱れた順番のパケットが到着することを予想するときに関して時間限界(通常は、何回かの複数回の往復時間すなわちRTT)を確立するように構成されている。また本システムは、発見的手法に基づく時間限界になるや否や失われたパケットを再送するように構成されていてもよい(例えば、3回のDUP ACKによってトリガーされる最初の再送)。
パケットが著しく異なるレイテンシを有する接続上でシーケンサ162に到着する場合、シーケンサ162(フロー毎ベースで)は、パケットを宛先に向かって前方に送信する前にそれらがおよそ同じ年齢(遅延)になるまでパケットをバッファするように構成されていてもよい。例えばフローが一致するレイテンシおよび低ジッターを要求する場合に、シーケンサ162はこれを行う。
シーケンサ162は、必ずしもデータパケットの信頼できる厳密に順番どおりの配信を提供する必要はなく、いくつかの実施形態では、プロトコル(例えば、UDPの上のTCPまたはアプリケーション)を使用する本システムが、パケットがネットワークによって失われていると早まって決定しないために、必要なものを提供するように構成されている。
いくつかの実施形態では、シーケンサ162は、パケットロスと共に各データ接続のレイテンシの変動(ジッター)を(動作エンジン152によって維持されるデータに基づいて)監視して、どのデータ接続がフローによって予想以上にパケットを遅延させる可能性があるかを接続信頼性に基づいて予測するように構成されている(エンドポイント102および110がそれらが失われているとみなし、かつそれらのエラー訂正ルーチンを呼び出すことを意味する)。
乱れた順番の状況の場合、シーケンサ162は例えば、より大きなレイテンシの変動を示す接続上でより大きなジッターバッファを利用してもよい。パケットの再送の場合、シーケンサ162は、「最良の」(最も信頼できる最も低いレイテンシ)接続を通して失われたパケットを即座に要求するように構成されていてもよい。
シナリオの一例では、帯域幅遅延積の推定は全体的に正確でなくてもよく、レイテンシスパイクが接続において経験される。その結果、パケットは中間のゲートウェイにおいて乱れた順番で受信される。
これらの実施形態では、シーケンサ162は、プロトコル(および/または関連するアプリケーション)が誤った順番のパケットに関してどのように行動することができるかに関して予測的決定を行い、かつ下流のシステムが、ネットワークが容量に達した(従ってその伝送速度を抑える)と誤ってみなし、かつ/または失われていないパケットの再送を不要に要求する可能性が低くなるように、パケットを再順序付けする命令を生成するように構成されていてもよい。
例えば、多くのTCP実装は、3回の連続した二重の肯定応答(DUP ACK)を、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の順番で既にバッファされていた場合、シーケンサ162は、この例では予測的決定がトリガーされないため(パケット3の位置決めを考慮して)、伝送前にそれらを再順序付けするのを邪魔しないように構成されていてもよい。
接続制御装置154は異なる接続パス106間で実際のルーティングを行うように構成されており、これは例えば、結合されたリンクへの接続106が物理的なゲートウェイ104、108上に存在している必要がないことを示すために提供されている(例えば物理的なゲートウェイは、他の場所にあってもよい(およびアンテナなどに関して異なる場所にあってもよい)物理的な送信/受信装置または衛星機器へのいくつかのリンク(イーサネット(登録商標)またはそれ以外)を有していてもよい)。従って、エンドポイントは論理的に接続されており、かつ様々な方法で物理的に分離されていてもよい。
一実施形態では、システム100はTCP加速法として知られている方法を提供するように構成されており、ここでは本ゲートウェイは、パケットを受信するとプレバッファを作成し、かつ受信エンドポイントが既に受信されたパケットを有するかのように肯定応答信号(例えばACKフラグ)を送信エンドポイントに提供し、実際のパケットがエンドポイントに配信される前に、送信エンドポイント102により多くのパケットをシステム100の中に送信させることができる。いくつかの実施形態では、プレバッファリングはTCP加速法のために使用される(得られるデータのバッファリングと組み合わせた日和見的肯定応答(ACKing))。
このプレバッファは、送信エンドポイント102への第1のリンクの前またはエンドポイント110への伝送路の中のどこか他の場所に存在することができる。このプレバッファのサイズはマルチパスネットワークからのフィードバックに応じて異なってもよく、これは、いくつかの実施形態では、帯域幅遅延積の推定または測定あるいは所定の論理演算のセットに基づいている(ここでは、特定のアプリケーションまたはユーザは、速度、レイテンシ、スループットなどの特定の特性を有するプレバッファを受信する)。
プレバッファは、例えば実装内の様々な位置に存在してもよく、例えばプレバッファは、ゲートウェイ104への入口点または110への伝送路(最終的な宛先の前)までのいずれかに存在してもよい。一実施形態では、一連のプレバッファが存在し、例えばデータはエンドポイント1からエンドポイント2まで流れるので、ゲートウェイAおよびゲートウェイBの両方の上にプレバッファが存在する。
プレバッファの中に受け入れられ、かつエンドポイント102に日和見的に肯定応答されたデータをエンドポイント110に確実に送信することはシステム100の責任となる。肯定応答は、エンドポイント110がデータを受信し、故にその正常なTCP機構を介する再送をもはや取り扱う必要がないことを元のエンドポイント102に伝える。
プレバッファリングおよび日和見的肯定応答は、接続106のロスおよび他の非理想的行動を取り扱うのに利用可能なシステム100が有する時間制限を取り除くので、有利である。TCP加速法を使用しない時間制限は、システム100の制御下にない値であるエンドポイント102によって計算されるTCP RTOに基づいている。この時間制限が超過された場合、エンドポイント102は、a)システム100が既にバッファリングしているかもしれないデータを再送し、かつb)そのcwndを減少させ、従ってスループットが低下する。
メモリ使用量に制限を加えるためにプレバッファのサイズを制限しなければならない場合があり、これはマルチパスゲートウェイ104および108間のフロー制御情報の通信を必要とする。例えば、ゲートウェイ108とエンドポイント110との通信リンクが全ての接続106の総スループットよりも低いスループットを有する場合、108でバッファされるデータの量は絶えず増加する。バッファされる量が限界を超えた場合、フロー制御メッセージが104に送信されて、エンドポイント102から送信されるデータを日和見的に肯定応答することを一時的に停止するようにそれに命令する。バッファされる量が最終的に限界未満まで低下した場合、フロー制御メッセージが104に送信されて日和見的に肯定応答することを再開するようにそれに指示を与える。限界は静的閾値であってもよく、あるいは、例えば全ての接続106の総BDPおよび本システムによって現在取り扱われているデータフローの総数などの因子を考慮しながら動的に計算される。フロー制御の開始/停止メッセージが送信される閾値は同じである必要はない(例えば、ヒステリシスが存在してもよい)。
同様に、マルチパスゲートウェイそれ自体の中にフロー制御信号情報が存在してもよい。例えば、接続106の総スループットがエンドポイント102とゲートウェイ104との間のスループットよりも小さい場合、104内のプレバッファは絶えず増加する。限界(先に記載したように計算してもよい)を超えた後、エンドポイント102から入って来るデータの日和見的肯定応答を一時的に停止し、次いでデータの量が適当な閾値未満に低下した場合に再開することを必要としてもよい。
先の例は、エンドポイント102から110に送信されるデータのためのTCP加速法について説明するものである。同じ説明が反対方向に送信されるデータに当てはまる。
別の実施形態では、バッファマネージャは、接続ネットワークの行動における可変性と、ネットワークに対する他の活動およびソース伝送の潜在的に「バースト性」である性質とを補償するために通信リンクごとの進行中の伝送に対して過剰バッファリングを提供するように構成されている。
過剰バッファリングとは、例えば出力側での接続のBDPよりも多くのパケットを入力側で意図的に受け入れることが取り扱い可能であるということを指してもよい。「過剰バッファリング」と「バッファリング」との違いは、バッファマネージャがフロー要求に基づき、かつ接続BDPがリアルタイムでどのように変わるかに基づいて異なる量をバッファすることができるという点である。
この過剰バッファリングにより、ゲートウェイ104にそうでない場合に対応する準備ができている量よりも多くの(例えば、それが「容易にこなせる」量よりも多くの)データを送信エンドポイント102から受け入れさせてバッファさせる。過剰バッファリングは、全体的に行うことができるか(例えば、本システムは、総スループットにおいて利用可能な本システムが推定するよりも多くを利用するように構成されている)、あるいは接続ごとに接続制御装置の中に移動させて管理することができるか、両方の組み合わせ(例えば、伝送ごとの複数のオーバーバッファ)で提供することができる。
例えば、システム100が所与のリンクのセットを通して20Mbpsを送信できるということのみを推定する場合であっても、システム100は当面は送信エンドポイント102からそれを超えて(例えば30Mbpsを)受け取り、恐らくネットワーク特性監視ユニット161よって提供されるネットワーク特性の統計学的かつ履歴的知識に基づきネットワーク条件が変わり得るという決定、または送信エンドポイント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%を超えて追加すべきではないという要求に関するルールが実装されていてもよい。この例では、このルールは、過剰バッファリングサイズが「ビットレート×ベースレイテンシ×1.5」であるということを示している。
一実施形態では、動作エンジン152がマルチパスゲートウェイ104、108に含まれていてもよい。別の実施形態では、動作エンジン152はクラウドに存在し、かつ1つ以上のゲートウェイ104、108に適用してもよい。一実施形態では、単一のマルチパスゲートウェイ104、108に接続する複数のエンドポイント102、110が存在してもよい。一実施形態では、エンドポイント102、110およびマルチパスゲートウェイ104、108は同じ装置に存在してもよい。
一実施形態では、接続制御装置154はマルチパスゲートウェイ104、108とは別個であってもよい(かつ1つ以上の接続装置(例えば、無線インタフェースまたは有線接続)に物理的に関連づけられていていてもよい)。別の実施形態では、接続制御装置は本ゲートウェイ上に存在していてもよいが、物理的な接続(例えばインタフェースまたは有線接続)は別個のユニット、1つの装置または複数の装置上に存在していてもよい。
エンドポイントは論理的に接続されている必要があるが、それらは接続106に依存しないように接続されていてもよい(例えば、マルチパスゲートウェイ104、108によって取り扱われる通信)。いくつかの実施形態では、所与のゲートウェイに利用可能な接続106のセットは動的であってもよい(例えば、特定の時間または特定のユーザにおいてのみ利用可能な特定のネットワーク)。
一実施形態では、エンドポイント102から入って来るトラフィックは、システム100からの動的フィードバックに基づいてシステム100によって制御可能であってもよい(例えば、本システムは、エンドポイントで始まるビデオ伝送のビットレートを変更するように構成されていてもよい)。別の実施形態では、エンドポイント102から入って来るトラフィックはシステム100によって制御可能でなくてもよい(例えば、エンドポイントから生じるウェブ要求)。
別の実施形態では、伝送路の中に2セット以上のマルチパスゲートウェイ104、108が存在してもよい(例えば図13)。例えば、いくつかの実装では、クラウド内のゲートウェイに接続する遠隔マルチパスゲートウェイによるTCP伝送が存在してもよく、次いでこの伝送はクラウドのエッジにある別のマルチパスゲートウェイに非マルチパス接続を提供し、次いで別のマルチパス遠隔ゲートウェイに伝送が行われる。
遠隔現場オペレータが大きな容量のデータを別の遠隔位置に伝送しなければならない場合がある陸軍使用の事例などの各種使用事例が可能であってもよい。オペレータのシステム100は、データをより広域のインターネットに提供するために複数のパスが利用される送信機構と共にセットアップされていてもよい。次いで、システム100はインターネットのエッジ上の他のどこかに伝送するために高容量のバックホールを使用し、次いでそこではそれが第2の遠隔エンドポイントに着くために別のマルチパス伝送を必要とする。
一実施形態では、ゲートウェイA104およびB108は、利用可能な接続パスのうちの1つを介して互いの間で制御情報を送信するように構成されていてもよい。
図2は、インターネットユーザが様々なネットワーク特性を有するトランスポートリンクを利用するゲートウェイの組み合わせを介してウェブに接続するシナリオを説明する。
図2は図1に関連しているが、クライアント202とサーバ204との異なる対話の例が示されている。本システムは究極的には両方向システムであってもよいが、伝送が単方向であるか最初は単方向であってもよい状況(例えば、データを提供するウェブページからデータを要求する)が存在してもよい。
クライアント202であってもよい装置は、例えばモノのインターネット(IoT)装置などの通信することができる各種装置であってもよい。他のエンドポイントはIoTハブなどのサーバであってもよい。図示されている接続206は、例えばLTEネットワーク、3Gネットワーク、衛星接続などを含んでもよい。他の接続の種類としては、特に有線ネットワーク、WiFiネットワーク(例えば、802.11規格)、ブルートゥース(登録商標)、マイクロ波接続、光接続、他の無線接続が挙げられる。これらのネットワークおよび/または接続のそれぞれの信頼性および接続性は、マルチパスフェージング、干渉、ノイズなどの様々な因子によって影響を受ける場合がある。
帯域幅、レイテンシ、ジッター、パケットロスなどは影響を受ける場合があり、いくつかの実施形態では、エンドポイント202、210および/またはマルチパスゲートウェイ204、208は移動中である場合があり、利用可能な接続206の数および種類さえ動的に利用可能になったり利用不可能になったりする場合がある。例えば、電気通信装備VANは、携帯電話通信可能範囲や衛星受信可能範囲などに出たり入ったりする場合がある。
図3は、図2のネットワークに基づく例に係る6つのパケットの順序付けを実証することによってシーケンサ160によって行われる方法のより詳細な例を示すために提供されている。図3の例では、パケットは単純なラウンドロビン式で送信される。その例は非限定的であり、他のパケット送信法が可能である。
特にレイテンシ特性に焦点を当てて、マルチパス送信機のスケジューラとマルチパス受信機のシーケンサとの間の以下の3種類の接続:
1.LTE:30Mbps、50msのレイテンシ、
2.3G:2Mbps、120msのレイテンシ、および
3.衛星:10Mbps、500msのレイテンシ
を検討する。
1.LTE:30Mbps、50msのレイテンシ、
2.3G:2Mbps、120msのレイテンシ、および
3.衛星:10Mbps、500msのレイテンシ
を検討する。
この例では、マルチパス送信機304を介して接続されたクライアント機械(C)302が、マルチパス受信機308を介して到達可能なサーバ(S)310にTCPトラフィックを送信しようと試みており、かつシステム300が先に記載したTCP加速法技術を用いていないと仮定する。
これらの接続のうち6つのIPパケットをラウンドロビンし、かつ「スマート」以外は何もしない単純なアルゴリズムを検討する。レイテンシの極端な差により、TCPストリームを受信するサーバ(S)は、以下の順番:
パケット1@t=50ms(LTEを介して送信される)
パケット4@t=50+ms(LTEを介して送信される)
パケット2@t=120ms(3Gを介して送信される)
パケット5@t=120+ms(3Gを介して送信される)
パケット3@t=500ms(衛星を介して送信される)
パケット6@t=500+ms(衛星を介して送信される)
で到達するパケットを観察する。
パケット1@t=50ms(LTEを介して送信される)
パケット4@t=50+ms(LTEを介して送信される)
パケット2@t=120ms(3Gを介して送信される)
パケット5@t=120+ms(3Gを介して送信される)
パケット3@t=500ms(衛星を介して送信される)
パケット6@t=500+ms(衛星を介して送信される)
で到達するパケットを観察する。
TCPは、パケットの主要な再順序付けおよびそれらの間の大きなレイテンシを取り扱うのに十分には設計されていない。当該サーバは、パケット1のために複数の二重のACKを送信し(当該サーバが失われたパケットをまだ待っているということをクライアントが知っていることを確認するために)、あらゆる/全てのパケット2/3/5/6を再送させるが、パケットは失われておらず、ただまだ伝送中であるのでこれは不必要である。特にこの理由のために、極めて様々な(または異なる)レイテンシの接続を結合しようと試みる場合に、多くの既存の解決法は非常に乏しいスループットを提供する。
ゲートウェイ104、108のシーケンサ162の順序付け機能は、当該サーバが、最終的にそれらが送信された順番でパケットを受信するように、パケットをバッファリングしてそれらを順番通りに送信することによる技術的解決法を提供する。得られる順番は、
パケット1@t=50ms(LTEを介して送信される)
パケット2@t=120ms(3Gを介して送信される)
パケット3@t=500ms(衛星を介して送信される)
パケット4@t=500+ms(LTEを介して送信され、かつシーケンサによってバッファされる)
パケット5@t=500+ms(3Gを介して送信され、かつシーケンサによってバッファされる)
パケット6@t=500+ms(衛星を介して送信される)
である。
パケット1@t=50ms(LTEを介して送信される)
パケット2@t=120ms(3Gを介して送信される)
パケット3@t=500ms(衛星を介して送信される)
パケット4@t=500+ms(LTEを介して送信され、かつシーケンサによってバッファされる)
パケット5@t=500+ms(3Gを介して送信され、かつシーケンサによってバッファされる)
パケット6@t=500+ms(衛星を介して送信される)
である。
バッファがどの程度の大きさであるかを決定する際に、スケジューラ160は当該決定が少なくとも部分的に帯域幅遅延積に基づくように構成されていてもよい。いくつかの実施形態では、バッファの長さは、例えばフロー要求、ジッター、接続セットの性能のための履歴データ(例えば、配信はそれらの接続に対してどの程度可変であったか、本システムがすぐに到着したパケットを再要求したこと(例えば、バッファは非常に小さい場合がある)、または最小のソーティングがシーケンサによって要求された回数(例えば、バッファは不必要に大きい場合がある)をどの程度頻繁に認識したか)に基づいてサイズ決めされていてもよい。
例えば、同様のレイテンシを有する多くの同様のネットワークが使用される場合、誤順序付けが生じる機会がより少なくなるため、スケジューラ160はより小さい受信/シーケンサバッファを提供してもよい。
他方で、本システムは、送信エンドポイントまたは当該接続のいずれかが「バースト性」である場合に、ネットワーク/パイプラインが常にフルであり続けることができることを保証するために、スケジューラ上のより大きなバッファを選択するように構成されていてもよい。バッファのサイズ決めは、どちら側であるかまたはフロー要求によって決まってもよい。エンドポイント2に対してより低いレイテンシが必要であり、かつ当該接続がそれ以外は良好/予測可能である場合、あるいはフローがパケット順序付けに対して厳しい要求を有しない場合に、バッファのサイズ決めはシーケンサ上ではより小さいバッファとなる傾向がある。
スケジューラ160上のバッファは、接続106がエンドポイント1によって一杯にされることを保証するように構成されていてもよく、かつシーケンサ162上のバッファはパケットの再要求の必要性を最小限に抑えるが、大き過ぎることによってパケットのエンドポイント2への配信に対して不必要な遅延を引き起こさないように構成されていてもよい。
いくつかの実施形態では、スケジューラ160およびシーケンサ162は、パケットの完全に保証された順番の信頼できる配信を提供するように構成されておらず、それどころかスケジューラ160およびシーケンサ162は、プロトコル(例えばTCP)またはアプリケーションがまだバッファ/転送されているパケットを失われたものとして誤って処理しないようにパケットを十分に再順序付けすることのみを必要とする。例えば、各種プロトコル/アプリケーションは複数のRTTをインジケータとして使用して、パケットが失われているか否かを決定してもよい。従ってスケジューラ160および/またはシーケンサ162は、パケットのバッファ時間における極度の可変性を減らすために動作可能であってもよい。
一実施形態では、本システムはスループットを最大化するために本システムの両側にバッファを設け、ここでは第1のバッファはトリガーによりコンテンツをネットワークに放出する。一実施形態では、この2つのバッファは、特定の全体的バッファ長さを維持するために一緒に調整することができる(ゲートウェイAのスケジューラ160およびゲートウェイBのシーケンサにおいて)。従って、当該バッファは一斉に動作して、送信機または受信機のいずれかの上での過度に長いバッファ(バッファブロート)を回避しながらも全体的バッファ長さを提供してスループットを向上させてもよい。別の実施形態では、当該バッファは互いに独立して動作してもよい。
図4は、スケジューラ160が「スマート」であるように構成されており、かつその決定においてレイテンシを利用するように構成されている場合の説明である。図4では、3つのネットワークが同じ帯域幅を有するが、異なるレイテンシを有する単純化された例が例示を目的として提供されている。
この例では、帯域幅は計算の単純性のために「1パケット」として定められているが、他の帯域幅が可能である。この仮定により、パケット1は@t=50msで到着し、パケット2は@t=100msで到着するという単純化された分析が可能になる。接続の帯域幅が1パケットよりも大きい場合、パケット2は、第1のパケットの後ろにパイプライン化されているので、t=51msで到着する(例えば1msの処理/パイプライン化遅延と仮定する)。別の例では、MbpsまたはKbpsを単位として当該分析を定めることが望まれる場合、その導出は全てのパケットが1500バイトであり、かつ接続が12Kbps(1500×8)の帯域幅を有するという仮定を含んでもよい。他の仮定が可能であり、例えば、
接続1-1パケットの帯域幅、レイテンシ50ms、
接続2-1パケットの帯域幅、レイテンシ120ms、および
接続3-1パケットの帯域幅、レイテンシ500ms
である。
接続1-1パケットの帯域幅、レイテンシ50ms、
接続2-1パケットの帯域幅、レイテンシ120ms、および
接続3-1パケットの帯域幅、レイテンシ500ms
である。
スマートスケジューラ160は、各種リンクの潜在的に時間で変化するレイテンシがリアルタイムで考慮されるようにパケットをルーティングするように構成されている。これにより、接続3を介して1パケットのみを送信することができるよりも速く全てのパケットに肯定応答することができるので(例えばRTTに基づいて)、スケジューラ160がパケットを接続1および2にのみ送信するという事例が生じる。
マルチパス受信機408上のシーケンサ162は、以下の順番:
パケット1@t=50ms(接続1を介して送信される)
パケット2@t=100ms(接続1を介して送信される)
パケット3@t=120ms(接続2を介して送信される)
パケット4@t=150ms(接続1を介して送信される)
パケット5@t=200ms(接続1を介して送信される)
パケット6@t=240ms(接続2を介して送信される)
でパケットを受信する。
パケット1@t=50ms(接続1を介して送信される)
パケット2@t=100ms(接続1を介して送信される)
パケット3@t=120ms(接続2を介して送信される)
パケット4@t=150ms(接続1を介して送信される)
パケット5@t=200ms(接続1を介して送信される)
パケット6@t=240ms(接続2を介して送信される)
でパケットを受信する。
ネットワーク上にドロップされたパケットや輻輳がないものと仮定すると、パケットは順番通りに到着し、かつシーケンサ162は再順序付けまたはバッファリングを必要とすることなく単にパケットを順番通りに通過させる。複数の接続が同様の特性を有する一実施形態では、本システムは、履歴的接続特性および信頼性に基づいてパケットを伝送させることを選択してもよい。
パケットが乱れた順番で受信されたり失われていたりする場合、シーケンサ162は、決定された最も信頼できる接続を通してパケットが再送されることを要求するように構成されていてもよい。マルチパス受信機408は例えば、フローの総レイテンシをそれが低い可変性を有するように維持することを試みるように構成されていてもよい。マルチパス受信機408がパケットを期待し、かつそれがまだ到着していない場合(パケットが失われていたり、当該接続がそれを予想外に再順序付けしたりしているため)、再要求を行うか、ただ継続するかどうかは(ロスを取り扱うためのプロトコル(TCP)またはアプリケーションに依存する)は、例えばフローおよびその要求に対して決定される影響によって決まってもよい。
図5は、帯域幅遅延積(BDP)の使用およびTCPパケットのマルチデータ接続ルーティングに関するスティッキー性を示すために提供されている。パケットを送信機504、接続506および受信機508を介して出力装置510に送信する入力装置502が示されていると共に、システム500が先に記載されているTCP加速技術を用いていないことが示されている。
図5の事例を検討すると、506に示されている3種類の接続のそれぞれは異なる帯域幅遅延積(BDP)を有する。図示されているBDPおよびレイテンシは単に例として提供されており、他の値が可能である。BDPは、例えば帯域幅に遅延(レイテンシ)を掛けて決定してもよい。
3Gリンク(例えば、接続1)は最も小さいBDP(2Mbps×120ms=約30KB)を有し、それがフルになったら(すなわち、約30KBの未肯定応答のパケットが送信されてパイプラインにおいてインフライト状態にある)、別のデータパケットをそのリンクを介して送信してはならず、さもなくばデータパケットはドロップおよび/またはバッファされ、これによりTCPフローにチャネル容量に達したと誤って認識させたり、当該接続のレイテンシを増加させたりする。
従って正しい手法は、代わりにそのデータパケットを異なるリンク(例えば、接続2または3)を通して送信することである。全てのリンクがそれらのフルBDPに達した場合にのみ、システム100はパケットをドロップする(あるいは、任意にそれを3つの接続のうちのいずれかに送信する)ように構成されるべきであり、それによりTCPフローは総チャネル容量に達したことを最終的に決定し、TCPフローに(例えば、送信ソース502)にその応答における総伝送速度を低下させる。
生じる技術的課題は、システム100が典型的には各接続の容量に関する情報を有しない点である。いくつかの実施形態では、帯域幅推定手法を適用して、改良されたルーティング決定を適用する(例えば、単純な帯域幅推定に対して期待されるスループットを確率的に向上させる)ことができるように、不完全な情報を考慮して帯域幅値を推定する。
推定がなければシステム100は、システム100がパケットロスおよび/またはレイテンシの増加を観察した場合にしか接続106がチャネル容量に達したときを決定することができないので、帯域幅の推定値は(正確性がほんの若干であるとしても)有用である。推定があればシステム100は、伝送速度が推定値に近づき始めた際にFECの割合を追加するなどの技術を使用するように有利に構成することができる。
受信機108がFECを用いて開始することが必要になると、送信機104はこれがチャネル容量に達したことを示していると決定してもよい。どんな回復不可能なロスも生じさせることなくチャネル容量が決定されるので、これはFECを使用しないシステムよりも改良されている。
いくつかの実施形態では、より正確な帯域幅推定手法は、システム100が重み付けされたラウンドロビンなどの改良された送信機構を呼び出すべきであると決定するのに有用であり得る。
但し、完璧な帯域幅推定アルゴリズムを用いる場合であっても、システム100は重み付けされたラウンドロビン機構を利用するのに最適なものでなくてもよい。フローがフルチャネル容量を必要としない場合、受信側でバッファリング/再順序付けが必要とならないように、そのパケットの全ては単一の接続に対して「スティッキー」な状態に維持されるべきである。すなわち、フローをデータ接続に割り当てたら、そのフローはその接続を使用し続けるべきである。フローの必要性がそれが割り当てられたデータ接続の容量を超えた場合にのみ、そのフローは別のデータ接続に「オーバーフロー」すべきである。
オーバーフロー接続の選択は、レイテンシ、スループット、信頼性、ジッター、コストなどあるいはこれらの因子の任意の組み合わせの面で様々な利点を提供するために、任意の数のパラメータを決定論理の中に組み込むことができる。例えば、LTE BDPは30Mbps×50ms=約187.5KBであり、かつ衛星リンクは10Mbps×500ms=約625KBである。衛星リンクが高コストであり、かつその目標が低レイテンシおよび低コストであれば、LTE接続は、衛星接続が使用される前にデータで「一杯」になるであろう。あるいは、衛星接続がLTE接続よりも著しく信頼でき、かつその目標が信頼性である場合、衛星接続は、LTE接続が利用される前にデータで「一杯」になるであろう。
また、同様の特性(レイテンシ、スループット、ジッターおよびパケットロス)を有する接続が互いにグループ化されるように、接続106は有利にはプールされてもよい。プーリングは接続制御装置内でより少ない決定を行うことを必要とすることを意味するので、これにより接続制御装置154によって行わなければならない接続管理が単純化される。接続特性は時間と共に変化するので、接続は必要に応じてプールをリアルタイムで結合および分離させて、信頼できるデータ通信を保証してもよい。全ての他の接続とは著しく異なる特性を有する任意の接続はプールされず、個々の接続として使用される。
プールされた接続は、矛盾する要求を有するフローの必要性を満たすのを可能にもする。例えば、全てが一貫して低レイテンシを有するが非常に様々なスループットを有する接続106のセットを検討する。このシナリオでは、最大で可能なスループットを達成するためにかなりの過剰バッファリングが必要とされ、これによりバッファブロートにおける著しい増加が生じ得る。一方が高スループットを必要とし、かつ他方が低レイテンシおよび低スループットを必要とする2つのフローが現在アクティブであれば、利用可能な接続106を、1つのプールがかなりの過剰バッファリングを利用し、かつ他方がそれを利用しない2つのプールに分割することにより、両方のフローはそれらの理想的な経験品質を達成することができる。
帯域幅推定手法の説明が図8A、図8B、図8C、図8Dおよび図8Eに提供されており、ここには、ネットワーク能力に関して分かっている情報を利用して、送信されるパケットの数およびパケットサイズに基づいて利用可能な帯域幅を推定する推定例が記載されている。実際の実装では非理想性を補償するために修正が適用され、これにより割り込み調停に関して合体などが生じることがある。各パケットに関連づけられたエラーレベルを決定して、帯域幅推定を向上させるのに利用してもよく、このエラーはビットレートによって決まってもよい(例えば、ビットレートが増加するにつれて、このエラーは取るに足らないものになり得る)。
当該技術分野でよく知られている輻輳制御技術(Reno、Vegas、CUBICおよび、BBRのようなより新しい手法)を用いて、接続のスループットおよびレイテンシ(ひいては接続の帯域幅遅延積すなわちBDP)も推定することができる。個々の(またはプールされた)接続の特性および/または入って来るデータフローの要求に応じて異なる輻輳制御手法を動的に使用すると有利であり得る。また単一の接続(または接続のプール)のために輻輳制御手法をパラメトリックに組み合わせることにより、接続(またはプールされた接続)および/または入って来るデータフローの必要性により良好に適合し得る手法が可能になるため、利点も得られる。
図6は、フロー要求の寸法(サイズおよびレイテンシに対する感度)を追加したものである。異なる入力装置602および603が存在してもよく、ここには図示されているように異なる種類のデータが提供されてもよい(602はFTP要求であり、603はSSHセッションである)。これらのフローは、ゲートウェイ604による分類を必要としてもよく、かつ有利にはフロー分類に基づく受信ゲートウェイ608への接続606を介し、かつFTPサーバ610および/または入力装置2に接続されたSSH接続612を介して提供されてもよい。
従って、フローの適切な識別および分類を用いて、データ接続(または接続のプール)へのデータパケットのさらに改良された割り当てを実装することができる。例えば、フローをDNSトラフィックとして特定するためにゲートウェイ604が動作可能である場合、ゲートウェイ604は、データストリームが小さく、かつレイテンシセンシティブであることを決定することができるため、ゲートウェイ604はこのデータストリームを最も低いレイテンシを有する接続または接続のプールに「スティッキー」な状態に維持する。逆に、ゲートウェイ604がデータストリームが大容量のFTP転送であることを特定した場合、ゲートウェイ604は、最初により高いレイテンシを有する接続へのルーティングの優先、および必要な場合および過剰な容量が存在する場合は、より低いレイテンシ接続または接続のプールへのオーバーフローのみを示すように構成されるべきである。
図示されている実施形態は最初の行にトラフィック識別子を含むが、他の解決法は、ディープパケットインスペクション、データストリームの種類を特定するためのデータパケットまたはデータストリームのラベリングを使用し、かつフロー分類エンジンによる適切な取り扱いを保証することができる。そのような手法はルーティングを支援してもよい(例えば、SSH:より低いレイテンシ接続を使用する、HTTP:より高いレイテンシ接続を使用する)。一実施形態では、いくつかのトラフィックの種類は常にスティッキーである(故にシーケンサ162は受信側で必要とされない)。
一実施形態では、フローの識別/分類を支援するために、送信機による(例えば、DSCP(Differentiated Services Code Point)を介する)パケットのマーク付けを使用して、接続へのパケットの割り当ておよびデータフローをさらに向上させることができる。
別の実施形態では、観察された行動に基づく発見的手法を用いてフローの性質を推定する(例えば、開始プログラムに戻る一方向の性質および高帯域幅を考慮して、ゲートウェイ604は、デフォルトによってこれがFTPフローであるとみなし、それに応じて接続割当てを調整するように構成することができる)。
別の実施形態では、当該分類はフローの行動に基づいて動的に変更することができる。例えば、SSHフローが最初に開始した場合、それは低帯域幅、レイテンシセンシティブなフローとして分類される場合がある。しかし、フローがデータを転送し続けるにつれて、それが特定の閾値の体積を通過すると、その分類はレイテンシセンシティブでない大容量のデータ転送(例えば、SCP/SFTP動作)に変更される場合がある。
図6では、フロー分類エンジンは、入力装置1(602)からのトラフィックの性質がFTPトラフィックであると決定(推定)するように構成されており、レイテンシセンシティブでない大きなフローのデータを予想して、システム100は最初にトラフィックを高いBDP衛星接続を通してルーティングし、必要に応じてLTE接続にオーバーフローさせる。
またフロー分類エンジン156は、入力装置2(603)からのフローがSSHセッションであると決定するように構成されていてもよく、次いでゲートウェイ604は、フローを取り扱うために低レイテンシ接続1(または低レイテンシ接続のプール)を選択するように構成されていてもよい。フロー分類エンジン156は、いくつかの実施形態では、ストリームの種類を特定するのを助けるために利用される入って来るデータストリームに関する統計学的情報を監視および/または受信する。
一実施形態では、システム100は、複数のフローの種類のその認識をリアルタイムで組み合わせて、接続の混合または使用される接続のプールの混合を動的に調整する。
図7に示されている一実施形態では、システム100は、送信マルチパスゲートウェイ704、受信マルチパスゲートウェイ708または両方のマルチパスゲートウェイにネットワーク特性監視ユニット701を取り入れている。各種因子をシステム100によって監視および/または推定して、データトラフィックが各種接続に割り当てられる方法を制御する。
これらの因子は、例えばパケットの伝送を向上させる方法を決定するために使用される接続信頼性の決定により確立されてもよい(例えば場合によっては、全体的信頼性はピーク速度よりも重要である)。
接続信頼性は、例えば特に帯域幅、レイテンシ、ジッター、パケットロス、可変性を含む1つ以上の因子の複合物として測定してもよい。
一例では、ネットワーク特性監視ユニット701は、スループット、パケットロス、ジッター、レイテンシ、パケット順序付けなどの生データを収集し、かつこの収集されたデータに関する統計量、典型的には限定されるものではないが、平均、分散、尖度、順序統計量、ランク統計量、事前に設定された/所定の閾値を超えるか下回る回数、および他の導出される統計量を計算する。
受信機704および送信機708の両方にネットワーク特性監視ユニットが存在する場合、これらのネットワーク特性監視ユニットは1つ以上の接続706を通して、それらの導出された統計量をリアルタイムまたは所定の間隔で共有するように構成されていてもよい(フィードバック702で示されている)。向上した信頼性のために、共有される導出された統計量を複数の接続(または接続のプール)を通して繰り返して信頼性を高めてもよい。
一実施形態では、受信側にあるネットワーク特性監視ユニット701は、どの位多くのビットが特定の接続706で送信される各パケットのための前方誤り訂正(FEC)によって訂正されるかの測定を取り入れている。この情報は、接続のためのエラー率に関する洞察を提供するために処理されてもよく、かつ導出される統計量の一部として提供される。
図8A、図8B、図8C、図8Dおよび図8Eは、いくつかの実施形態に係る帯域幅推定方法の例示である。帯域幅推定は、実際のボトルネック帯域幅のいずれかに近い速度で伝送させることなく、送信機と受信機との間のボトルネック帯域幅(帯域幅の制約)についての適度に正確な推定値を得るために提供される。
推定帯域幅は、所与のデータ接続のための全体的スコアまたは適合レベル(例えば、ネットワーク「適合度(goodness)」)を決定するために他の因子と共に使用される。本システムは、各種データ接続へのパケットの伝送に重み付けするために、利用可能なデータ接続(例えばネットワーク)の全ての期待される帯域幅の決定のために構成されていてもよい。
図8Aを参照すると、図表800に示されているように、提供されている例は、送信機802からのそれぞれ1400バイトの8つのパケットの伝送バーストを含む。ネットワークの理想的なモデルでは、ボトルネックリンクは、各パケット間の等しい遅延を効率的に挿入することができる正にその速度でこれらの8つのパケットを伝送する。この例では、ネットワークは25Mbpsで伝送することができるので、それは448マイクロ秒の遅延を各パケット間に挿入する。
受信機804では、パケットが受信され、かつタイムスタンプが正確に448マイクロ秒間隔で記録される。帯域幅推定は、全てのパケットを転送するのに必要な時間で割ったパケットサイズの合計(第1のパケットを除外する)に基づいている。第1のパケットのサイズはネットワークで費やされる時間が分からないため除外される。但し、それが受信された時間は、第2のパケットがボトルネックリンクからのその送信を開始する時間を示す。
図8Bに示すように実際には、送信機、受信機および中間ルーティングシステムは、他のトラフィックとの競争、処理時間の可変性、割り込み調停などのネットワークインタフェースカード(NIC)の最適化などにより、帯域幅の推定値にエラーを導入する可能性がある。例えば、各種統計学的方法(例えば、平均値、中央値など)の使用によりエラーの補償を行ってもよい。エラーの補償により本システムの効率およびスループットを高めてもよく、いくつかの実施形態では、ルーティングの特性の適応修正が行われてもよい。
エラー補償のための別の技術は、一番最近の帯域幅の推定値に応じて各バースト内のパケットの数を適応的に変化させることである。一般に、バーストのヘッドおよびテールにおいてパケット間到着時間に導入されるエラーのみが帯域幅の推定値計算に影響を与えるので、バーストが長くなるほど推定値がより正確になる。バーストが長くなるほど、総バースト持続期間と比較してヘッドおよびテールのエラーがさらに取るに足らないものになる。但し、ネットワークが低帯域幅を有する場合、長いバーストは実用的なものになり得ない。
図8A、図8B、図8C、図8Dおよび図8Eの例を分かりやすくするために、バーストは8つの等しいサイズのパケットを含むが、バーストごとのパケットの数およびバースト内の各パケットのサイズは固定されている必要はない。帯域幅の推定値の計算は、パケットの全体サイズおよびバーストの全持続期間を知ることのみを必要とする。但し、過度に小さいパケットおよび/または短いバーストは、バーストのヘッドおよびテールに導入されるエラーを拡大させる可能性がある。
いくつかの実施形態では、バースト内のパケットは真のデータも含むことができる(伝送されるデータの上に帯域幅推定アルゴリズムのために必要なメタデータを本質的にピギーバッキングする)。このメタデータのために第1のパケット(これは廃棄される)を使用してもよい。信頼性の向上のために、バースト内のその後のパケットは、このメタデータを繰り返してもよい。
ピギーバッキングが可能でない場合、または伝送するのに不十分な真のデータが存在する場合、このバーストは「ダミー」データと共に伝送されてもよいが、バーストが実際のデータ伝送を可能な限り僅かにだけ干渉するように、バースト長さをさらにより短くしてもよい。
NIC割り込みの取り扱いに関する技術などの、いくつかの種類のエラーを部分的に補償するための技術を使用してもよい。
図8Cは、いくつかの実施形態に係る、NIC割り込みが著しい遅延に関して対処されるものとしてモデル化されている受信機についてのタイミング例を示す。図8Cに示されている方法は、NIC割り込みの結果として生じるレイテンシおよびパケットバーストを補正するために利用される。
この例には、割り込みレイテンシを補正するための決定が示されており、これは単純なボトルネック帯域幅の推定とは対照的である。これらの割り込み遅延は、例えば受信されたパケットにボトルネックを生じさせる送信機と受信機とのネットワークリンクにより生じ得、その結果、均等に離間されている図8Aの例とは対照的にバーストとしてパケットが受信される。
パケットが受信された場合に割り込みが発生するが、著しい遅延の後(この例では500マイクロ秒)まで実行されない。この遅延の間にハンドラがやっと実行されると、それが全てのパケット(割り込みをトリガーした第1のパケット+遅延の間に到着した任意のパケット)を収集してそれらを同時にアプリケーションに配信するように、より多くのパケットが到着することができる。
グループ内の全てのパケットが同じ受信時間でスタンプされている状態でバースト内のいくつかのパケットがグループに合体されているので、エラーがこのモデルに導入されている。合体されているパケットがバーストのヘッドおよびテールから「トリミングされている」場合に(それらが帯域幅の推定値の計算から除外されるということを意味する)、得られるパケットの分散パターンは非遅延割り込みの場合と同一であるという観察により、このエラーを補正することができる。唯一の違いは、バーストの事実上の持続期間がトリミングによりさらに短くなっているという点と、パケット受信時間のそれぞれが割り込み遅延によって同等に時間でシフトされているという点である。
バーストのヘッドからのトリミングは、単一のパケットのみを含む第1のグループを見つけることを必要とする。テールからのトリミングは、バーストの最後のグループ内の最初のパケット以外の全てを無視することのみを必要とする。
従って、いくつかの実施形態では、ネットワーク特性監視ユニット701は、パケット受信特性を追跡する(例えば、ボトルネック帯域幅の推定値を決定することによる)。図8Cに示すように、いくつかの実施形態のネットワーク特性監視ユニット701は、例えば合体されたパケットをトリミングし、かつ時間シフトを組み込むことによって割り込みレイテンシをさらに補正するように構成されている。
図8Dは、2つ以上のパケットを含む全てのグループにより、バーストのヘッドからのトリミングが可能でない場合に、割り込みレイテンシを補償するために使用することができる技術を示す。
この技術を例えばネットワーク特性監視ユニット701によって実施して、ボトルネックリンクにおいて生じる割り込みレイテンシを補正してもよい。従って、ネットワーク特性監視ユニット701は、バーストのヘッドからトリミングすることができるようにするための要求を含まない割り込みレイテンシに適応することができる。
ネットワーク特性監視ユニット701は、パケットの受信時間がボトルネックリンクからのその後のパケットの送信時間に等しい(すなわち、t(N-1)受信==tN送信)というボトルネックリンクの理想化モデルを適用するように構成されている。この例から分かるように、この置換(この場合、t2送信からt1受信に)を行った後に、バーストのヘッドをトリミングしない場合であっても推定値を計算することができることは明らかである。
図8Eは、NICが割り込み調停技術を用いてネットワーク特性監視ユニット701によってモデル化されている受信機を示し、これは、割り込みハンドラが固定されたタイマー上で(この例では1000マイクロ秒ごとに)起動することを意味し得る。
ハンドラの最後の実行以降に受信されたあらゆるパケットが収集されてアプリケーションに配信される。
パケットの実際の受信時間はもはやアプリケーションには見えないので、これによりエラーが推定値に導入され、推定値は割り込みが発生する時間に基づく。
割り込み調停間隔が分かっていれば(例えば、それはシステム定数であるか、恐らくパケットのグループがアプリケーションに到着する頻度に基づいてリアルタイムで測定されているので)、帯域幅の推定値のために上限値および下限値を計算することができる。従って、いくつかの実施形態では、ネットワーク特性監視ユニット701は、追跡されるデータ値のコーパスから得られるような最新の推定される割り込み調停間隔を表すデータ構造を維持するように構成されており、このデータ構造は帯域幅の推定値の上限値および下限値を含む割り込み間隔を推定するために利用される。
上限値は、第2の最後の割り込みの直後にバースト内の最後のグループが実際に受信されたと仮定して計算する。下限値は最後の割り込みの直前に最後のグループが受信されたと仮定して計算する。
一実施形態では、下限値はFECが生成されて当該接続上で伝送され始める閾値である。
いくつかのシステム上で、割り込み調停にも関わらず、各パケットの実際の受信時間は、NICまたはオペレーティングシステムカーネルによってアプリケーションに利用可能にすることができる。これらのシステム上で、割り込み合体によるエラーの明示的補償は必要とされない。
ネットワーク特性監視ユニット701は、いくつかの実施形態では、再構築のためにパケット受信特性を決定する際に下限値および上限値を利用するように構成されている。
図9は、ゲートウェイA902とゲートウェイB908との間の衛星オフロードの単純な例(単一の入力)を示すように構成された図表900である。破線は構成要素間の論理接続を表し、物理接続は結合されたリンクを通るフローを表す。
トラフィックマネージャ904が制御することができる(ネットワーク上にいる人および優先帯域幅を得る人などを制御することができる、ネットワークパラメータなどを調整することができる)1つのネットワーク(例えば、衛星またはマイクロ波)、およびトラフィックマネージャ904が制御しない他のネットワーク(例えば、第三者セルラーネットワーク)が存在する例を検討する。被制御ネットワークが、トラフィックの一部を他のネットワークにオフロードすることを意味するとしても、それがトラフィックで「一杯」になる(コストを減らすか収入を最大化するために)のを確実にするためにそれを有利にさせる特定の特性(例えば、既に支払い済みであるので帯域幅が固定された「チャンク」として月単位で購入される)を有し得るということをさらに検討する。
例はビデオの送信であり、ここではセルラーネットワークによって保証することも場合によっては提供するさえもできない特定のレベルの伝送信頼性を配信することが望まれる。この場合、目標レベルの信頼性を保証することが必要とされるので、衛星ネットワークを通したビデオと同じ位多くを送信することが望ましい場合がある。また、衛星接続がフル容量でなければ(1つまたは複数のゲートウェイが同時に送信すると仮定する)、さらなるセルラーデータを使用する増分コストを減らすために可能な限り多くの衛星接続を使用することも有利であり得る。FEC情報またはメタデータまたはビデオストリームの実際の部分などのビデオと組み合わせた他のデータも、組み合わせられた接続を通して送信することができることに留意されたい。別の実施形態では、良好なセルラー帯域幅を有するゲートウェイがより少ない衛星帯域幅を使用するように指示されるようなネットワークブレンダ/トラフィックマネージャ904の制御下で、データを衛星からセルラーにオフロードすることが有利であり得る。
ネットワークブレンダ/トラフィックマネージャ904は、ネットワークの最適な組み合わせを決定するように構成されている(いくつかの実施形態では、1つ以上のネットワークが制御され、そのような場合にはネットワークブレンダ/トラフィックマネージャ904は、全てのネットワークに対する監視を提供し、かつスループット、信頼性、パケットロスなどのリアルタイム測定に基づいてルーティングするので、なお有用性がある)。一実施形態では、1つ以上の利用可能なネットワーク接続は「制御」されており(上記のとおり)、かつネットワークブレンダ/トラフィックマネージャ904は、本ゲートウェイからリアルタイム情報を受信し、かつネットワーク全体がネットワークブレンダ/トラフィックマネージャ904によって管理されるように、本ゲートウェイ(「エッジノード」)によって使用される帯域幅を制御するように構成されている。
一実施形態では、被制御ネットワーク管理システム(CNMS)906は、特定の条件下で(例えば、ユーザまたはトラフィックの種類、コストに基づく優先順位、信頼性などに関して)特定のトラフィックの許可を決定するための論理演算のセット(例えば、静的論理演算、動的論理演算)を有していてもよい。論理演算のセットは、各種データ記憶装置に提供され、かつ本ゲートウェイ、ソース/エンドポイントまたはクラウドに格納されているものに基づいていてもよい。
いくつかの実施形態では、論理演算のセットがトラフィックマネージャ904にも格納されており、トラフィックマネージャ904は、被制御ネットワーク管理システム906からの論理演算を、伝送全体に適用する他の論理演算と組み合わせて利用してもよい(例えば、ユーザは制御されている衛星のために多くを支払わなくてもよく、かつ意図的に制御されている衛星から押し出される場合もあるが、伝送全体のために支払ってもよく、従ってより高コスト/信頼性の非被制御ネットワークの選択または割当てに関して優遇措置が存在し得るように、システム100のデータ接続の残りについて優先順位を受信する)。
一実施形態では、ネットワークブレンダ/トラフィックマネージャ904はCNMS906と対話して、ネットワークブレンダ/トラフィックマネージャ904に被制御ネットワークおよびネットワークブレンダ/トラフィックマネージャ904が管理することができる任意の他の伝送の両方をより良好に利用させることができるようにシステム100を構成することができるような一般的なネットワーク条件に関して、本システム、マルチパスゲートウェイ902またはマルチパスゲートウェイに接続された装置に知らせてもよい。
例えば複数の接続が利用可能であってもよく、接続のそれぞれに影響を与えるネットワーク条件は時間と共に変わってもよい。例えば、輻輳としてロスおよびノイズが接続のそれぞれによって経験され、これらの接続は有利には、例えばそれらの接続特性に基づく使用または機能に割り当てられてもよい。その機能の接続および割当てのそのような「結合」は出願人の米国特許第9,357,427号に記載されており、この特許は参照により組み込まれる。
図10は、複数の被制御および非被制御ネットワークに接続された複数のゲートウェイが存在する混合の例を提供する図表1000である。
破線は構成要素間の論理接続を表し、かつ物理接続は結合されたリンクを通るフローを表す。
N個のマルチパスゲートウェイ(例えば、1002、1003)が存在してもよく、それぞれが、複数のエンドポイントから複数のゲートウェイを通るフローが被制御ネットワーク上のリソースのためのコンテンション(1004および1006の制御下)、これらのゲートウェイの所有者によって購入されるサービスレベル、これらのゲートウェイに取り付けられた非被制御ネットワーク上の接続性の品質および利用能、これらのゲートウェイを通るトラフィックを生成するフローおよびアプリケーションの要求などの因子を考慮して最良の経験品質で提供されるように、ネットワークブレンダ/トラフィックマネージャ1004およびCNMS1006に関して一斉に作動する。伝送は最終的にマルチパスゲートウェイAA~NN(例えば、1008、1010)に提供されてもよい。これらのゲートウェイは、ネットワーク上の各ゲートウェイのためのサービスの公知かつ制御された品質を有する結合された機能性を与える。この文脈では、サービスの品質は、ネットワークブレンダ/トラフィックマネージャ1004およびCNMS1006によって提供される帯域幅のスマート管理による特定のアプリケーションまたはアプリケーションのクラスのための帯域幅の割当てを意味する。
これらのゲートウェイは、異なるレベルの接続信頼性で販売(または保証)されていてもよい。ゲートウェイに高信頼性が保証され(またはそれが高信頼性を動的に要求し)、かつそれが高信頼性を受信していない場合、ネットワークブレンダ/トラフィックマネージャ1004は、別のゲートウェイからより信頼できる(例えば衛星)帯域幅をプロビジョニング(例えば、「スチール」)して、この増加した信頼性をより高い信頼性を要求した(またはそれが保証された)ゲートウェイに与えるように構成されていてもよい。
ネットワークブレンダ/トラフィックマネージャ1004は、複数のゲートウェイからの被制御ネットワークを介するトラフィックの割当てを管理し、ネットワーク特性のリアルタイム測定(本ゲートウェイによって提供される)および設定された静的もしくは動的論理演算(サービスルールの品質)に基づいて伝送のセットを最適化する。
一実施形態では、ネットワークブレンダ/トラフィックマネージャ1004は、特定のユーザ/組織のトラフィックの管理に特化していてもよい。別の実施形態では、ネットワークブレンダ/トラフィックマネージャ1004は、多種多様なユーザにサービスを提供するように構成されていてもよい。複数のネットワークブレンダ/トラフィックマネージャ1004が存在し得る場合、そのリソースは必要に応じて互いに通信し、かつ必要に応じて提供されてもよく、ここでは、リソースは必要に応じてプロビジョニングされる/プロビジョニング解除される(「スピンアップまたはスピンダウン」される)。ネットワークブレンダ/トラフィックマネージャ1004および被制御ネットワーク管理システム1006は、いくつかの実施形態では、分散されたネットワークリソースの形態で提供されていてもよい(例えば、クラウド構成では「クラウド内で」実行されてもよい)。
被制御ネットワークを通した新しい伝送が生じた場合に被制御ネットワークをどのように利用するかについて取り組むために、動的論理演算が提供されてもよい(例えば、任意の特定の伝送に与えられる優先順位は進行中の他の伝送によって決まってもよい)。
図11は、結合されていないディザスタリカバリー/ロードバランシング用途のために構成された1対1のシナリオを例解するために提供されている図表1100である。この状況では、個々のフローはどんな結合も有さずに特定の接続にスティッキーなままであってもよく、ここでは、当該バッファは受信側で必要とされないため、第2のゲートウェイは存在しない。フローの接続への割り当てのためのアルゴリズムは、フロー要求、接続品質/信頼性、伝送コスト、本ゲートウェイ上での計算限界などの因子を考慮に入れる静的もしくは動的ルールに基づいていてもよい。
一実施形態では、ゲートウェイ1102は必要に応じて(例えば、スループットまたはトラフィックの種類に応じて)、通信の2つのエンドポイント間に個々のソケットを結合するのではなくセットアップする接続リンクを追加または除去するように構成されている。
いくつかの実施形態では、接続は結合されていてもよいがデータを全く伝送せず、そのような実装はフェイルオーバーシナリオにおいて技術的利点を提供することができ、このシナリオでは接続が作動中であることを知っている必要があってもよく、接続をアクティブにすることにより、本システムは接続を定期的にテストして動作を確認し、かつ/またはその必要性が生じた場合には新しい接続を通してデータストリーム(またはフロー)を移動させることができる。
一実施形態では、ディザスタリカバリーのシナリオに直面しているサイトからの特定の種類のトラフィックは、コストを減らし、セキュリティを高め、レイテンシ、ジッターまたはそのような因子の任意の組み合わせなどを最小限に抑えるために、特定のバックアップリンク(またはリンクのセット)を介してルーティングされるように構成されていてもよい。
例えば、受信機/第2のゲートウェイを介してルーティングすることを必要としないサービスツール(または適応ロードバランサー)としてのディザスタリカバリーのための本システムの使用が存在してもよく、ここでは上記解決法の実施形態を利用して、よりロバストな接続性を提供してもよい。
図12は、結合されたディザスタリカバリー/ロードバランシング用途のサンプルを示すために提供されている図表1200であり、ここでは、トラフィックはいくつかの実施形態に従って結合され、かつ第2のゲートウェイ1204を介してルーティングされる。
図12に示すように、一実施形態では、大きな組織(またはセキュリティを必要とする組織)は、(比較的)閉鎖されたシステムにおいて2つの専用のゲートウェイ1202および1204を有し得る。別の実施形態では、顧客には単に「クラウド内の」公開ゲートウェイ1204が割り当てられていてもよい。図12の実装は、段階的ゲートウェイの使用によりインターネットからの潜在的に悪意のある攻撃からネットワークを分離し、かつ入って来て出て行くデータストリーム(またはフロー)のためのサービスの品質を含むセキュリティポリシーおよびプロトコルを適用するための協調的部分を提供するので、高いセキュリティを提供するように機能する。
図13は、2つ以上のエンドポイント1302および1310を接続する一連のマルチパスゲートウェイ1304、1306および1308を示す図表1300である。図13は、エンドポイント1(1302)の現場オペレータが伝送を行うために複数のパスを有するという利点を必要とするシナリオ(例えば、遠隔位置にいる兵士は状況認識情報を本部に提供するビデオおよび他のデータを送信する)を示す。これを達成するためにマルチパスゲートウェイの組み合わせ(例えば、ゲートウェイ1304、1306および1308)が必要とされてもよい。例えばトランジットの第1のホップは、現場からのデータを近くの前進作戦基地に送るために複数のWiFiネットワークを使用することを必要としてもよい。次いで前進作戦基地においてゲートウェイは、異なるセットの通信リンク(例えば多くのセルラーネットワーク)を介して全国本部にデータを送信してもよく、次いでここでは別のゲートウェイは、データを全国本部に送るために1つ以上のファイバーリンクを使用し、次いでこれは異なる組み合わせのリンクを使用してデータを異なる現場位置に送り戻してもよい。
一実施形態では、データはトランジットに沿った1つ以上の停止部においてアプリケーションに利用可能である。別の実施形態では、データは、途中でアプリケーションによってアクセスされることなく端から端まで伝送される。
いくつかの実施形態では、ネットワークの重複プールを用いて複数のスタート/エンドポイントを管理することのために構成されているシステムが提供されてもよく、ここでは、インテリジェントエンジンは各種装置および各種ネットワークの活動の知識を使用して伝送のフローをより良好に管理する。そのような実装では、本システムは、データレジデンシー論理演算(例えば、論理ルール)に従って順序付けを行うかネットワーク使用量を管理するように構成されていてもよい。
図14は、境界ゲートウェイプロトコル(BGP)に基づくエッジルーターを含む典型的なトランジットおよび/またはピアリング構成を用いて複数のリンクを通してインターネットに接続された2つのサイトを示す図表1400である。この例では、サイトAは、サブネットAのためのBGP経路をその上流のピア/トランジットプロバイダに知らせ、サイトBはサブネットBのためのBGP経路を知らせる。
BGPは「粗い」ディスタンスベクタ型ルーティングプロトコルであり、これはパケットをルーティングすることを決定する方法における主要因子が、パケットが宛先サブネットに到着するために横切る自律システム(AS)の数に基づくことを意味する。それは各AS内の輻輳を考慮することもなければ、本来はマルチホーミングをサポートすることもない。
例えば、ネットワークパストランジットA1がサブネットBからサブネットAへのトラフィックのための最も短いパスとみなされた場合、サブネットAへの全てのインバウンドトラフィックは、たとえ輻輳されているとしても、トランジットA1を介して到着する。全ての他のリンク(トランジットA2、ピアA1、ピアA2など)は利用されない。
この限界に対処するための手法は、サブネットAをより小さいサブネットに仕切り、かつリンクのサブセットを通してそれらを選択的に宣伝することである。より小さいサブネットのそれぞれにおけるトラフィックパターンは全ての時間において所与のリンクの中で所望の分割を表さない可能性が高いので、これは最適以下である。より小さいサブネットはグローバルBGPテーブルサイズの増加にも寄与するが、一般的に言って、/24よりも小さいサブネットはグローバルBGPテーブルにおいて受け入れられない。
2つのサイト間のBGPルーティングとの比較がこの図では一例として使用されているが、これは要件ではない。この2つのサイトは単に、公に宣伝されているサブネットを有しない異なるプロバイダを介するマルチホームであってもよい。そのような状況では、2つのマルチパスゲートウェイ間の完全に接続されたグラフがなお確立され、その際この2つのサイト間のトラフィックは、任意の先に述べた基準(例えば、接続コスト、フロー要求、接続品質/信頼性など)に従って接続上でルーティングされる。
図15は、2つのマルチパスゲートウェイシステム100に接続された同じ2つのサイトを示す図表1500を含む。接続制御装置154は、トランジットA1を(トランジットB1、トランジットB2、ピアB1)の全てに、トランジットA2を(トランジットB1、トランジットB2、ピアB1)の全てに...のように接続する完全に接続されたグラフを形成している。
サブネットAおよびB上のホストおよびアプリケーションによって生成されるフローは、宣伝されているBGPルートに基づいてもはやルーティングされないが、代わりにトランジットおよび/またはピアリングネットワーク上のIPアドレスを介して直接通信する2つのマルチパスシステム104および108間のプロトコル内にカプセル化されている。
これにより、マルチパスシステムは任意の数の上記基準(例えば、各フローのレイテンシおよびスループット要求、検出される輻輳/コンテンション、ジッター、コスト、管理者ポリシーなど)に基づいてパケットをルーティングすることができる。
いくつかの実施形態では、本明細書に記載されているシステムおよび/または方法の1つ以上の態様は、各伝送のための全てのレイテンシおよびパケットロス制約を満たしながらも、複数のリンクを通る伝送の総フローのスループットを最大化することを求めることができる。
場合によっては、リンク上の過剰なバッファリングによって生じるレイテンシであるバッファブロートを管理することによってこれらの問題のいくつかに対処してもよい。バッファブロートによりパケット遅延の変動(ジッター)やレイテンシの増加が生じる可能性がある。
接続が過負荷された場合、過負荷された接続上でレイテンシが増加し、これにより帯域幅遅延積(BDP)が増加するが、スループットの対応する増加は生じない。
いくつかの実施形態では、バッファブロートの管理は、様々な接続型のBDPを反映するバッファサイズの選択を必要とする場合がある。これは以下:
のように表すことができ、式中、「i」は接続の数であり、「ki」は本ゲートウェイ上でバッファリングを管理するために使用される定数であり(以下に概説されている)、
であり、式中、RtPropi(t)は接続のベース伝搬遅延である。
スループットi(t)およびRtPropi(t)が時間と共に変化しないか非常にゆっくりと変化する単純な接続では、レイテンシ制約を満たしながらも総スループットを最大にすることは、
・全てのRtPropi(t)が<=低レイテンシフローのレイテンシ要求である接続のサブセットが存在し、かつ
・サブセットの少なくとも1つを通る[ki×bdpi(t)]の合計が>=低レイテンシフローによって生成されるデータの体積である、
という条件である限り解決することができる。
・全てのRtPropi(t)が<=低レイテンシフローのレイテンシ要求である接続のサブセットが存在し、かつ
・サブセットの少なくとも1つを通る[ki×bdpi(t)]の合計が>=低レイテンシフローによって生成されるデータの体積である、
という条件である限り解決することができる。
この基準を満たすサブセットが存在する場合、全ての残りの接続を通る[ki×bdpi(t)]の合計(および低レイテンシフローによって完全に消費されない接続の部分的BDPを含む)は、レイテンシセンシティブでないフローのために使用することができる。
最大化問題は、スループットi(t)およびRtPropi(t)が急激に、かつ本システムがbdpi(t)の瞬時値に正確に従うことができないそのような大きな範囲の値にわたって変化する接続が存在する場合に明らかになる。これらの種類の接続のために、本システムはbdp_mini(t)およびbdp_maxi(t)(スループットiおよびRtPropiのmin/maxから測定される)を測定/観察するように構成することができる。
スループットi(t)およびRtPropi(t)が変化する事例の場合、観察されたスループットi(t)およびRtPropi(t)の分配に基づく統計学的手法を使用することができる。場合によっては、これは条件付き確率または反復的発見的手法に依存してもよい。機械学習または人工知能手法も用いてもよい。
本システムは、接続の最適な分割を決定する場合にレイテンシ制約を満たしながらも最大化問題に対処するように構成されている。これらの制約を満たす複数の接続サブセットが存在してもよい。
・低レイテンシサブセット
・RtProp_mini(t)が<=低レイテンシフローのレイテンシ要求である全ての接続を見つけ、かつ
・bdp_mini(t)の合計が>=低レイテンシフローによって生成されるデータの体積であるこれらの接続を通る全てのサブセットを見つける
・高レイテンシサブセット
・残りの接続(サブセットの中にない接続)上にある上で計算した各実行可能なサブセットの場合、bdp_maxi(t)を合計する。その目標はこの合計を最大化するサブセットを見つけることである
・低レイテンシサブセット
・RtProp_mini(t)が<=低レイテンシフローのレイテンシ要求である全ての接続を見つけ、かつ
・bdp_mini(t)の合計が>=低レイテンシフローによって生成されるデータの体積であるこれらの接続を通る全てのサブセットを見つける
・高レイテンシサブセット
・残りの接続(サブセットの中にない接続)上にある上で計算した各実行可能なサブセットの場合、bdp_maxi(t)を合計する。その目標はこの合計を最大化するサブセットを見つけることである
kiの決定
単純な事例では、kiは定数であり、故に接続のためのバッファサイズを接続のためのBDPのいくらかの割合として選択する。経験に基づいて、ki=1.2の値が実際に十分に機能することを見出した(例えば、本システムは所与のリンクのBDPの20%超をバッファするように構成されている)。
単純な事例では、kiは定数であり、故に接続のためのバッファサイズを接続のためのBDPのいくらかの割合として選択する。経験に基づいて、ki=1.2の値が実際に十分に機能することを見出した(例えば、本システムは所与のリンクのBDPの20%超をバッファするように構成されている)。
複雑な事例では、kiは、接続iを通して移動するフローの種類(およびそれらのフローの種類に関する任意の制約)、bdpi(t)の分散(kiをリアルタイムで調整するためにこれをリアルタイムで計算して使用してもよい)、および接続特性(レイテンシ、ジッター、スループット)の関数であり、ここでは、どの位のレイテンシがフローの種類のために必要であるか、およびどの位のスループットが必要とされるか(および、それらのフローの種類のためにどの組み合わせが最小で許容可能であるか)を決定し、これはkiがフローの種類、BDP分散および接続特性の関数であることを意味している。
WiFiおよびLTE接続を用いる場合、レイテンシの変動はかなり急激であり得、かつ数規模の大きさに及ぶ範囲をカバーすることができる(例えば、WiFiは<10msかつ>100msで移動することができる)。
選択されたバッファリングの量が<10msのレイテンシである(すなわち、小さいki)と仮定した場合、実際のレイテンシが>100msであるときはいつでもネットワークをフルに維持するのに利用可能なデータが不十分であり、最適以下の平均スループットが得られる。
バッファリングの量が>100msのレイテンシである(すなわち、大きなki)と仮定した場合、ネットワークを常にフルまたはフルに近い状態に維持することができる(最適な平均スループットが得られる)が、実際のレイテンシが<10msであるときはいつでもバッファリング(バッファブロート)によりさらなるレイテンシが存在する。
この例では、低レイテンシを必要とするフローが存在すれば、本システムは妥協して、低レイテンシのフロー伝送のために使用される接続上のバッファリングを<10msのレイテンシと想定されるレベル(すなわち、kiおよびbdp_mini(t)のために保存的/小さい値)に維持しなければならない。場合によっては、これにより、全体的により低い平均スループットとなる場合があるが、フローの要求を邪魔するバッファブロートは導入されない。本システムは、高スループットを必要とし、かつレイテンシセンシティブでないであるフローのために残りの接続上で会話するように構成することができる。
上記考察は、本発明の主題の多くの例示的な実施形態を提供している。各実施形態は発明要素の単一の組み合わせを表しているが、本発明の主題はここに開示されている要素の全ての可能な組み合わせを含むものとみなされる。従って、一実施形態が要素A、BおよびCを含み、かつ第2の実施形態が要素BおよびDを含む場合、たとえ明示的に開示されていないとしても、本発明の主題はA、B、CまたはDの他の残りの組み合わせも含むものとみなされる。
本明細書に記載されている装置、システムおよび方法の実施形態は、ハードウェアおよびソフトウェアの両方の組み合わせで実装されていてもよい。これらの実施形態はプログラム可能なコンピュータに実装されていてもよく、各コンピュータは、少なくとも1つのプロセッサ、データ記憶システム(揮発性メモリまたは不揮発性メモリまたは他のデータ記憶要素あるいはそれらの組み合わせを含む)、および少なくとも1つの通信インタフェースを備える。
プログラムコードは、本明細書に記載されている機能を実施して出力情報を生成するための入力データに適用される。この出力情報は1つ以上の出力装置に適用される。いくつかの実施形態では、通信インタフェースはネットワーク通信インタフェースであってもよい。要素を組み合わせることができる実施形態では、通信インタフェースは、プロセス間通信のためのインタフェースなどのソフトウェア通信インタフェースであってもよい。さらに他の実施形態では、ハードウェア、ソフトウェアおよびそれらの組み合わせとして実装されている通信インタフェースの組み合わせが存在してもよい。
実施形態の技術的解決法はソフトウェア製品の形態であってもよい。ソフトウェア製品は、コンパクトディスクリードオンリーメモリ(CD-ROM)、USBフラッシュディスクまたは取外し可能なハードディスクであってもよい不揮発性もしくは非一時的記憶媒体に記憶されていてもよい。ソフトウェア製品は、コンピュータ装置(パーソナルコンピュータ、サーバまたはネットワーク装置)に当該実施形態よって提供される方法を実行させることができる多くの命令を含む。
ネットワーク接続を通してデータフローを制御するためのネットワークゲートウェイは、対応する方法、装置およびコンピュータ可読メディアと共に本明細書に記載されている。本ゲートウェイは、いくつかの実施形態では、プログラムコードまたはコンピュータ論理の形態のソフトウェアおよび組み込みファームウェアを代表とする命令セットに従ってデータパケットを受信してルーティングするように構成された、プロセッサ、インタフェース、バス、電源、メモリ(ROM、RAM、フラッシュ)などの構成要素を備える物理的なハードウェア装置であってもよい。
プログラムコードおよび/またはコンピュータ論理は制御論理および装置を含み、いくつかの実施形態では、制御装置、ルーター、スイッチ、アクセス点などとして動作してもよく、上記装置は、最終使用者に透過であるように動作するように構成されていてもよい(可能な性能改善は別にして、特に大きな量のデータが上記装置を通るため)。
本ネットワークゲートウェイは一例では、本明細書中のいくつかの例に記載されているようにTCP接続を結合するために特に最適化された専門の計算装置であってもよい。本ネットワークゲートウェイは他の例では、より大きなシステムの一部としてプロセッサおよび/または他のコンピューティングハードウェアを用いて実装されていてもよい。本ネットワークゲートウェイは単一の装置であってもよく、あるいは場合によっては一斉に動作する複数の装置であってもよい。
本明細書に記載されている実施形態は、計算装置、サーバ、受信機、送信機、プロセッサ、メモリ、表示装置およびネットワークを備える物理的コンピュータハードウェアによって実装されている。本明細書に記載されている実施形態は、有用な物理的機械および特に設定されたコンピュータハードウェア構成を提供する。本明細書に記載されている実施形態は、様々な情報を表す電磁信号を処理および変形させるのに適した電子機械および電子機械によって実行される方法に関する。
本明細書に記載されている実施形態は、広範囲かつ一体的に機械およびそれらの使用に関し、本明細書に記載されている実施形態は、コンピュータハードウェア、機械および各種ハードウェア構成要素によるそれらの使用以外の意味または実用的適用性を有さない。例えば特にメンタルステップを用いる非物理的ハードウェアのために各種動作を実行するように構成された物理的ハードウェアの置き換えは、当該実施形態が作動する方法に実質的に影響を与える場合がある。そのようなコンピュータハードウェアの限界は本明細書に記載されている実施形態の明らかに必須の要素であり、それらは本明細書に記載されている実施形態の動作および構造に対して重大な影響を与えることなく省略することもメンタル手段と置き換えることもできない。コンピュータハードウェアは本明細書に記載されている様々な実施形態を実施するために必須であり、かつ迅速かつ効率的に工程を行うために単に使用されるものではない。
当該実施形態は詳細に記載されているが、当然のことながら本範囲から逸脱することなく本明細書では様々な変形、置換および変更を行うことができる。
さらに本出願の範囲は、本明細書に記載されているプロセス、機械、製造、物質の組成、手段、方法および工程の特定の実施形態に限定されるものではない。当業者であれば本開示から容易に理解するように、本明細書に記載されている対応する実施形態として実質的に同じ機能を行うか実質的に同じ結果を達成する現在存在するか後に開発されるプロセス、機械、製造、物質の組成、手段、方法または工程を利用してもよい。従って、添付の特許請求の範囲は、それらの範囲内でそのようなプロセス、機械、製造、物質の組成、手段、方法または工程を含むことが意図されている。
理解することができるように、上に記載され、かつ図示されている例は単に例示であることが意図されている。
Claims (37)
- 複数のネットワーク接続を通してデータフローをルーティングするためのネットワークゲートウェイであって、前記ネットワークゲートウェイは、
前記複数のネットワーク接続を通してデータを伝送するための複数のネットワークインタフェースと、
少なくとも1つのプロセッサであって、
前記複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、
パケットのデータフローの少なくとも1つのパケットを解析して前記データフローのためのデータフロークラスを特定することであって、前記データフロークラスは、前記データフローの少なくとも1つのネットワークインタフェース要件に関連づけられていることと、
前記データフロークラスおよび前記時変ネットワーク伝送特性に基づいて前記データフロー内のパケットを前記複数のネットワーク接続を通してルーティングすることと、
前記複数のネットワークインタフェースの第1のネットワークインタフェースを通してパケットの順次バーストを送信することと、
前記パケットの順次バースト内のパケットが受信ノードにおいて受信される際に記録されるタイムスタンプおよび前記パケットのサイズに基づいて、前記第1のネットワークインタフェースの帯域幅の推定値を生成することであって、前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、前記順次バースト内の特定のパケットの受信タイムスタンプを前記特定のパケット後に送信されたパケットの送信タイムスタンプと置き換えることを含むことと、
前記第1のネットワークインタフェースの生成された帯域幅の推定値に基づいて前記複数のネットワーク接続を通してパケットをルーティングすることと、
のために構成された、プロセッサと、
を備える、ネットワークゲートウェイ。 - 前記時変ネットワーク伝送特性を監視することは、前記監視される時変ネットワーク伝送特性に基づいて前記複数のネットワークの少なくとも1つのネットワークインタフェースの帯域幅遅延積を生成することを含み、かつ前記データフロー内のパケットをルーティングすることは、前記少なくとも1つのネットワークインタフェースの帯域幅遅延積に基づいている、請求項1に記載のネットワークゲートウェイ。
- 前記少なくとも1つのプロセッサは、
パケットの複数のデータフローのそれぞれの少なくとも1つのパケットを解析し、かつ
前記複数のデータフローのそれぞれのデータフロークラス、および前記それぞれのデータフローのデータフロークラスに対応している前記ネットワーク接続の利用可能な帯域幅に基づいて、前記複数のデータフローのそれぞれの中のパケットをルーティングする
ように構成されている、請求項1に記載のネットワークゲートウェイ。 - 前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の第1のパケットと前記バースト内の第2のパケットとの間のパケットのパケットサイズの合計を前記第1のパケットのためのタイムスタンプと前記第2のパケットのためのタイムスタンプとの間で経過した時間で割ることを含み、ここでは前記第1のパケットは前記バースト内の最初のパケットではなく、かつ前記第2のパケットは前記バースト内の第1のパケットの後のものである、請求項1に記載のネットワークゲートウェイ。
- 前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の最初もしくは最後のパケットと合体されていない前記バースト内のパケットのタイムスタンプに基づいて前記帯域幅の推定値を生成することを含む、請求項1に記載のネットワークゲートウェイ。
- 前記受信ノードが定期的な間隔で受信されたパケットを処理する場合、前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、
前記帯域幅決定においてエンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを用いることによって下限帯域幅値を生成することと、
前記エンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを前記エンドパケットに先行する前記バースト内のパケットの受信タイムスタンプと置き換えることによって上限帯域幅値を生成することと、
を含む、請求項1に記載のネットワークゲートウェイ。 - 前記少なくとも1つのプロセッサは、
前記データフロー内のパケットの各パケットのために、前記データフロー内のパケットが所望のシーケンスで宛先ノードに到着するように、前記複数のネットワーク接続の監視されたレイテンシに基づく前記複数のネットワーク接続および前記データフロー内の他のパケットのネットワーク接続のうちの1つを通してルーティングするために前記パケットを提供すること
のために構成されている、請求項1に記載のネットワークゲートウェイ。 - 前記所望のシーケンスは前記データフロー内のパケットの元のシーケンスである、請求項7に記載のネットワークゲートウェイ。
- 前記所望のシーケンスは、前記シーケンス内でのパケットの再送をトリガーしないパケットの少なくとも1つの誤順序付けを含むシーケンスである、請求項7に記載のネットワークゲートウェイ。
- 前記少なくとも1つのプロセッサは、
前記複数のネットワーク接続を介して宛先ノードにルーティングするためにソースインタフェースからパケットを受信することと、
前記パケットを前記宛先ノードにルーティングする前に肯定応答を前記ソースインタフェースに送信することと、
前記パケットが前記宛先ノードにルーティングされる前に前記パケットを少なくとも1つのバッファに格納することと、
のために構成されている、請求項1に記載のネットワークゲートウェイ。 - 前記少なくとも1つのプロセッサは、前記複数のネットワーク接続に関連づけられた帯域幅遅延積に基づいて前記少なくとも1つのバッファのサイズを動的に制御することのために構成されている、請求項10に記載のネットワークゲートウェイ。
- 前記少なくとも1つのプロセッサは、前記複数のネットワーク接続の伝送特性の監視および前記順次パケットのデータフローの受信における不均等分配に基づいて、前記パケットの肯定応答の送信および格納を制御することのために構成されている、請求項10に記載のネットワークゲートウェイ。
- 前記少なくとも1つのプロセッサは、前記複数のネットワーク接続の帯域幅の推定値、およびそれを通して前記データフローがルーティングされるネットワーク接続の数の減少のうちの少なくとも1つに基づいて前記パケットをルーティングするように構成されている、請求項1に記載のネットワークゲートウェイ。
- 前記少なくとも1つのプロセッサは、同様のデータフロークラスを有する前記複数のデータフローのパケットをグループ化し、かつ前記複数のデータフローの分類に基づいてグループ化されたパケットを前記複数のネットワーク接続を通してルーティングするように構成されている、請求項3に記載のネットワークゲートウェイ。
- 前記複数のデータフローの1つのデータフロークラスは、対応するデータフローの閾値体積のデータがルーティングされると自動的に変わる、請求項1に記載のネットワークゲートウェイ。
- 前記パケットのデータフローはビデオおよび音声データのうちの少なくとも1つを含むデータパケットである、請求項1に記載のネットワークゲートウェイ。
- 前記パケットの順次バーストは、帯域幅の推定値の決定を行うために利用されるテストパケットならびにビデオおよび音声データのうちの少なくとも1つを含むデータパケットの両方を含む、請求項1に記載のネットワークゲートウェイ。
- 前記パケットの順次バーストを通して伝送される前記ビデオおよび音声データのうちの少なくとも1つを含む前記データパケットは、失われたデータパケットの量に耐えるように構成された冗長データパケットである、請求項17に記載のネットワークゲートウェイ。
- 複数のネットワーク接続を通してデータを伝送するために複数のネットワークインタフェースを通してデータフローをルーティングするための方法であって、前記方法は、
前記複数のネットワーク接続の時変ネットワーク伝送特性を監視することと、
パケットのデータフローの少なくとも1つのパケットを解析して前記データフローのためのデータフロークラスを特定することであって、前記データフロークラスは、前記データフローの少なくとも1つのネットワークインタフェース要件に関連づけられていることと、
前記データフロークラスおよび前記時変ネットワーク伝送特性に基づいて前記データフロー内のパケットを前記複数のネットワーク接続を通してルーティングすることと、
前記複数のネットワークインタフェースの第1のネットワークインタフェースを通してパケットの順次バーストを送信することと、
前記パケットの順次バースト内のパケットが受信ノードにおいて受信される際に記録されるタイムスタンプおよび前記パケットのサイズに基づいて、前記第1のネットワークインタフェースの帯域幅の推定値を生成することであって、前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、前記順次バースト内の特定のパケットの受信タイムスタンプを前記特定のパケット後に送信されたパケットの送信タイムスタンプと置き換えることを含むことと、
前記第1のネットワークインタフェースの生成された帯域幅の推定値に基づいて前記複数のネットワーク接続を通してパケットをルーティングすることと、
を含む、方法。 - 前記時変ネットワーク伝送特性を監視することは、前記監視される時変ネットワーク伝送特性に基づいて前記複数のネットワークの少なくとも1つのネットワークインタフェースの帯域幅遅延積を生成することを含み、かつ前記データフロー内のパケットをルーティングすることは、前記少なくとも1つのネットワークインタフェースの帯域幅遅延積に基づいている、請求項19に記載の方法。
- パケットの複数のデータフローのそれぞれの少なくとも1つのパケットを解析することと、
前記複数のデータフローのそれぞれのデータフロークラス、および前記それぞれのデータフローのデータフロークラスに対応している前記ネットワーク接続の利用可能な帯域幅に基づいて、前記複数のデータフローのそれぞれの中のパケットをルーティングすることと、
を含む、請求項19に記載の方法。 - 前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の第1のパケットと前記バースト内の第2のパケットとの間のパケットのパケットサイズの合計を前記第1のパケットのためのタイムスタンプと前記第2のパケットのためのタイムスタンプとの間で経過した時間で割ることを含み、ここでは前記第1のパケットは前記バースト内の最初のパケットではなく、かつ前記第2のパケットは前記バースト内の第1のパケットの後のものである、請求項19に記載の方法。
- 前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、前記バースト内の最初もしくは最後のパケットと合体されていない前記バースト内のパケットのタイムスタンプに基づいて前記帯域幅の推定値を生成することを含む、請求項19に記載の方法。
- 前記受信ノードが定期的な間隔で受信されたパケットを処理する場合、前記第1のネットワークインタフェースの帯域幅の推定値を生成することは、
前記帯域幅決定においてエンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを用いることによって下限帯域幅値を生成することと、
前記エンドパケットとして選択された前記バースト内のパケットの受信タイムスタンプを前記エンドパケットに先行する前記バースト内のパケットの受信タイムスタンプと置き換えることによって上限帯域幅値を生成することと、
を含む、請求項19に記載の方法。 - 前記データフロー内のパケットの各パケットのために、前記データフロー内のパケットが所望のシーケンスで宛先ノードに到着するように、前記複数のネットワーク接続の監視されたレイテンシに基づく前記複数のネットワーク接続および前記データフロー内の他のパケットのネットワーク接続のうちの1つを通してルーティングするために前記パケットを提供すること
を含む、請求項19に記載の方法。 - 前記所望のシーケンスは前記データフロー内のパケットの元のシーケンスである、請求項25に記載の方法。
- 前記所望のシーケンスは、前記シーケンス内でのパケットの再送をトリガーしないパケットの少なくとも1つの誤順序付けを含むシーケンスである、請求項25に記載の方法。
- 前記複数のネットワーク接続を介して宛先ノードにルーティングするためにソースインタフェースからパケットを受信することと、
前記パケットを前記宛先ノードにルーティングする前に肯定応答を前記ソースインタフェースに送信することと、
前記パケットが前記宛先ノードにルーティングされる前に前記パケットを少なくとも1つのバッファに格納することと、
を含む、請求項19に記載の方法。 - 前記複数のネットワーク接続に関連づけられた帯域幅遅延積に基づいて前記少なくとも1つのバッファのサイズを動的に制御することを含む、請求項28に記載の方法。
- 前記複数のネットワーク接続の伝送特性の監視および前記順次パケットのデータフローの受信における不均等分配に基づいて、前記パケットの肯定応答の送信および格納を制御することを含む、請求項28に記載の方法。
- 前記複数のネットワーク接続の帯域幅、およびそれを通して前記データフローがルーティングされるネットワーク接続の数の減少のうちの少なくとも1つに基づいて前記パケットをルーティングすることを含む、請求項19に記載の方法。
- 同様のデータフロークラスを有する前記複数のデータフローのパケットをグループ化することと、前記複数のデータフローの分類に基づいてグループ化されたパケットを前記複数のネットワーク接続を通してルーティングすることとを含む、請求項21に記載の方法。
- 前記複数のデータフローの1つのデータフロークラスは、対応するデータフローの閾値体積のデータがルーティングされると自動的に変わる、請求項19に記載の方法。
- 前記パケットのデータフローはビデオおよび音声データのうちの少なくとも1つを含むデータパケットである、請求項19に記載の方法。
- 前記パケットの順次バーストは、帯域幅の推定値の決定を行うために利用されるテストパケットならびにビデオおよび音声データのうちの少なくとも1つを含むデータパケットの両方を含む、請求項19に記載の方法。
- 前記パケットの順次バーストを通して伝送される前記ビデオおよび音声データのうちの少なくとも1つを含む前記データパケットは、失われたデータパケットの量に耐えるように構成された冗長データパケットである、請求項35に記載の方法。
- 実行されるときに、1つ以上のプロセッサに請求項19~36のいずれか1項に記載の方法を行わせる機械解釈可能命令のセットを格納するコンピュータ可読媒体。
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662437635P | 2016-12-21 | 2016-12-21 | |
US62/437,635 | 2016-12-21 | ||
US201762558610P | 2017-09-14 | 2017-09-14 | |
US62/558,610 | 2017-09-14 | ||
JP2019534168A JP7173587B2 (ja) | 2016-12-21 | 2017-12-21 | パケット伝送システムおよび方法 |
PCT/CA2017/051584 WO2018112657A1 (en) | 2016-12-21 | 2017-12-21 | Packet transmission system and method |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019534168A Division JP7173587B2 (ja) | 2016-12-21 | 2017-12-21 | パケット伝送システムおよび方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023002774A true JP2023002774A (ja) | 2023-01-10 |
Family
ID=62624135
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019534168A Active JP7173587B2 (ja) | 2016-12-21 | 2017-12-21 | パケット伝送システムおよび方法 |
JP2022172589A Pending JP2023002774A (ja) | 2016-12-21 | 2022-10-27 | パケット伝送システムおよび方法 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019534168A Active JP7173587B2 (ja) | 2016-12-21 | 2017-12-21 | パケット伝送システムおよび方法 |
Country Status (6)
Country | Link |
---|---|
US (3) | US11438265B2 (ja) |
EP (1) | EP3560154A4 (ja) |
JP (2) | JP7173587B2 (ja) |
AU (2) | AU2017383561B2 (ja) |
CA (1) | CA3048055A1 (ja) |
WO (1) | WO2018112657A1 (ja) |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108696427B (zh) * | 2017-04-11 | 2020-05-08 | 华为技术有限公司 | 一种数据传输方法及装置 |
US11477305B2 (en) * | 2017-05-03 | 2022-10-18 | Comcast Cable Communications, Llc | Local cache bandwidth matching |
CN109327400B (zh) * | 2017-08-01 | 2022-04-26 | 华为技术有限公司 | 一种数据通信方法及数据通信网络 |
US20190141560A1 (en) * | 2017-11-07 | 2019-05-09 | Nokia Solutions And Networks Oy | Call admission control for multimedia delivery in multi-radio access technology networks |
US10931587B2 (en) * | 2017-12-08 | 2021-02-23 | Reniac, Inc. | Systems and methods for congestion control in a network |
US10893437B2 (en) * | 2018-02-27 | 2021-01-12 | Verizon Patent And Licensing Inc. | Out-of-order packet handling in 5G/new radio |
EP3777291B1 (en) * | 2018-05-31 | 2022-09-14 | Google LLC | Mobile device configuration for wireless networks |
CN111316604B (zh) * | 2018-07-23 | 2021-07-09 | 华为技术有限公司 | 一种数据传输方法及电子设备 |
CN111416794B (zh) | 2019-01-08 | 2022-07-29 | 华为技术有限公司 | 一种数据传输方法及电子设备 |
US10869228B2 (en) | 2019-02-13 | 2020-12-15 | Nokia Solutions And Networks Oy | Resource allocation |
EP3716537A1 (de) * | 2019-03-25 | 2020-09-30 | Siemens Aktiengesellschaft | Verfahren zur datenkommunikation, netzwerkknoten, computerprogramm und computerlesbares medium |
US11695703B2 (en) * | 2019-05-14 | 2023-07-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Multi-timescale packet marker |
CA3149828A1 (en) * | 2019-08-08 | 2021-02-11 | Imad AZZAM | Systems and methods for managing data packet communications |
US10873533B1 (en) * | 2019-09-04 | 2020-12-22 | Cisco Technology, Inc. | Traffic class-specific congestion signatures for improving traffic shaping and other network operations |
US11151150B2 (en) | 2019-09-13 | 2021-10-19 | Salesforce.Com, Inc. | Adjustable connection pool mechanism |
US11252626B2 (en) * | 2019-10-01 | 2022-02-15 | Honeywell International Inc. | Data transmission protocol to reduce delay during link switchovers |
US11636067B2 (en) | 2019-10-04 | 2023-04-25 | Salesforce.Com, Inc. | Performance measurement mechanism |
US11165857B2 (en) | 2019-10-23 | 2021-11-02 | Salesforce.Com, Inc. | Connection pool anomaly detection mechanism |
US11463371B2 (en) | 2019-12-02 | 2022-10-04 | Citrix Systems, Inc. | Discovery and adjustment of path maximum transmission unit |
US11228536B2 (en) * | 2020-01-15 | 2022-01-18 | Qualcomm Incorporated | Usage of QUIC spin bit in wireless networks |
US11611517B2 (en) * | 2020-05-29 | 2023-03-21 | Equinix, Inc. | Tenant-driven dynamic resource allocation for virtual network functions |
IL275018A (en) * | 2020-05-31 | 2021-12-01 | B G Negev Technologies And Applications Ltd At Ben Gurion Univ | A system and method for predicting and handling short-term data overflow |
US11558284B2 (en) * | 2020-06-30 | 2023-01-17 | Redline Communications Inc. | Variable link aggregation |
WO2022106868A1 (en) * | 2020-11-20 | 2022-05-27 | Pismo Labs Technology Limited | Method and systems for reducing network latency |
EP4075742A1 (en) * | 2021-04-14 | 2022-10-19 | Deutsche Telekom AG | System and method for multipath transmission with efficient adjustable reliability |
CN115412508A (zh) * | 2021-05-28 | 2022-11-29 | 华为技术有限公司 | 传输报文的方法及装置 |
JPWO2023276220A1 (ja) | 2021-06-30 | 2023-01-05 | ||
US20230141738A1 (en) * | 2021-11-05 | 2023-05-11 | Maxlinear, Inc. | Latency reduction with orthogonal frequency division multiple access (ofdma) and a multiple resource unit (mru) |
CN114553783B (zh) * | 2022-02-23 | 2023-06-16 | 湖南工学院 | 数据中心网络自适应调整流胞粒度的负载均衡方法 |
US11936564B2 (en) * | 2022-05-18 | 2024-03-19 | Cisco Technology, Inc. | Dynamically enabling a transport control protocol proxy for satellite networks |
CN114915600B (zh) * | 2022-06-10 | 2023-06-27 | 贵州大学 | 一种深度缓冲区下BBRv2拥塞控制方法 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2934279B2 (ja) | 1990-04-27 | 1999-08-16 | 日本電信電話株式会社 | 移動通信パケット転送制御方式 |
EP0948168A1 (en) * | 1998-03-31 | 1999-10-06 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Method and device for data flow control |
US6778495B1 (en) * | 2000-05-17 | 2004-08-17 | Cisco Technology, Inc. | Combining multilink and IP per-destination load balancing over a multilink bundle |
US20020169880A1 (en) | 2001-04-19 | 2002-11-14 | Koninklijke Philips Electronics N.V. | Method and device for robust real-time estimation of the bottleneck bandwidth in the internet |
JP2004159146A (ja) | 2002-11-07 | 2004-06-03 | Nippon Telegr & Teleph Corp <Ntt> | 通信ネットワーク及びパケット転送装置 |
US7543052B1 (en) * | 2003-12-22 | 2009-06-02 | Packeteer, Inc. | Automatic network traffic discovery and classification mechanism including dynamic discovery thresholds |
CA2556420A1 (en) | 2004-02-19 | 2005-09-01 | Georgia Tech Research Corporation | Systems and methods for parallel communication |
JP2006060579A (ja) | 2004-08-20 | 2006-03-02 | Fujitsu Ltd | アプリケーション特性に応じて複数の経路を同時に利用する通信装置 |
JP4627669B2 (ja) | 2005-03-16 | 2011-02-09 | アラクサラネットワークス株式会社 | パケット転送装置およびその転送制御方式 |
US8139487B2 (en) | 2007-02-28 | 2012-03-20 | Microsoft Corporation | Strategies for selecting a format for data transmission based on measured bandwidth |
US8717885B2 (en) | 2007-04-26 | 2014-05-06 | Mushroom Networks, Inc. | Link aggregation methods and devices |
US8873560B2 (en) | 2009-07-08 | 2014-10-28 | Dejero Labs Inc. | Multipath video streaming over a wireless network |
WO2013060378A1 (en) | 2011-10-28 | 2013-05-02 | Telecom Italia S.P.A. | Apparatus and method for selectively delaying network data flows |
CN103369594B (zh) | 2012-04-06 | 2016-10-05 | 华为技术有限公司 | 一种标记业务数据包的方法、装置及系统 |
JP2014003459A (ja) | 2012-06-19 | 2014-01-09 | Hitachi Ltd | ゲートウェイ装置、及びパケット通信方法 |
EP2883385B1 (en) | 2012-09-07 | 2020-01-08 | Dejero Labs Inc. | Method for characterization and optimization of multiple simultaneous real-time data connections |
KR102187810B1 (ko) * | 2014-09-26 | 2020-12-08 | 삼성전자주식회사 | 통신 시스템에서 데이터 흐름 제어 장치 및 방법 |
-
2017
- 2017-12-21 AU AU2017383561A patent/AU2017383561B2/en active Active
- 2017-12-21 WO PCT/CA2017/051584 patent/WO2018112657A1/en unknown
- 2017-12-21 US US16/482,972 patent/US11438265B2/en active Active
- 2017-12-21 CA CA3048055A patent/CA3048055A1/en active Pending
- 2017-12-21 JP JP2019534168A patent/JP7173587B2/ja active Active
- 2017-12-21 EP EP17883631.8A patent/EP3560154A4/en active Pending
-
2022
- 2022-09-05 US US17/903,024 patent/US11876711B2/en active Active
- 2022-10-27 JP JP2022172589A patent/JP2023002774A/ja active Pending
-
2023
- 2023-02-10 AU AU2023200735A patent/AU2023200735A1/en active Pending
-
2024
- 2024-01-15 US US18/413,010 patent/US20240163212A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
EP3560154A4 (en) | 2020-06-03 |
AU2017383561B2 (en) | 2022-11-10 |
US11438265B2 (en) | 2022-09-06 |
EP3560154A1 (en) | 2019-10-30 |
JP7173587B2 (ja) | 2022-11-16 |
US11876711B2 (en) | 2024-01-16 |
JP2020502948A (ja) | 2020-01-23 |
AU2023200735A1 (en) | 2023-03-09 |
AU2017383561A1 (en) | 2019-06-27 |
CA3048055A1 (en) | 2018-06-28 |
US20220417151A1 (en) | 2022-12-29 |
US20240163212A1 (en) | 2024-05-16 |
WO2018112657A1 (en) | 2018-06-28 |
US20200236043A1 (en) | 2020-07-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7173587B2 (ja) | パケット伝送システムおよび方法 | |
EP2959645B1 (en) | Dynamic optimization of tcp connections | |
CA2805105C (en) | System, method and computer program for intelligent packet distribution | |
EP3714580A1 (en) | Latency increase estimated rate limiter adjustment | |
US20220166724A1 (en) | Application-based traffic control in multipath networks | |
US20220294727A1 (en) | Systems and methods for managing data packet communications | |
EP3281380A1 (en) | Method and system for the scheduling of packets in a bundling scenario based on tcp tunnels and native tcp information | |
JP2014518047A (ja) | 適応性の伝送キュー長を用いたデータパケット損失低減システムおよび方法 | |
SE546013C2 (en) | Edge node control | |
Halepoto et al. | Management of buffer space for the concurrent multipath transfer over dissimilar paths | |
WO2017059932A1 (en) | Controlling downstream flow of data packets to one or more clients | |
AU2021279111A1 (en) | Systems and methods for data transmission across unreliable connections | |
Ramaboli | Concurrent multipath transmission to improve performance for multi-homed devices in heterogeneous networks | |
Havey | Throughput and Delay on the Packet Switched Internet (A Cross-Disciplinary Approach) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20221118 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20231206 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20240123 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20240422 |