JP6632966B2 - ネットワークデバイスおよびトラフィックシェーピング方法 - Google Patents

ネットワークデバイスおよびトラフィックシェーピング方法 Download PDF

Info

Publication number
JP6632966B2
JP6632966B2 JP2016251237A JP2016251237A JP6632966B2 JP 6632966 B2 JP6632966 B2 JP 6632966B2 JP 2016251237 A JP2016251237 A JP 2016251237A JP 2016251237 A JP2016251237 A JP 2016251237A JP 6632966 B2 JP6632966 B2 JP 6632966B2
Authority
JP
Japan
Prior art keywords
traffic shaping
data
queue
transmission
packets
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.)
Active
Application number
JP2016251237A
Other languages
English (en)
Other versions
JP2017163530A5 (ja
JP2017163530A (ja
Inventor
カルロ・コンタバリ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of JP2017163530A publication Critical patent/JP2017163530A/ja
Publication of JP2017163530A5 publication Critical patent/JP2017163530A5/ja
Application granted granted Critical
Publication of JP6632966B2 publication Critical patent/JP6632966B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/22Traffic shaping
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/22Traffic shaping
    • H04L47/225Determination of shaping rate, e.g. using a moving window
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/6205Arrangements for avoiding head of line blocking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9026Single buffer per packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9036Common buffer combined with individual queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/50Queue scheduling
    • H04L47/62Queue scheduling characterised by scheduling criteria
    • H04L47/6215Individual queue per QOS, rate or priority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/901Buffering arrangements using storage descriptor, e.g. read or write pointers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

背景
トラフィックシェーピングとは、優先されるトラフィックストリームほど重要ではない、または所望されないと判断されたトラフィックストリームを遅くすることによって、ネットワークデータトラフィックを調整する手法である。ストリームを遅くするための共通のメカニズムは2つあり、第1のメカニズムはいくつかのパケットを破棄または廃棄すること、第2のメカニズムはパケットを遅延させることである。パケット破棄メカニズムは広く使用されており、多くの場合、唯一の実行可能な解決策として考えてられている。たとえば、トラフィックシェーピングは、コンピュータが接続された別個のデバイスによって行なわれる場合、パケットを選択的に破棄することによって行なわれ得る。
これに代えて、パケット遅延メカニズムは、パケット破棄なしで済ますこと、または破棄されるパケットの数を減少させることができる。たとえば、パケットが遅延されると、フィードバックメカニズムは、送信モジュール(たとえば、デバイスまたはソフトウエアコンポーネント)に「背圧」をかけ、すなわちフィードバックを送信して、送信モジュールに、それがパケットを送信する速度を減少させるようにすることができる。そのような「背圧」がなければ、トラフィックシェーピングモジュールは、より速い速度でパケットを受信し続ける必要があり、また、それが正しい速度でパケットを送信するできる時間までパケットをバッファに入れる必要があるであろう。そのような「背圧」の欠如は、アプリケーションがトラフィック輻輳をすぐ認識するのを妨げるだけではなく、パケット送信システムの全体的なスループットおよび性能を低下させるであろう。
概要
一局面では、ネットワークデバイスを含むシステムが提示される。ネットワークデバイスは、ネットワークインターフェイスドライバと、データトラフィックシェーピングモジュールと、ネットワークカードとを含む。ネットワークインターフェイスカードは、ソフトウェアアプリケーションによって生成され発送された第1の組のデータパケットを、ネットワークカードによる送信のために送信し、受信された第1の組のデータパケットに関連付けられた記述子を第1の順序で一次送信キューに格納し、受信された第1の組のデータパケットに関連付けられた記述子を、ネットワークカードおよび少なくとも1つのプロセッサのうちの一方上で実行されるデータトラフィックシェーピングモジュールに転送するように構成される。受信された第1の組のパケットのうちの1つのパケットがネットワークカードによって順調に送信されたという判断に応答して、ネットワークインターフェイスカードは、パケット送信完了メッセージをソフトウェアアプリケーションに通信するように構成され、ソフトウェアアプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。データトラフィックシェーピングモジュールは、複数のトラフィックシェーピングキューを維持するように構成され、それらの各々は少なくとも1つの関連付けられた送信速度規則を有する。データトラフィックシェーピングモジュールはさらに、一次送信キューから、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を受信し、ネットワークカードによる送信が遅延される必要があると判断し、そのような判断に応答して記述子を一次送信キューから除去し、分類の結果に基づいてそれを対応するトラフィックシェーピングキューに格納するように構成される。データトラフィックシェーピングモジュールはさらに、ネットワークカードに、二次的なトラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させ、ネットワークインターフェイスドライバに、第1の順序とは異なる第2の順序でのデータパケットの順調な送信を通知するように構成される。
一局面では、ソフトウェアアプリケーションによって生成され発送された第1の組のデータパケットを、ネットワークカードによる送信のために、少なくとも1つのプロセッサ上で実行されるネットワークインターフェイスドライバによって受信することを含む方法が提示される。この方法はさらに、受信された第1の組のデータパケットに関連付けられた記述子を、ネットワークインターフェイスドライバによって、第1の順序で一次送信キューに格納することと、受信された第1の組のデータパケットに関連付けられた記述子を、ネットワークインターフェイスドライバによって、ネットワークカードおよび少なくとも1つのプロセッサのうちの一方上で実行されるデータトラフィックシェーピングモジュールに転送することとを含む。この方法はさらに、受信された第1の組のパケットのうちの1つのパケットがネットワークカードによって順調に送信されたという判断に応答して、ネットワークインターフェイスカードによって、パケット送信完了メッセージをソフトウェアアプリケーションに通信することを含み、ソフトウェアアプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。この方法はさらに、データトラフィックシェーピングモジュールによって、複数のトラフィックシェーピングキューを維持することを含み、それらの各々は少なくとも1つの関連付けられた送信速度規則を有し、さらに、一次送信キューから、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を、データトラフィックシェーピングモジュールによって受信することを含む。この方法はさらに、受信された記述子に関連付けられたデータパケットを、データトラフィックシェーピングモジュールによって分類することと、データトラフィックシェーピングモジュールによって、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、第1のデータパケットに関連付けられた第1の記述子を一次送信キューから除去し、分類の結果に基づいて第1の記述子を対応するトラフィックシェーピングキューに格納することとを含む。この方法はさらに、データトラフィックシェーピングモジュールによって、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させることと、データトラフィックシェーピングモジュールによって、ネットワークインターフェイスドライバに、第1の順序とは異なる第2の順序でのデータパケットの順調な送信を通知することとを含む。
一局面では、コンピュータ読取可能媒体は命令を格納し、命令は、コンピューティングプロセッサによって実行されると、コンピューティングプロセッサが、ソフトウェアアプリケーションによって生成され発送された第1の組のデータパケットを、ネットワークカードによる送信のために、コンピューティングプロセッサ上で実行されるネットワークインターフェイスドライバを介して受信するようにする。コンピューティングプロセッサはさらに、受信された第1の組のデータパケットに関連付けられた記述子を、ネットワークインターフェイスドライバを介して、一次送信キューに格納するようにされる。コンピューティングプロセッサはさらに、受信された第1の組のデータパケットに関連付けられた記述子を、ネットワークインターフェイスドライバを介して、ネットワークカードおよびコンピューティングプロセッサのうちの一方上で実行されるデータトラフィックシェーピングモジュールに転送するようにされる。受信された第1の組のパケットのうちの1つのパケットがネットワークカードによって順調に送信されたという判断に応答して、コンピューティングプロセッサはさらに、ネットワークインターフェイスカードを介して、パケット送信完了メッセージをソフトウェアアプリケーションに通信するようにされ、ソフトウェアアプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。コンピューティングプロセッサはさらに、データトラフィックシェーピングモジュールを介して、複数のトラフィックシェーピングキューを維持するようにされ、それらの各々は少なくとも1つの関連付けられた送信速度規則を有する。コンピューティングプロセッサはさらに、一次送信キューから、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を、データトラフィックシェーピングモジュールを介して受信し、受信された記述子に関連付けられたデータパケットを、データトラフィックシェーピングモジュールを介して分類するようにされる。コンピューティングプロセッサはさらに、データトラフィックシェーピングモジュールを介して、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、第1のデータパケットに関連付けられた第1の記述子を一次送信キューから除去し、分類の結果に基づいて第1の記述子を対応するトラフィックシェーピングキューに格納するようにされる。コンピューティングプロセッサはさらに、データトラフィックシェーピングモジュールを介して、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させる。コンピューティングプロセッサはさらに、データトラフィックシェーピングモジュールを介して、ネットワークインターフェイスドライバに、データパケットの順調な送信を通知するようにされる。
図面の簡単な説明
本開示の上述のおよび関連する目的、特徴、ならびに利点は、以下の詳細な説明を以下の図とともに参照することによって、より十分に理解されるであろう。
いくつかの実現化例に従ったデータトラフィックシェーピングシステムを有するネットワーク環境のブロック図である。 例示的な仮想マシン環境のブロック図である。 いくつかの実現化例に従ったネットワークインターフェイスドライバの動作を示すフローチャートである。 いくつかの実現化例に従ったデータトラフィックシェーピングモジュールの動作を示すフローチャートである。 いくつかの実現化例に従ったネットワークインターフェイスドライバの動作を示すフローチャートである。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である。 例示的なコンピューティングシステムのブロック図である。
詳細な説明
ネットワークデバイスにおけるトラフィックシェーピングに関するシステムおよび方法が提示される。いくつかの実現化例では、これらのシステムおよび方法は、受信されたパケットに関連付けられた記述子を送信キューに格納し、記述子をトラフィックシェーピングモジュールに転送するように構成された、ネットワークデバイスのネットワークインターフェイスドライバを含む。受信されたパケットは、コンピューティングデバイス上で、たとえば、コンピューティングデバイスによってホストされる1つ以上の仮想マシン上で実行されるアプリケーションから生じる。仮想マシンのゲストオペレーティングシステムは、以前に発送されたパケットが順調に送信されたことを確認するメッセージが受信されるまで、アプリケーションが追加のパケットをネットワークインターフェイスドライバに発送するのを妨げる。ここに説明されるように、いくつかの実現化例では、受信されたパケットの第1のパケットがネットワークカードによって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバは、パケット送信完了メッセージをソフトウェアアプリケーションまたはゲストオペレーティングシステムに通信し、それは、パケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。いくつかの実現化例では、受信されたパケットのうちの1つのパケットの、ネットワークカードによる送信が遅延されるべきであるという判断に応答して、トラフィックシェーピングモジュールは、そのパケットに関連付けられた記述子を送信キューから除去し、その記述子を対応するトラフィックシェーピングキューに格納する。この構成は、ネットワークインターフェイスドライバにおける単一の一次送信キューと、異なるトラフィックシェーピング規則を採用する(たとえばネットワークインターフェイスカードにおける)複数のトラフィックシェーピングキューとで実現可能であり、このため、ネットワークインターフェイスドライバにおける複数の送信キューを必要とせずに、フロー毎のトラフィックシェーピングを可能にする。さらに、この構成では、(仮想マシンのゲストOS上ではなく)ネットワークデバイスの実OS上で作動するソフトウェアアプリケーション、もしくは、ハイパーバイザによって管理されるゲストOSにおけるソフトウェアアプリケーションまたはTCPスタックの上位層、といったパケットソースは、ネットワークインターフェイスドライバにおいて、またはネットワークカード上で実現されるトラフィックシェーピングアルゴリズムを認識しなくてもよい。したがって、仮想マシン環境でネットワークインターフェイスドライバおよびゲストオペレーティングシステムを実現するコストを減少させることができる。また、この構成では、パケットソースは、トラフィックシェーピングアルゴリズムだけでなく、他の構成、たとえばパケット分類規則、および他のトラフィック調整ポリシーも認識しなくてもよい。したがって、トラフィックシェーピングシステム全体は、アプリケーションまたはユーザがそのような詳細な規則およびポリシー(たとえばキューの数)を構成できるシステムよりも、信頼性がより高くなり得る。
従来のシステムでは、パケットは、送信キュー、たとえば先入れ先出し(first-in-first-out:FIFO)キューから順に処理され、完了が順に返される。本開示におけるいくつかの実現化例では、トラフィックシェーピングモジュールは、(破棄のない)遅延された送信のためにいくつかのデータパケットを送信キューから除去することによって、完了メッセージがバラバラの順序で返されるようにすることができる。この「順序がバラバラの完了」の構成では、ネットワークインターフェイスドライバにすでに発送されたデータパケットについての完了メッセージが受信されるまで、アプリケーションはより多くのデータパケットを送信しないため、アプリケーションは、単一の送信キューを依然として有しながら、データパケットをより早くまたはより遅く送信するようにされ得る。すなわち、この構成は、遅延されるべきデータパケットがキューに残ることを妨げることによって、ライン先頭ブロッキング(head of line blocking)を避けることができる。さらに、いくつかの実現化例では、この「順序がバラバラの」完了構成を、アプリケーション、たとえば対応するフローまたはストリームのために開かれる何千もの接続を有するアプリケーション内のデータパケットの個々のフロー(またはストリーム)に当てはめることができ、そのため、各フローを選択的に遅くすることができる。
さらに、いくつかの実現化例では、「順序がバラバラの」完了構成は、一次送信キューがいくつあるか、またはパケットがどのように各キューに入れられるかにかかわらず、完了メッセージがバラバラの順序で返され得る限り、ライン先頭ブロッキングなしで「背圧」を送信モジュールにかけることができる。いくつかの実現化例では、「順序がバラバラの」完了構成を有するトラフィックシェーピングメカニズムが、特定のネットワーク/ハードウェア構成(たとえば、特定数の一次送信キューおよび特定のキュー割当て規則)で実現可能である。たとえば、トラフィックの千個のフロー/ストリームをシェーピングするために、トラフィックシェーピングメカニズムは、単一のキューのみで、または少数のキュー(たとえば16〜32個のキュー)で実現可能である。少数のキューを有するシステムにおいて実現される場合、トラフィックシェーピングメカニズムは、各パケットが予め定められたキュー割当て規則に基づいて正しいキューに入れられるか、またはパケットトラフィックがキュー中に「ランダムに」分散されるかにかかわらず、「順序がバラバラの」完了メッセージを返すことができる。たとえば、Linux(登録商標)システムから多数のハードウェアキュー中に分散されたパケットトラフィックをシェーピングするための「順序がバラバラの」完了トラフィックシェーピングシステムが、仮想マシンにおいて、ネットワーク/ハードウェア構成(たとえば、Linuxシステムのキュー割当て規則、またはハードウェアキューの数)の修正なしで実現可能である。いくつかの実現化例では、トラフィックシェーピングシステムは、トラフィックシェーピング層、フロー分類規則およびポリシーをアプリケーションまたはユーザから隠すことによって、そのようなネットワーク/ハードウェア互換性を提供することができる。
図1は、データトラフィックシェーピングシステム160を有する例示的なネットワーク環境1000のブロック図である。広範な概観では、図示されたネットワーク環境は、相互接続されたネットワークノード750のネットワーク700を含む。ネットワークノード750は、データソース、データ宛先(またはデータシンク)、およびデータをソースからネットワーク700を通して宛先に伝搬する中間ノードとして、ネットワーク700に関与する。ネットワーク700は、さまざまな他の関与するネットワークノード750へのリンク600を有するネットワークデバイス110のデータトラフィックシェーピングシステム160を含む。図1をより詳細に参照して、ネットワーク700は、関与デバイス間のやりとりを容易にするネットワークである。図示された例示的なネットワーク700はインターネットであるが、他の実現化例では、ネットワーク700は、データセンター内のローカルネットワーク、ネットワークファブリック、もしくは任意の他のローカルエリアまたはワイドエリアネットワーク、といった別のネットワークであってもよい。ネットワーク700は、複数の接続されたサブネットワークまたは自律的ネットワークからなっていてもよい。ネットワーク700は、企業イントラネットなどのローカルエリアネットワーク(local-area network:LAN)、メトロポリタンエリアネットワーク(metropolitan area network:MAN)、ワイドエリアネットワーク(wide area network:WAN)、インターネットなどのインターネットワーク、または、ピアツーピアネットワーク、たとえばアドホックWiFiピアツーピアネットワークであってもよい。任意のタイプおよび/または形のデータネットワークおよび/または通信ネットワークを、ネットワーク700のために使用することができる。それは、公的ネットワーク、私的ネットワーク、または公的ネットワークと私的ネットワークとの組合せであってもよい。一般に、ネットワーク700は、コンピューティングデバイス間、たとえばネットワークノード750間で情報を伝達するために使用され、データトラフィックシェーピングシステムのネットワークデバイス110は、その構成に従ってこの通信を容易にする。
図1を参照して、ネットワークデバイス110は、1つ以上の仮想マシンをホストするサーバである。ネットワークデバイス110は、データトラフィックシェーピングシステム160を含む。いくつかの実現化例では、ネットワークデバイス110は、メモリ112とネットワークカード168とを含む。ネットワークデバイス110は、データパケットを格納するためのパケットバッファ169を含み得る。いくつかの実現化例では、ネットワークデバイス110は、図9に示すようなコンピューティングシステム140の構成と同様の構成を有する。たとえば、メモリ112は、図9に示すようなメモリ144の構成と同様の構成を有し、ネットワークカード168は、図9に示すようなネットワークインターフェイス146またはネットワークインターフェイスコントローラ143の構成と同様の構成を有し得る。コンピューティングシステム140については、図9を参照して以下により詳細に説明する。図9に示すコンピューティングシステム140に示された要素のすべてが、図1に示すネットワークデバイス110のいくつかの実現化例に存在する必要はない。いくつかの実現化例では、ネットワークデバイス110は、ソフトウェアキュー、またはエミュレートされたネットワークデバイス、またはネットワークインターフェイスとして作用するソフトウェアであってもよい。
図1を再び参照して、いくつかの実現化例では、データトラフィックシェーピングシステム160は、1つ以上のアプリケーション150(たとえば、アプリケーション150A、150B、および150C)と通信する。アプリケーション150A〜150Cのうちの1つ以上は、ネットワークデバイス110の実オペレーティングシステム上で作動するソフトウェアアプリケーションであってもよい。加えて、ソフトウェアアプリケーション150A〜150Cのうちの1つ以上は、仮想マシン環境でハイパーバイザによって管理されるゲストOS上で作動するソフトウェアアプリケーション、または、仮想マシン環境のゲストOSのプロトコルスタック(たとえばTCPスタック)の上位層であってもよい。たとえば、図2を参照して、アプリケーション150A〜150Cは各々、図2における、実OS220上で作動するソフトウェアアプリケーション230、ハイパーバイザ250によって管理されるゲストOS260上で作動するソフトウェアアプリケーション265、またはゲストOS260のプロトコルスタック261の上位層であってもよい。ハイパーバイザ250およびそれに関する仮想マシン環境については、図2を参照して以下により詳細に説明する。
図1を依然として参照して、いくつかの実現化例では、ネットワークデバイス110は、ネットワークインターフェイスドライバ164とデータトラフィックシェーピングモジュール166とを含む。ネットワークインターフェイスドライバ164は、実OS上で作動するネットワークインターフェイスドライバモジュールであってもよい。ネットワークインターフェイスドライバ164は、ソフトウェアアプリケーション150A〜150Cのうちの1つ(たとえば、図2のアプリケーション265)と、(ネットワークデバイス110の実OS上で動作する場合には)直接、(仮想マシン環境で動作する場合には)仮想マシンのゲストOSを介して、または、いくつかの実現化例ではハイパーバイザおよびゲストOSを通して、通信することができる。いくつかの実現化例では、ネットワークインターフェイスドライバ164は、ネットワークデバイス110の実OSの伝送制御プロトコル(transmission control protocol:TCP)スタックの第1の層内に含まれており、TCPスタックの上位層に含まれるソフトウェアモジュールまたはアプリケーションと通信する。一例では、ネットワークインターフェイスドライバ164は、TCPスタックのトランスポート層内に含まれており、TCPスタックのアプリケーション層に含まれるソフトウェアモジュールまたはアプリケーションと通信する。別の例では、ネットワークインターフェイスドライバ164は、TCPスタックのリンク層内に含まれており、TCPスタックのインターネット/トランスポート層に含まれるTCP/IPモジュールと通信する。
図1を再び参照して、いくつかの実現化例では、データトラフィックシェーピングモジュール166は、実OS上で作動するネットワークインターフェイスドライバモジュールの一部として実現可能である。いくつかの実現化例では、データトラフィックシェーピングモジュール166は、ネットワークカード168の一部として含まれ得る。
図1を参照して、いくつかの実現化例では、パケットバッファ169は、ネットワークデバイス110の共有メモリに位置することができ、そのため、アプリケーション150、ネットワークカード168、ネットワークインターフェイスドライバ164、およびデータトラフィックシェーピングモジュール166のうちのいくつかまたはすべてが、パケットバッファ169に直接的にまたは間接的にアクセスできる。たとえば、パケットバッファ169は、ゲストOS、実OS、ネットワークインターフェイスドライバ164、およびネットワークカード168によってアクセス可能な共有メモリに位置することができる。ネットワークを通してパケットを送信するために、ネットワークカード168への送信に先立って、データパケットをパケットバッファ169に格納することができ、そこでそれは、ネットワークインターフェイスドライバ164およびネットワークカード168によってアクセスされ得る。
図2は、仮想マシン環境を実現する例示的なサーバ200のブロック図を示す。いくつかの実現化例では、サーバ200は、ハードウェア210と、ハードウェア210上で作動する実オペレーティングシステム(operating system:OS)220と、ハイパーバイザ250と、ゲストオペレーティングシステム(ゲストOS)260および270を有する2つの仮想マシンとを含む。ハードウェア210は、他のコンポーネントの中でも、ネットワークインターフェイスカード(network interface card:NIC)215を含み得る。ハードウェア210は、図9に示すようなコンピューティングシステム140の構成と同様の構成を有し得る。ハードウェア210のNIC215は、図9に示すようなネットワークインターフェイスコントローラ143またはネットワークインターフェイス146の構成と同様の構成を有し得る。いくつかの実現化例では、実OS220は、プロトコルスタック225(たとえばTCPスタック)を有し、実OS220上で作動するソフトウェアアプリケーションを有する。いくつかの実現化例では、ゲストOS260および270は、プロトコルスタック261および271をそれぞれ有する。ゲストOS260および270の各々は、さまざまなアプリケーション、たとえばソフトウェアアプリケーション265、266、275および276をホストすることができる。サーバ200は、ファイルサーバ、アプリケーションサーバ、ウェブサーバ、プロキシサーバ、アプライアンス、ネットワークアプライアンス、ゲートウェイ、ゲートウェイサーバ、仮想化サーバ、デプロイメントサーバ、SSL VPNサーバ、またはファイアウォールであってもよい。
図2を再び参照して、サーバ200はハイパーバイザ250を実行し、それは、第1のゲストOS260および第2のゲストOS270をインスタンス化して管理する。第1のゲストOS260は、第1のソフトウェアアプリケーション265および第2のソフトウェアアプリケーション266をホストする。第2のゲストOS270は、第3のソフトウェアアプリケーション275および第4のソフトウェアアプリケーション276をホストする。たとえば、アプリケーションは、データベースサーバ、データウェアハウジングプログラム、株式市場トランザクションソフトウェア、オンラインバンキングアプリケーション、コンテンツ発行および管理システム、ホストされたビデオゲーム、ホストされたデスクトップ、電子メールサーバ、旅行予約システム、顧客関係管理アプリケーション、在庫制御管理データベース、および企業リソース管理システムを含み得る。いくつかの実現化例では、ゲストOSは、他の種類のアプリケーションをホストする。サーバ200のコンポーネント間のやりとりを、図3〜6に関連して以下にさらに説明する。
図3は、図1に示すネットワークインターフェイスドライバ164といったネットワークインターフェイスドライバによって行なわれる例示的な方法300を使用して、ネットワークトラフィックをシェーピングするためのフローチャートである。広範な概観では、方法300はステージ310で始まり、そこで、ネットワークインターフェイスドライバは、アプリケーションによって生成され発送された第1の組のデータパケットを、図1に示すネットワークカード168といったネットワークカードによる送信のために受信することができる。ステージ320で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子を一次送信キューに格納することができる。ステージ330で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子を、図1に示すデータトラフィックシェーピングモジュール166といったデータトラフィックシェーピングモジュールに転送することができる。
ここで、図3のフローチャートを、いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である図6Aおよび図6Bを参照して、より詳細に説明する。
ステージ310で、ネットワークインターフェイスドライバは、アプリケーションによって生成され発送された第1の組のデータパケットを、ネットワークカードによる送信のために受信することができる。たとえば、図6Aを参照して、ネットワークインターフェイスドライバ164は、一組のアプリケーション150A〜150Cのうちの1つによって生成され発送された一組のデータパケットを、ネットワークカード168による送信のために受信する。いくつかの実現化例では、一組のデータパケットの受信に応答して、ネットワークインターフェイスドライバ164は、受信された一組のデータパケットをパケットバッファ(たとえば、図1および図6A〜6Dのパケットバッファ169)に格納する。たとえば、パケットバッファ169は、共有リソースとして、ゲストOSとネットワークインターフェイスドライバ164との間の共有メモリに位置することができ、そのため、ゲストOS上で作動するアプリケーション150から送信されたパケットをパケットバッファ169に格納することができ、それらのパケットに関連付けられた記述子は、共有リソース内の位置を指し示す。いくつかの実現化例では、パケットバッファ内のある特定のパケットへのポインタ(たとえばメモリアドレス)を含む記述子が、その特定のパケットに関連付けられる。いくつかの実現化例では、記述子は概して小さく(たとえば、32バイトであるか、または数個の64ビット整数を含む)、扱いが簡単であり、一方、パケットは概して最小でも数百バイトであり、しばしば1500バイトである。
いくつかの実現化例では、データパケットは、ストリームの一部であってもよい。アプリケーション150は、各ストリームにおけるデータパケットを特定の順序で送信できる。各ストリームは、異なるアプリケーション(たとえば、異なるゲストOS上で実行されるアプリケーション)から来ることができる。図6Aに示す例では、アプリケーション150Aは、記述子S1、S2およびS3に対応する第1のストリームの3つのパケットを順次送信する。アプリケーション150Bは、記述子T1、T2およびT3に対応する第2のストリームの3つのパケットを順次送信する。アプリケーション150Cは、記述子U1およびU2に対応する第3のストリームの2つのパケットを送信する。
ステージ320で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子を一次送信キュー161に格納することができる。図6A〜6Dを参照して、ネットワークデバイス110は、アプリケーション150から受信されたデータパケットに関連付けられた記述子を含むための一次送信キュー161を含む。いくつかの実現化例では、一次送信キュー161は、単一のキューである。いくつかの実現化例では、一次送信キュー161は、ハードウェアキュー(たとえば、専用ハードウェアで実現されたキュー)、またはソフトウェアキューであってもよい。いくつかの実現化例では、一次送信キュー161は、一組の一次送信キューである。たとえば、一次送信キュー161は、マルチキューNICで実現された複数のキューである。いくつかの実現化例では、一組の一次送信キューの数は、速度リミッタ(たとえば、トラフィックシェーピングキュー)の数よりも少ない。たとえば、何千ものフローまたはストリームをシェーピングするために、ネットワークデバイス110は約10〜約32個のハードウェアキューを有していてもよく、一方、その何千ものフローをシェーピングするためにそこに設置されたより多くのトラフィックシェーピングキューを有していてもよい。アプリケーション150からのデータパケットの受信に応答して、ネットワークインターフェイスドライバ164は、データパケットに関連付けられた記述子を、単一のキュー、たとえば一次送信キュー161に書込む。いくつかの実現化例では、ネットワークインターフェイスドライバ164は、各ストリームにおけるデータパケットに関連付けられた記述子を、パケットがアプリケーション150によって送信された順序で一次送信キュー161に書込む。たとえば、図6Aに示すように、ネットワークインターフェイスドライバ164は、アプリケーション150から8つのデータパケットを受信し、それらのパケットに関連付けられた記述子(たとえば、記述子T1、U1、T2、S1、U2、S2、S3、T3)を、ネットワークカード168を介したそれらのパケットの送信のために一次送信キュー161に書込む。いくつかの実現化例では、アプリケーション150からのデータパケットの受信に応答して、ネットワークインターフェイスドライバ164は、(受信されたパケットに関連付けられた記述子を格納する代わりに)受信されたパケットを単一の送信キューに書込むことができる。
ネットワークインターフェイスドライバ164は、アプリケーション150Aから第1のストリームのパケットを受信し、記述子S1、S2およびS3を、それらが送信された順序で、すなわち、S1、次にS2、次にS3という順序で一次送信キュー161に書込む。同様に、ネットワークインターフェイスドライバ164は、アプリケーション150Bから第2のストリームのパケットを受信し、記述子T1、T2およびT3を、それらが受信された順序で一次送信キュー161に書込み、ネットワークインターフェイスドライバ164は、アプリケーション150Cから第3のストリームのパケットを受信し、記述子U1およびU2を一次送信キュー161に書込む。いくつかの実現化例では、一次送信キューにおいて、各ストリームにおけるパケットの受信順序を維持しながら、異なるストリームのパケットをインタリーブすることができる。たとえば、図6Aに示す例では、一次送信キューにおいて、各ストリームのパケットの受信順序を維持しながら(たとえば、第1のストリームについてはS1→S2→S3という順序、第2のストリームについてはT1→T2→T3という順序、および第3のストリームについてはU1→U2という順序を維持しながら)、異なるストリームのパケットが(すなわち、T1、U1、T2、S1、U2、S2、S3、およびT3という順序で)インタリーブされている。
ステージ330で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子を、データトラフィックシェーピングモジュールに転送することができる。たとえば、図6Bを参照して、いくつかの実現化例では、ネットワークインターフェイスドライバ164は、受信されたデータパケットに関連付けられた記述子(たとえば、T1、U1、T2、S1、U2、S2、S3、およびT3)を、データトラフィックシェーピングモジュール166に転送する。
図4は、図1および図6A〜6Dに示すデータトラフィックシェーピングモジュール166といったデータトラフィックシェーピングモジュールによって行なわれる例示的な方法400を使用して、ネットワークトラフィックをシェーピングするためのフローチャートである。広範な概観では、方法400はステージ410で始まり、そこで、データトラフィックシェーピングモジュールは、複数のトラフィックシェーピングキューを維持し、一次送信キューから、図1および図6A〜6Dに示すネットワークインターフェイスドライバ164といったネットワークインターフェイスドライバによって転送されたデータパケットの記述子を受信する。ステージ420で、データトラフィックシェーピングモジュールは、受信された記述子に関連付けられたデータパケットを分類する。ステージ430で、データトラフィックシェーピングモジュールは、受信された第1の記述子に関連付けられた第1のデータパケットの、図1および図6A〜6Dに示すネットワークカード168といったネットワークカードによる送信が遅延されるべきか判断する。ステージ440で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきであると判断すると、データトラフィックシェーピングモジュールは、第1のデータパケットに関連付けられた第1の記述子を一次送信キューから除去し、分類の結果に基づいて第1の記述子を対応するトラフィックシェーピングキューに格納する。次に、ステージ450で、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させる。ステージ460で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきではないと判断すると、データトラフィックシェーピングモジュールは、ネットワークカードに、第1のデータパケットをすぐに送信させる。ステージ470で、データトラフィックシェーピングモジュールは、ネットワークインターフェイスドライバに、データパケットの順調な送信を通知する。なお、ここに使用されるように、データパケットの順調な送信は必ずしも、受信側によるデータパケットの順調な受信を必要としない。すなわち、パケット受信の受領確認(たとえばTCP ACKメッセージ)の受信は、パケットが順調に送信されたとネットワークインターフェイスカードが判断するための必要条件ではない。
ここで、図4のフローチャートを、いくつかの実現化例に従ったデータトラフィックシェーピングシステムの例示的な動作を表わすブロック図である図6A〜6Dを参照して、より詳細に説明する。
上述のように、ステージ410で、データトラフィックシェーピングモジュールは、複数のトラフィックシェーピングキューを維持し、一次送信キューから、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を受信する。たとえば、図6A〜6Dを参照して、データトラフィックシェーピングモジュール166は、複数のトラフィックシェーピングキュー(たとえば、トラフィックシェーピングキュー162、163および165)を維持する。いくつかの実現化例では、各トラフィックシェーピングキューは、トラフィックシェーピングキューによって管理されるべきパケットの格納のための対応するパケットバッファ(図示せず)を維持することができる。いくつかの実現化例では、トラフィックシェーピングキューのうちの少なくともいくつかは、パケットバッファ169へのアクセスを共有し、このため、それら自体の別個のパケットバッファを有する必要はない。図6Aおよび図6Bを参照して、ネットワークインターフェイスドライバ164が、受信されたデータパケットに関連付けられた記述子(たとえば、T1、U1、T2、S1、U2、S2、S3、およびT3)をデータトラフィックシェーピングモジュール166に転送することに応答して、データトラフィックシェーピングモジュール166は、一次送信キュー161から、データパケットの転送された記述子を受信する。
ステージ420で、データトラフィックシェーピングモジュールは、受信された記述子に関連付けられたデータパケットを分類する。いくつかの実現化例では、たとえば図6Bに示すように、データトラフィックシェーピングモジュール166は、各ストリームの特性を対応するトラフィックシェーピングキューにマッピングするための一組の分類規則に基づいて、受信された記述子に関連付けられたデータパケットを分類する。たとえば、トラフィックシェーピングモジュールは、ソースおよび宛先IPアドレス、ソースおよび宛先ポート番号のうちの4つまたは5つ、ならびにタイプ・オブ・サービス・インジケータを含む、パケットヘッダにおける4タプルまたは5タプルのデータに基づいて、パケットを分類することができる。いくつかの実現化例では、パケットは、より少ないデータフィールドのヘッダを使用して、より広範に分類され得る。たとえば、いくつかの実現化例では、パケットは、(使用されているプロトコルおよびプロトコルバージョンに依存して)タイプ・オブ・サービス(type of service:ToS)またはクオリティ・オブ・サービス(quality of service:QoS)フィールドといった単一データフィールド、ファイルタイプフィールド、またはポート番号に基づいて分類されてもよく、それらの各々はしばしば、優先レベルと相関され得る。パケットの関連する特性を識別した後で、データトラフィックシェーピングモジュール166は、識別された特性を分類規則と比較し、分類規則が満たされたトラフィックシェーピングキューにパケットを割当てる。いくつかの実現化例では、トラフィックシェーピングモジュール166は、他のトラフィックシェーピングキューに割当てられないすべてのパケットを、それらの特定の特性に基づいて扱うための、「包括的」トラフィックシェーピングキューを維持する。
いくつかの実現化例では、各トラフィックシェーピングキューは、少なくとも1つの関連付けられた送信速度規則を有する。ある特定のトラフィックシェーピングキューについての送信速度規則は、その特定のトラフィックシェーピングキューに格納されたパケットをネットワークカードによって送信するためのフロー速度限界を特定することができる。図6A〜6Dを参照して、データトラフィックシェーピングモジュール166は、ネットワークカード168に、その特定のトラフィックシェーピングキューに格納されたパケットを、そのキューについての送信速度規則に従って送信させる。いくつかの実現化例では、送信速度規則は、絶対的であってもよく、または条件付きであってもよい。同様に、送信速度規則は、パケットの数またはデータの量に基づいていてもよい。いくつかの例示的な絶対的送信速度規則は、1)無制限の送信、2)1秒あたり送信されるパケットの最大数、3)1秒あたり送信されるパケットの平均数、4)1秒あたり送信される最大ビット、または5)1秒あたり送信される平均ビットを含む。いくつかの実現化例では、送信速度規則は、上述のタイプの規則のうちのいずれかの組合せを含み得る。たとえば、送信速度規則は、トラフィックのバースト性を可能にし、および/またはそれに対処するように、1秒あたりの平均許容ビットまたはパケットを、1秒あたりのビットまたはパケットの最大数とともに特定してもよい。条件付き送信速度規則は、異なる状況における異なる絶対的送信速度規則を可能にする。たとえば、条件付き送信速度規則は、異なるトラフィックシェーピングキューが一杯である場合よりも、その異なるトラフィックシェーピングキューが空である状況で、1つの送信速度を許容してもよい。別の条件付き送信規則は、たとえばキューがあいにく一杯になりつつある状況でパケットのより迅速な処理を可能にするために、キューにおけるパケットの数に依存して異なる送信速度を許容してもよい。上述の規則は、それぞれのトラフィックシェーピングキューの各々のために実現され得る広範囲の規則の例である。特定の規則は、たとえばシステムアドミニストレータによって設定され得る。
ステージ430で、データトラフィックシェーピングモジュールは、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきか判断することができる。あるパケットの送信は、その分類の結果、それが、未送信パケット(またはそれらの記述子)をすでに格納しているトラフィックシェーピングキューに割当てられた場合、遅延される。
ステージ440で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきであると判断すると、データトラフィックシェーピングモジュールは、第1のデータパケットに関連付けられた第1の記述子を一次送信キューから除去し、分類の結果に基づいて第1の記述子を対応するトラフィックシェーピングキューに格納する。たとえば、図6Aおよび図6Bを参照して、第2のストリームの記述子T1に関連付けられたデータパケットの、ネットワークカード168による送信が遅延されるべきであるという判断に応答して、データトラフィックシェーピングモジュール166は、記述子T1を一次送信キュー161から除去し、記述子T1をトラフィックシェーピングキュー165に格納する。同様に、データトラフィックシェーピングモジュール166は、第2のストリームの記述子T2およびT3を一次送信キュー161から除去し、記述子T2およびT3をトラフィックシェーピングキュー165に格納する。第1のストリームの記述子S1に関連付けられたデータパケットの、ネットワークカード168による送信が遅延されるべきであるという判断に応答して、データトラフィックシェーピングモジュール166は、記述子S1を一次送信キュー161から除去し、記述子S1をトラフィックシェーピングキュー163に格納する。同様に、データトラフィックシェーピングモジュール166は、第1のストリームの記述子S2およびS3を一次送信キュー161から除去し、記述子S2およびS3をトラフィックシェーピングキュー163に格納する。
遅延されるべきであると判断されたトラフィックストリームに関連付けられた記述子の、単一の送信キューからの除去は、「ライン先頭ブロッキング」と呼ばれるキューイング問題を解決することができる。先入れ先出し(FIFO)キューの先頭のパケットの送信が遅延されるものの、送信キューに残っている場合、そのパケットは、キューにおいてその後ろに格納された記述子に関連付けられた他のすべてのパケット(さもなければ、トラフィックシェーピングモジュールによって実現されたトラフィックシェーピング規則に基づいて遅延されなかったであろうパケットを含む)の処理をブロックし、「ライン先頭ブロッキング」問題を引き起こすであろう。対照的に、トラフィックシェーピング規則に基づいて送信が遅延されるべきであると判断されたデータパケットについては、データトラフィックシェーピングモジュール166は、パケットに関連付けられた記述子を送信キューの先頭から転送することができる。この除去は、キューに格納された記述子に関連付けられた他のパケットの継続的な処理を可能にすることができ、それにより、「先頭ラインブロッキング」問題を解決する。さらに、送信キューからの記述子の除去に応答して、データトラフィックシェーピングモジュール166は、記述子を対応するトラフィックシェーピングキューに移動させることができ、それにより、記述子またはその対応するパケットを破棄することなく、パケットの遅延された送信を可能にする。
図6Bを再び参照して、いくつかの実現化例では、データトラフィックシェーピングモジュール166が、第1のストリームにおけるデータパケット(たとえば、記述子S1に対応するデータパケット)の、ネットワークカード168による送信が遅延されるべきであると判断すると、データトラフィックシェーピングモジュール166は、第1のストリームにおけるデータパケットに関連付けられた記述子を、第1のトラフィックシェーピングキュー(たとえば、トラフィックシェーピングキュー163)に格納する。データトラフィックシェーピングモジュール166が、第1のストリームとは異なる第2のストリームにおけるデータパケット(たとえば、記述子T1に対応するデータパケット)の、ネットワークカードによる送信が遅延されるべきであると判断すると、データトラフィックシェーピングモジュール166は、第2のストリームにおけるデータパケットに関連付けられた記述子を、第2のトラフィックシェーピングキュー(たとえば、トラフィックシェーピングキュー165)に格納する。いくつかの実現化例では、異なるストリームに関連付けられたパケットが、同じトラフィックシェーピングキューに転送されてもよい。すなわち、トラフィックシェーピングモジュール166は、トラフィックシェーピングモジュール166が扱うストリームの数よりも少ない、多くの場合はるかに少ないトラフィックシェーピングキューを維持することができる。
ステージ450で、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させる。たとえば、図6B〜6Dを参照して、データトラフィックシェーピングモジュール166は、ネットワークカード168に、トラフィックシェーピングキュー163に格納された記述子S1、S2およびS3に関連付けられたデータパケットを、トラフィックシェーピングキュー163に関連付けられた送信速度規則に従って、遅延された態様で送信させる。データトラフィックシェーピングモジュール166はまた、ネットワークカード168に、トラフィックシェーピングキュー165に格納された記述子T1、T2およびT3に関連付けられたデータパケットを、トラフィックシェーピングキュー165に関連付けられた送信速度規則に従って、遅延された態様で送信させる。
ステージ460で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきではないと判断すると、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットをすぐに送信させることができる。たとえば、あるデータパケットが、それが無制限の送信速度を可能にする送信速度規則を有するトラフィックシェーピングキューに割当てられるように分類され、かつそのキューが空である場合、そのデータパケットは遅延なくすぐに送信されてもよい。図6A〜6Dに示す例では、記述子U1およびU2に関連付けられたパケットが、そのようなものとして扱われる。同様に、あるパケットが、空であり、かつその対応する送信速度規則で識別された送信速度を上回らなかったトラフィックシェーピングキューに分類された場合、そのパケットはすぐに送信されてもよい。
いくつかの実現化例では、ネットワークカード168は、リソースを使用することによってデータパケットを送信する。いくつかの実現化例では、リソースは、アプリケーション150、ネットワークインターフェイスドライバ164、およびネットワークカード168のうちのいくつかまたはすべてによって共有されるメモリバッファ(たとえば、図1および図6A〜6Dのパケットバッファ169)である。たとえば、ネットワークカード168は、(共有メモリにおける)パケットバッファ169におけるデータパケットのアドレスを、データパケットに関連付けられた記述子を使用して識別し、次に、パケットバッファ169からデータパケットを送信する。いくつかの実現化例では、パケットバッファ169を使用してデータパケットを送信することに応答して、ネットワークカード168は、パケットバッファが、送信されたパケットを格納するために使用されるメモリ空間を、その空間が新規パケットを格納するために使用できるように解放するようにすることができる。
ステージ470で、データトラフィックシェーピングモジュールは、ネットワークインターフェイスドライバに、データパケットの順調な送信を通知することができる。たとえば、図6Cを参照して、記述子U1およびU2に関連付けられたデータパケットの、ネットワークカード168を介した(即時)送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、データパケットの順調な送信を通知する。いくつかの実現化例では、データトラフィックシェーピングモジュール166は、記述子U1およびU2に関連付けられたデータパケットの順調な送信を示す、ネットワークカード168によって生成された単一のメッセージを、ネットワークインターフェイスドライバ164に発送することによって、ネットワークインターフェイスドライバ164にデータパケットの順調な送信を通知することができる。いくつかの実現化例では、データトラフィックシェーピングモジュール166は、パケット毎に別々の送信完了メッセージをネットワークインターフェイスドライバ164に発送することによって、ネットワークインターフェイスドライバ164に、記述子U1およびU2に関連付けられたデータパケットの各々の順調な送信を別々に通知することができる。
遅延された送信のために、同様の通信を生成し発送することができる。たとえば、図6Dを参照して、記述子T1、S1、T2、S2、T3およびS3に関連付けられたデータパケットの、ネットワークカード168を介した(遅延)送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、データパケットの順調な送信を通知する。いくつかの実現化例では、データトラフィックシェーピングモジュール166は、複数のデータパケットの順調な送信を示す、ネットワークカード168によって生成された単一のメッセージを、ネットワークインターフェイスドライバ164に発送することによって、ネットワークインターフェイスドライバ164にデータパケットの順調な送信を通知することができる。いくつかの実現化例では、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、個々のデータパケットの順調な送信を別々に通知することができる。
図5は、ネットワークインターフェイスドライバによって行なわれる例示的な方法500を使用して、ネットワークトラフィックをシェーピングするためのフローチャートである。広範な概観では、方法500はステージ510で始まり、そこで、図1および図6A〜6Dに示すネットワークインターフェイスドライバ164といったネットワークインターフェイスドライバが、受信された第1の組のパケットのうちの1つのパケットが、ネットワークカード168といったネットワークカードによって順調に送信されたか判断する。ステージ520で、ネットワークインターフェイスドライバが、第1の組の受信されたパケットのうちの1つのパケットが順調に送信されたと判断すると、ネットワークインターフェイスドライバは、パケット送信完了メッセージをアプリケーションに通信し、アプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。
図5のフローチャートに示す方法を、図6A〜6Dを参照して以下により詳細に説明する。
図5をより詳細に参照して、ステージ510で、ネットワークインターフェイスドライバは、受信された第1の組のパケットのうちの1つのパケットが、ネットワークカードによって順調に送信されたか判断する。たとえば、図6Cを参照して、記述子U1およびU2に関連付けられたデータパケットの、ネットワークカード168による送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、単一のメッセージまたは複数のメッセージを通信することによって、ネットワークインターフェイスドライバ164にデータパケットの順調な送信を通知する。データトラフィックシェーピングモジュール166からのデータパケットの順調な送信の通知に基づいて、ネットワークインターフェイスドライバ164は、受信されたパケットのうちの各パケットがネットワークカード168によって順調に送信されたと判断する。
ステージ520で、ネットワークインターフェイスドライバが、受信された第1の組のパケットのうちの1つのパケットが順調に送信されたと判断することに応答して、ネットワークインターフェイスドライバは、パケット送信完了メッセージをアプリケーションに通信し、アプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。たとえば、図6Cを参照して、元々アプリケーション150Cから送信された第3のストリームの記述子U1に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子U1に対応するパケット送信完了メッセージ167(たとえば、図6CのM−U1)をアプリケーション150Cに通信する。同様に、元々アプリケーション150Cから送信された第3のストリームの記述子U2に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子U2に対応するパケット送信完了メッセージ167(たとえば、図6CのM−U2)をアプリケーション150Cに通信する。いくつかの実現化例では、送信メッセージ167は小さくてもよい(たとえば、32バイトであるか、または数個の64ビット整数を含む)。いくつかの実現化例では、記述子U1およびU2に関連付けられたデータパケットの順調な送信を示す単一のメッセージ(図示せず)をデータトラフィックシェーピングモジュール166から受信することに応答して、ネットワークインターフェイスドライバ164は、2つの別々の送信完了メッセージ(たとえば、図6CのM−U1およびM−U2)を生成し、各メッセージを、対応するパケットソース、たとえばアプリケーション150Cに、データパケットの順調な送信の順序で通信する。いくつかの実現化例では、記述子U1およびU2に関連付けられたデータパケットの各々の順調な送信を示すメッセージ(図示せず)をデータトラフィックシェーピングモジュール166から受信することに応答して、ネットワークインターフェイスドライバ164は、受信されたメッセージを、送信完了メッセージとして、対応するパケットソース、たとえばアプリケーション150Cに発送することができる。
図6Dを参照して、元々アプリケーション150Bから送信された第2のストリームの記述子T1に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子T1に対応するパケット送信完了メッセージ167(たとえば、図6DのM−T1)をアプリケーション150Bに通信する。同様に、元々アプリケーション150Aから送信された第1のストリームの記述子S1に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子S1に対応するパケット送信完了メッセージ167(たとえば、図6DのM−S1)をアプリケーション150Bに通信する。いくつかの実現化例では、記述子T1、S1、T2、S2、T3およびS3に関連付けられたデータパケットの順調な送信を示す単一のメッセージ(図示せず)をデータトラフィックシェーピングモジュール166から受信することに応答して、ネットワークインターフェイスドライバ164は、6つの別々の送信完了メッセージ(たとえば、図6CのM−T1、M−S1、M−T2、M−S2、M−T3およびM−S3)を生成し、各メッセージを、対応するパケットソース(たとえば、第1のストリームの記述子T1、T2、T3についてはアプリケーション150A、第2のストリームの記述子S1、S2、S3についてはアプリケーション150B)に、データパケットの順調な送信の順序で(たとえば、T1、S1、T2、S2、T3およびS3という順序で)通信する。または、各メッセージがデータトラフィックシェーピングモジュール166から受信されると、各ソースへの1つだけのメッセージ(たとえば、アプリケーション150Aへの1つのメッセージ、およびアプリケーション150Bへの1つのメッセージ)を送信することができ、各メッセージは、複数の順調に送信されたパケットを識別する。
いくつかの実現化例では、アプリケーション150の各々は、ネットワークインターフェイスドライバ164からのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバ164に発送するように構成可能である。いくつかの実現化例では、アプリケーション150の各々は、ネットワークインターフェイスドライバ164からの、ある特定のストリームのデータパケットについての送信完了メッセージの受信を待ってから、同じストリームの追加のデータパケットをネットワークインターフェイスドライバ164に発送するように構成可能である。たとえば、図6Cに示すように、アプリケーション150Cは、ネットワークインターフェイスドライバ164からの、記述子U1に対応する第3のストリームのデータパケットについての送信完了メッセージの受信を待つ。図6Dを参照して、アプリケーション150Cが記述子U1に対応する送信完了メッセージを受信することに応答して、アプリケーション150Cは、同じ第3のストリームの追加のデータパケット(たとえば、図6Dに示すような記述子U3およびU4に対応するデータパケット)をネットワークインターフェイスドライバ164に発送する。このように、アプリケーション150Cは、同じストリームのパケットがネットワークカード168によって送信されたというパケット送信完了メッセージを受信したときだけ、追加のパケットをネットワークインターフェイスドライバ164に送信することによって、一次送信キューに、ストリーム毎に少数のパケット(たとえば、1つ、2つ、または3つのパケット)を維持することができる。いくつかの実現化例では、ある特定のストリームの記述子に対応する送信完了メッセージを受信することに応答して、アプリケーションは、その特定のストリームとは異なるストリームの追加のデータパケットをネットワークインターフェイスドライバ164に発送することができる。
図3〜5のフローチャートに示す方法を、いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である図7A〜7Dを参照して以下にさらに説明する。図7A〜7Dでは、図6A〜6Dと同じ参照番号が使用されており、同じ説明は省略される。図7A〜7Dは、単一のアプリケーション150Dが異なるストリームまたはフローのパケット(たとえば、記述子V1、V2、V3に対応する第4のストリームのパケット、および記述子W1、W2、W3に対応する第5のストリームのパケット)をネットワークインターフェイスドライバ164に送信する場合のデータトラフィックシェーピングシステムの動作を示す。
図3のステージ310で、ネットワークインターフェイスドライバは、アプリケーションによって生成され発送された第1の組のデータパケットを、ネットワークカードによる送信のために受信することができる。たとえば、図7Aを参照して、ネットワークインターフェイスドライバ164は、アプリケーション150Dによって生成され発送された一組のデータパケットを、ネットワークカード168による送信のために受信する。図7Aに示す例では、アプリケーション150Dは、記述子V1、V2およびV3に対応する第4のストリームの3つのパケットを順次送信する。同じアプリケーション150Dは、記述子W1、W2およびW3に対応する第5のストリームの3つのパケットを順次送信する。
図3のステージ320で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子を一次送信キュー161に格納することができる。いくつかの実現化例では、ネットワークインターフェイスドライバ164は、各ストリームからのデータパケットに関連付けられた記述子を、パケットがアプリケーション150Dによって送信された順序で一次送信キュー161に書込む。たとえば、図7Aに示すように、ネットワークインターフェイスドライバ164は、アプリケーション150Dから6つのデータパケットを受信し、それらのパケットに関連付けられた記述子(たとえば、記述子W1、W2、V1、V2、V3、W3)を、ネットワークカード168を介したそれらのパケットの送信のために一次送信キュー161に書込む。ネットワークインターフェイスドライバ164は、アプリケーション150Dから第4および第5のストリームのパケットを受信し、対応する記述子(たとえば、第4のストリームについてはV1、V2、V3、第5のストリームについてはW1、W2、W3)を、それらが送信された順序で、すなわち、W1、次にW2、次にV1、次にV2、次にV3、次にW3という順序で一次送信キュー161に書込む。いくつかの実現化例では、一次送信キューにおいて、各ストリームにおけるパケットの受信順序を維持しながら、異なるストリームのパケットをインタリーブすることができる。たとえば、図7Aに示す例では、一次送信キューにおいて、各ストリームのパケットの受信順序を維持しながら(たとえば、第4のストリームについてはV1→V2→V3という順序、第5のストリームについてはW1→W2→W3という順序を維持しながら)、異なるストリームのパケットが(すなわち、W1、W2、V1、V2、V3、W3という順序で)インタリーブされている。
図3のステージ330で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子(たとえば、W1、W2、V1、V2、V3、W3)を、データトラフィックシェーピングモジュール166に転送することができる。
図4を参照して、ステージ410で、データトラフィックシェーピングモジュールは、複数のトラフィックシェーピングキューを維持し、一次送信キューから、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を受信する。図7Aおよび図7Bを参照して、ネットワークインターフェイスドライバ164が、受信されたデータパケットに関連付けられた記述子(たとえば、W1、W2、V1、V2、V3、およびW3)をデータトラフィックシェーピングモジュール166に転送することに応答して、データトラフィックシェーピングモジュール166は、一次送信キュー161から、データパケットの転送された記述子を受信する。
図4のステージ420で、データトラフィックシェーピングモジュールは、受信された記述子に関連付けられたデータパケットを分類する。いくつかの実現化例では、たとえば図7Bに示すように、データトラフィックシェーピングモジュール166は、各ストリームの特性を対応するトラフィックシェーピングキューにマッピングするための一組の分類規則に基づいて、受信された記述子に関連付けられたデータパケットを分類する。
図4のステージ430で、データトラフィックシェーピングモジュールは、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきか判断することができる。あるパケットの送信は、その分類の結果、それが、未送信パケット(またはそれらの記述子)をすでに格納しているトラフィックシェーピングキューに割当てられた場合、遅延される。
図4のステージ440で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきであると判断すると、データトラフィックシェーピングモジュールは、第1のデータパケットに関連付けられた第1の記述子を一次送信キューから除去し、分類の結果に基づいて第1の記述子を対応するトラフィックシェーピングキューに格納する。たとえば、図7Aおよび図7Bを参照して、第5のストリームの記述子W1およびW2に関連付けられたデータパケットの、ネットワークカード168による送信が遅延されるべきであるという判断に応答して、データトラフィックシェーピングモジュール166は、記述子W1およびW2を一次送信キュー161から除去し、記述子W1およびW2をトラフィックシェーピングキュー163に格納する。
図4のステージ450で、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させる。たとえば、図7B〜7Dを参照して、データトラフィックシェーピングモジュール166は、ネットワークカード168に、トラフィックシェーピングキュー163に格納された記述子W1、W2およびW3に関連付けられたデータパケットを、トラフィックシェーピングキュー163に関連付けられた送信速度規則に従って、遅延された態様で送信させる。
図4のステージ460で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきではないと判断すると、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットをすぐに送信させることができる。たとえば、あるデータパケットが、それが無制限の送信速度を可能にする送信速度規則を有するトラフィックシェーピングキューに割当てられるように分類され、かつそのキューが空である場合、そのデータパケットは遅延なくすぐに送信されてもよい。図7A〜7Dに示す例では、記述子V1、V2およびV3に関連付けられたパケットが、そのようなものとして扱われる。
図4のステージ470で、データトラフィックシェーピングモジュールは、ネットワークインターフェイスドライバに、データパケットの順調な送信を通知することができる。たとえば、図7Cを参照して、記述子V1、V2およびV3に関連付けられたデータパケットの、ネットワークカード168を介した(即時)送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、データパケットの順調な送信を通知する。いくつかの実現化例では、図7Cに示すように、データトラフィックシェーピングモジュール166は、パケット毎に別々の送信完了メッセージをネットワークインターフェイスドライバ164に発送することによって、ネットワークインターフェイスドライバ164に、記述子V1、V2およびV3に関連付けられたデータパケットの各々の順調な送信を別々に通知することができる。
遅延された送信のために、同様の通信を生成し発送することができる。たとえば、図7Dを参照して、記述子W1、W2およびW3に関連付けられたデータパケットの、ネットワークカード168を介した(遅延)送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、データパケットの順調な送信を通知する。
図5のステージ510で、ネットワークインターフェイスドライバは、受信された第1の組のパケットのうちの1つのパケットが、ネットワークカードによって順調に送信されたか判断する。たとえば、図7Cを参照して、記述子V1、V2およびV3に関連付けられたデータパケットの、ネットワークカード168による送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、単一のメッセージまたは複数のメッセージを通信することによって、ネットワークインターフェイスドライバ164にデータパケットの順調な送信を通知する。データトラフィックシェーピングモジュール166からのデータパケットの順調な送信の通知に基づいて、ネットワークインターフェイスドライバ164は、受信されたパケットのうちの各パケットがネットワークカード168によって順調に送信されたと判断する。
図5のステージ520で、ネットワークインターフェイスドライバが、受信された第1の組のパケットのうちの1つのパケットが順調に送信されたと判断することに応答して、ネットワークインターフェイスドライバは、パケット送信完了メッセージをアプリケーションに通信し、アプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。たとえば、図7Cを参照して、元々アプリケーション150Dから送信された第4のストリームの記述子V1に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子V1に対応するパケット送信完了メッセージ167(たとえば、図7CのM−V1)をアプリケーション150Dに通信する。同様に、元々アプリケーション150Dから送信された第4のストリームの記述子V2およびV3に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子V2およびV3に対応する2つのパケット送信完了メッセージ167(たとえば、図7CのM−V2およびM−V3)をアプリケーション150Dに通信する。いくつかの実現化例では、アプリケーション150Dは、ネットワークインターフェイスドライバ164からのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバ164に発送するように構成可能である。いくつかの実現化例では、アプリケーション150Dは、ネットワークインターフェイスドライバ164からの、ある特定のストリームのデータパケットについての送信完了メッセージの受信を待ってから、同じストリームの追加のデータパケットをネットワークインターフェイスドライバ164に発送するように構成可能である。たとえば、図7Cに示すように、アプリケーション150Dは、ネットワークインターフェイスドライバ164からの、記述子V1に対応する第4のストリームのデータパケットについての送信完了メッセージの受信を待つ。図7Dを参照して、アプリケーション150Dが記述子V1に対応する送信完了メッセージを受信することに応答して、アプリケーション150Dは、同じ第4のストリームの追加のデータパケット(たとえば、図7Dに示すような記述子V4およびV5に対応するデータパケット)をネットワークインターフェイスドライバ164に発送する。このように、アプリケーション150Dは、同じストリームのパケットがネットワークカード168によって送信されたというパケット送信完了メッセージを受信したときだけ、追加のパケットをネットワークインターフェイスドライバ164に送信することによって、一次送信キューに、ストリーム毎に少数のパケット(たとえば、1つ、2つ、または3つのパケット)を維持することができる。
図7A〜7Dを参照して、一般に、ネットワークトラフィックは、複数のフローまたはストリームに属する(たとえば、記述子V1、V2、V3に対応する第4のストリームのパケット、およびW1、W2、W3に対応する第5のストリームのパケット)。各フロー/ストリームは、特定のアプリケーション(たとえば、アプリケーション150D)に属していてもよく、または特定のリモート位置に定められてもよい。たとえば、複数のフロー/ストリームは、同じアプリケーション(たとえば、図7A〜7Dのアプリケーション150D)に属していてもよく、または異なるアプリケーション(たとえば、図6A〜6Dのアプリケーション150A〜150C)に属していてもよい。任意の所与の時間に、ネットワークデバイスは、何百または何千または何十億もの異なるフロー/ストリームを扱うかもしれず、時には、特定の宛先についてのトラフィック、または特定のアプリケーションについてのトラフィックを遅くする必要があるかもしれない。図7A〜7Dを参照して、いくつかの実現化例では、データトラフィックシェーピングモジュール166は、フロー/ストリームに対応するキュー(たとえば、トラフィックシェーピングキュー162および163)を取付け、同じキューを通して送信されたすべてのトラフィックを遅くする(たとえば、トラフィックシェーピングキュー163を通して送信された記述子W1、W2、W3に関連付けられたすべてのパケットを遅くする)ことによって、同じアプリケーション150Dから送信された異なるフロー/ストリームを、ライン先頭ブロッキングなしで独立して速度制限し、またはトラフィックシェーピングすることができる。この構成では、フローがアプリケーションによってそれらのキューにどのように入れられるか(たとえば、複数のフローが、図6A〜6Dに示すように対応する異なるアプリケーションから受信される場合、または図7A〜7Dに示すように同じアプリケーションから受信される場合)にかかわらず、フローは、ライン先頭ブロッキングを引き起こしたりパケットを破棄することなく、また、各アプリケーションから送信されたトラフィックがどのように分類されトラフィックシェーピングされ得るかを各アプリケーションが認識する必要なく、選択的に遅くされ得る。
図3〜5のフローチャートに示す方法を、いくつかの実現化例に従ったデータトラフィックシェーピングシステムの動作の例を表わすブロック図である図8A〜8Cを参照して以下にさらに説明する。図8A〜8Cでは、図6A〜6Dと同じ参照番号が使用されており、同じ説明は省略される。図8A〜8Cは、一次送信キュー161が一組の一次送信キュー161A〜161Cである場合のデータトラフィックシェーピングシステムの動作を示す。たとえば、一次送信キュー161は、マルチキューNICで実現された複数のキューであってもよい。いくつかの実現化例では、一組の一次送信キュー161A〜161Cの数は、速度リミッタすなわちトラフィックシェーピングキュー162A〜162Dの数よりも少ない。たとえば、何千ものフローまたはストリームをシェーピングするために、ネットワークデバイス110は10〜32個のハードウェアキューを有していてもよく、一方、その何千ものフローをシェーピングするためにそこに設置されたより多くのトラフィックシェーピングキューを有していてもよい。
図3のステージ310で、ネットワークインターフェイスドライバは、アプリケーション150によって生成され発送された一組のデータパケットを、ネットワークカードによる送信のために受信することができる。たとえば、図8Aを参照して、ネットワークインターフェイスドライバ164は、アプリケーション150A〜150Cによって生成され発送された一組のデータパケットを、ネットワークカード168による送信のために受信する。図8Aに示す例では、アプリケーション150Aは、記述子S1、S2およびS3に対応する第1のストリームの3つのパケットを順次送信する。アプリケーション150Bは、記述子T1、T2およびT3に対応する第2のストリームの3つのパケットを順次送信する。アプリケーション150Cは、記述子U1およびU2に対応する第3のストリームの2つのパケットを送信する。いくつかの実現化例では、ネットワークインターフェイスドライバ164は、データパケットを、パケットがアプリケーション150によって送信された順序で(たとえば、T1、次にU1、次にT2、次にS1、次にU2、次にS2、次にS3、次にT3という順序で)受信する。
図3のステージ320で、ネットワークインターフェイスドライバは、受信された第1の組のデータパケットに関連付けられた記述子を、一組の一次送信キュー161A〜161Cに格納することができる。いくつかの実現化例では、ネットワークインターフェイスドライバ164は、受信されたデータパケット毎に一次送信キュー161A〜161Cのうちの1つをランダムに選択し、対応する記述子を、一次送信キュー161のうちの選択された送信キューに書込む。たとえば、図8Aを参照して、ネットワークインターフェイスドライバ164は、記述子T1、S1およびS3を(T1、S1およびS3の順序で)一次送信キュー161Aに書込み、記述子U1、T2およびU2を(U1、T2およびU2の順序で)一次送信キュー161Bに書込み、記述子S2およびT3を(S2およびT3の順序で)一次送信キュー161Cに書込む。いくつかの実現化例では、各一次送信キューにおいて、各ストリームにおけるパケットの受信順序を維持しながら、異なるストリームのパケットをインタリーブすることができる。たとえば、図8Aに示す例では、一次送信キュー161Aにおいて、各ストリームのパケットの受信順序を維持しながら(たとえば、第3のストリームについてはS1→S3という順序という順序を維持しながら)、異なるストリームのパケットが(すなわち、T1、S1、S3という順序で)インタリーブされている。
図3のステージ330で、ネットワークインターフェイスドライバ164は、受信された第1の組のデータパケットに関連付けられ、各一次送信キューに格納された記述子(たとえば、一次送信キュー161Aに格納されたT1、S1、S3)を、データトラフィックシェーピングモジュール166に転送することができる。
図4を参照して、ステージ410で、データトラフィックシェーピングモジュールは、複数のトラフィックシェーピングキューを維持し、一次送信キュー161A〜161Cの各々から、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を受信する。図8Aおよび図8Bを参照して、ネットワークインターフェイスドライバ164が、受信されたデータパケットに関連付けられた記述子をデータトラフィックシェーピングモジュール166に転送することに応答して、データトラフィックシェーピングモジュール166は、一次送信キュー161Aからデータパケットの記述子(たとえば、記述子T1、S1、S3)を受信し、一次送信キュー161Bからデータパケットの記述子(たとえば、記述子U1、T2、U2)を受信し、一次送信キュー161Cからデータパケットの記述子(たとえば、記述子S2、T3)を受信する。いくつかの実現化例では、データトラフィックシェーピングモジュールは、複数のトラフィックシェーピングキューを維持し、各一次送信キューから、ネットワークインターフェイスドライバによって転送されたデータパケットの記述子を受信する。たとえば、図8A〜8Cを参照して、データトラフィックシェーピングモジュール166は、複数のトラフィックシェーピングキュー(たとえば、トラフィックシェーピングキュー162A〜162D)を維持する。
図4のステージ420で、データトラフィックシェーピングモジュール166は、各一次送信キューから受信された記述子に関連付けられたデータパケットを分類する。ステージ430で、データトラフィックシェーピングモジュール166は、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきか判断することができる。あるパケットの送信は、その分類の結果、それが、未送信パケット(またはそれらの記述子)をすでに格納しているトラフィックシェーピングキューに割当てられた場合、遅延される。
図4のステージ440で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきであると判断すると、データトラフィックシェーピングモジュールは、第1のデータパケットに関連付けられた第1の記述子を各一次送信キューから除去し、分類の結果に基づいて第1の記述子を対応するトラフィックシェーピングキューに格納する。たとえば、図8Aおよび図8Bを参照して、一次送信キュー161Aについて、データトラフィックシェーピングモジュールは、一次送信キュー161Aに格納された記述子T1、S1、S3に関連付けられたデータパケットの、ネットワークカード168による送信が遅延されるべきであると判断する。第2のストリームの記述子T1に関連付けられたデータパケットの、ネットワークカード168による送信が遅延されるべきであるという判断に応答して、データトラフィックシェーピングモジュール166は、記述子T1を一次送信キュー161Aから除去し、記述子T1をトラフィックシェーピングキュー162Cに格納する。同様に、データトラフィックシェーピングモジュール166は、第1のストリームの記述子S1を一次送信キュー161Aから除去し、記述子S1をトラフィックシェーピングキュー162Bに格納する。データトラフィックシェーピングモジュール166はまた、記述子S3を一次送信キュー161Aから除去し、記述子S3をトラフィックシェーピングキュー162Bに格納する。同様の態様で、図8Aおよび図8Bに示すように、一次送信キュー161Bについて、データトラフィックシェーピングモジュール166は、第3のストリームの記述子U1を一次送信キュー161Bから除去し、記述子U1をトラフィックシェーピングキュー162Aに格納し、第2のストリームの記述子T2を一次送信キュー161Bから除去し、記述子T2をトラフィックシェーピングキュー162Cに格納し、第3のストリームの記述子U2を一次送信キュー161Bから除去し、記述子U2をトラフィックシェーピングキュー162Aに格納する。同様の態様で、図8Aおよび図8Bに示すように、一次送信キュー161Cについて、データトラフィックシェーピングモジュール166は、第1のストリームの記述子S2を一次送信キュー161Cから除去し、記述子S2をトラフィックシェーピングキュー162Bに格納し、第2のストリームの記述子T3を一次送信キュー161Cから除去し、記述子T3をトラフィックシェーピングキュー162Cに格納する。
図4のステージ450で、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれのトラフィックシェーピングキューに関連付けられた送信速度規則に従って送信させる。たとえば、図8B〜8Cを参照して、データトラフィックシェーピングモジュール166は、ネットワークカード168に、トラフィックシェーピングキュー162Bに格納された記述子S1、S2およびS3に関連付けられたデータパケットを、トラフィックシェーピングキュー162Bに関連付けられた送信速度規則に従って、遅延された態様で送信させる。データトラフィックシェーピングモジュール166はまた、ネットワークカード168に、トラフィックシェーピングキュー162Cに格納された記述子T1、T2およびT3に関連付けられたデータパケットを、トラフィックシェーピングキュー162Cに関連付けられた送信速度規則に従って、遅延された態様で送信させる。
図4のステージ460で、データトラフィックシェーピングモジュールが、受信された第1の記述子に関連付けられた第1のデータパケットの、ネットワークカードによる送信が遅延されるべきではないと判断すると、データトラフィックシェーピングモジュールは、ネットワークカードに、トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットをすぐに送信させることができる。たとえば、あるデータパケットが、それが無制限の送信速度を可能にする送信速度規則を有するトラフィックシェーピングキューに割当てられるように分類され、かつそのキューが空である場合、そのデータパケットは遅延なくすぐに送信されてもよい。図8A〜8Cに示す例では、記述子U1およびU2に関連付けられたパケットが、そのようなものとして扱われる。
図4のステージ470で、データトラフィックシェーピングモジュールは、ネットワークインターフェイスドライバに、データパケットの順調な送信を通知することができる。たとえば、図8Bおよび図8Cを参照して、記述子U1およびU2に関連付けられたデータパケットの、ネットワークカード168を介した(即時)送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、データパケットの順調な送信を通知する。たとえば、図8Bおよび図8Cを参照して、記述子T1、S1、T2、S2、T3およびS3に関連付けられたデータパケットの、ネットワークカード168を介した(遅延)送信の順調な完了に応答して、データトラフィックシェーピングモジュール166は、ネットワークインターフェイスドライバ164に、データパケットの順調な送信を通知する。
図5を参照して、ステージ510で、ネットワークインターフェイスドライバは、受信された第1の組のパケットのうちの1つのパケットが、ネットワークカードによって順調に送信されたか判断する。
ステージ520で、ネットワークインターフェイスドライバが、受信された第1の組のパケットのうちの1つのパケットが順調に送信されたと判断することに応答して、ネットワークインターフェイスドライバは、パケット送信完了メッセージをアプリケーションに通信し、アプリケーションは、ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバに発送する。たとえば、図8Cを参照して、元々アプリケーション150Cから送信された第3のストリームの記述子U1に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子U1に対応するパケット送信完了メッセージ167(たとえば、図8CのM−U1)をアプリケーション150Cに通信する。同様に、元々アプリケーション150Cから送信された第3のストリームの記述子U2に関連付けられたパケットがネットワークカード168によって順調に送信されたという判断に応答して、ネットワークインターフェイスドライバ164は、記述子U2に対応するパケット送信完了メッセージ167(たとえば、図8CのM−U2)をアプリケーション150Cに通信する。同様に、いくつかの実現化例では、記述子T1、S1、T2、S2、T3およびS3に関連付けられたデータパケットの順調な送信を示すメッセージ(図示せず)をデータトラフィックシェーピングモジュール166から受信することに応答して、ネットワークインターフェイスドライバ164は、6つの別々の送信完了メッセージ(たとえば、図8CのM−T1、M−S1、M−T2、M−S2、M−T3およびM−S3)を生成し、各メッセージを、対応するパケットソースに、データパケットの順調な送信の順序で(たとえば、T1、S1、T2、S2、T3およびS3という順序で)通信する。
図8Cを参照して、いくつかの実現化例では、アプリケーション150の各々は、ネットワークインターフェイスドライバ164からのパケット送信完了メッセージの受信を待ってから、追加のデータパケットをネットワークインターフェイスドライバ164に発送するように構成可能である。いくつかの実現化例では、アプリケーション150の各々は、ネットワークインターフェイスドライバ164からの、ある特定のストリームのデータパケットについての送信完了メッセージの受信を待ってから、同じストリームの追加のデータパケットをネットワークインターフェイスドライバ164に発送するように構成可能である。
図8A〜8Cを参照して、いくつかの実現化例では、アプリケーション150またはネットワークインターフェイスドライバ164は、フロー/ストリームおよびそれらの対応するパケットを、一組の一次送信キュー161A〜161C中に、それらが構成される任意の態様(たとえば、キュー中へのランダム分散、またはキュー中へのラウンドロビン分散)で分散してもよい。いくつかの実現化例では、アプリケーション150またはネットワークインターフェイスドライバ164は、フロー/ストリームおよびそれらの対応するパケットを、一組の一次送信キュー中に、一次送信キューの数にかかわらず同じ態様で分散してもよい。いくつかの実現化例では、アプリケーション150またはネットワークインターフェイスドライバ164は、データトラフィックシェーピングモジュール166、トラフィックシェーピングキュー162A〜162Dの実現詳細、および、トラフィックがそれらのキューにどのように分類されるかを認識しないように構成される。たとえば、仮想マシンで実行されるアプリケーションからのトラフィックは、ライン先頭ブロッキングなしで、また、仮想マシンのアドミニストレータにトラフィックシェーピングキューおよび各キューに対する分類規則の詳細を通知せずに、シェーピングされ、または速度制限され得る。図8A〜8Cに示す構成では、パケットは、一次送信キューからできるだけ速く出ることができ、また、パケットが一次送信キューから出る際に完了メッセージを返すことなくトラフィックシェーピングキューに分類されることができる。いくつかの実現化例では、図8A〜8Cに示すように、パケットがトラフィックシェーピングキューから出るまで完了メッセージは返されず、そのため、完了メッセージはバラバラの順序で、すなわち、パケットが一次送信キューに保存される順序とは異なる順序で、およびFIFOではない順序で返され、それにより、より速いフローを送信するアプリケーションが、より遅いフローを送信する別のアプリケーションよりも、多くの追加のパケットを送信できるようにする。図8A〜Cを参照して、データトラフィックシェーピングモジュール166が、複数の一次送信キュー161A〜161Cを有するシステムにおいて実現される場合、ネットワークインターフェイスドライバ164は、各パケットが予め定められたキュー割当て規則に基づいて正しいキューに入れられるか、またはパケットトラフィックがキュー中に「ランダムに」分散されるかにかかわらず、「順序がバラバラの」完了メッセージを返すことができる(たとえば、完了メッセージM−U1、M−U2、M−T2の順序は、対応するパケットが一次送信キュー161Bに保存される順序、すなわちU1、T2、U2とは異なっている;図8Aおよび図8Cを参照)。
図9は、例示的なコンピューティングシステム140のブロック図である。例示的なコンピューティングシステム140は、ここに説明されたコンピュータ化されたコンポーネントを、図示された実現化例に従って実現する際の使用に好適である。広範な概観では、コンピューティングシステム140は、命令に従ってアクションを行なうための少なくとも1つのプロセッサ148と、命令およびデータを格納するための1つ以上のメモリデバイス144または149とを含む。図示された例示的なコンピューティングシステム140は、メモリ144、ネットワーク(図示せず)への接続のためのネットワークインターフェイスポート146を有する少なくとも1つのネットワークインターフェイスコントローラ143、および他のコンポーネント145、たとえば入力/出力(「I/O」)コンポーネント147と、バス142を介して通信している1つ以上のプロセッサ148を含む。一般に、プロセッサ148は、メモリから受信された命令を実行するであろう。図示されたプロセッサ148は、キャッシュメモリ149を組込み、またはキャッシュメモリ149に直接接続される。場合によっては、命令は、メモリ144からキャッシュメモリ149に読込まれ、キャッシュメモリ149からプロセッサ148によって実行される。
より詳細には、プロセッサ148は、命令、たとえばメモリ144またはキャッシュ149から取出された命令を処理する任意の論理回路であってもよい。多くの実現化例では、プロセッサ148は、マイクロプロセッサユニット、または専用プロセッサである。コンピューティングシステム140は、ここに説明されたように動作できる任意のプロセッサ、または任意の一組のプロセッサに基づいていてもよい。プロセッサ148は、シングルコアまたはマルチコアプロセッサであってもよい。プロセッサ148は、複数の別個のプロセッサであってもよい。
メモリ144は、コンピュータ読取可能なデータを格納するのに好適な任意のデバイスであってもよい。メモリ144は、固定ストレージを有するデバイス、またはリムーバブル記憶媒体を読取るためのデバイスであってもよい。例は、あらゆる形の不揮発性メモリ、媒体およびメモリデバイス、半導体メモリデバイス(たとえば、EPROM、EEPROM、SDRAM、およびフラッシュメモリデバイス)、磁気ディスク、光磁気ディスク、および光ディスク(たとえばCD ROM、DVD−ROM、またはBlu−Ray(登録商標)ディスク)を含む。コンピューティングシステム140は、任意の数のメモリデバイス144を有していてもよい。
キャッシュメモリ149は一般に、速い読取時間のためにプロセッサ148の近傍に配置された一種のコンピュータメモリである。いくつかの実現化例では、キャッシュメモリ149は、プロセッサ148の一部であり、またはプロセッサ148と同じチップ上にある。いくつかの実現化例では、キャッシュ149のレベルは複数あり、たとえば、L2およびL3キャッシュ層がある。
ネットワークインターフェイスコントローラ143は、(ネットワークインターフェイスポートとも呼ばれる)ネットワークインターフェイス146を介して、データ交換を管理する。ネットワークインターフェイスコントローラ143は、ネットワーク通信のためのOSIモデルの物理層およびデータリンク層を扱う。いくつかの実現化例では、ネットワークインターフェイスコントローラのタスクのうちのいくつかは、プロセッサ148の1つ以上によって扱われる。いくつかの実現化例では、ネットワークインターフェイスコントローラ143は、プロセッサ148の一部である。いくつかの実現化例では、コンピューティングシステム140は、単一のコントローラ143によって制御される複数のネットワークインターフェイス146を有する。いくつかの実現化例では、コンピューティングシステム140は、複数のネットワークインターフェイスコントローラ143を有する。いくつかの実現化例では、各ネットワークインターフェイス146は、物理ネットワークリンク(たとえばcat−5イーサネット(登録商標)リンク)のための接続点である。いくつかの実現化例では、ネットワークインターフェイスコントローラ143は無線ネットワーク接続をサポートし、インターフェイスポート146は、(たとえば、IEEE 802.11プロトコル、近距離無線通信「NFC」(near field communication)、Bluetooth(登録商標)、ANT、または任意の他の無線プロトコルのうちのいずれかのための)無線受信機/送信機である。いくつかの実現化例では、ネットワークインターフェイスコントローラ143は、イーサネットなどの1つ以上のネットワークプロトコルを実現する。一般に、コンピューティングシステム140は、ネットワークインターフェイス146を通して、物理リンクまたは無線リンクを介して、他のコンピューティングデバイスとデータを交換する。ネットワークインターフェイス146は、別のデバイスに直接リンクしてもよく、もしくは、インターネットなどのデータネットワークにコンピューティングシステム140を接続する、ハブ、ブリッジ、スイッチ、またはルータなどのネットワークデバイスといった中間デバイスを介して、別のデバイスにリンクしてもよい。
コンピューティングシステム140は、1つ以上の入力または出力(「I/O」)デバイスを含んでいてもよく、または当該入力または出力デバイスのためのインターフェイスを提供してもよい。入力デバイスは、キーボード、マイクロホン、タッチスクリーン、フットペダル、センサ、MIDIデバイス、および、マウスまたはトラックボールなどのポインティングデバイスを、何ら限定されることなく含んでいてもよい。出力デバイスは、ビデオディスプレイ、スピーカ、再生可能な点字端末、ライト、MIDIデバイス、および、2Dまたは3Dプリンタを、何ら限定されることなく含む。
他のコンポーネント145は、I/Oインターフェイス、外部シリアルデバイスポート、および任意の追加のコプロセッサを含んでいてもよい。たとえば、コンピューティングシステム140は、入力デバイス、出力デバイス、または追加のメモリデバイス(たとえば、ポータブルフラッシュドライブまたは外部メディアドライブ)を接続するためのインターフェイス(たとえば、ユニバーサルシリアルバス(universal serial bus:USB)インターフェイス)を含んでいてもよい。いくつかの実現化例では、コンピューティングデバイス140は、コプロセッサなどの追加のデバイス145を含み、たとえば、数値演算コプロセッサは、プロセッサ148が高精度のまたは複雑な計算を行なうのを支援できる。
この明細書で説明された主題および動作の実現化例は、デジタル電子回路で、もしくは、この明細書で開示された構造およびそれらの構造的等価物を含む有形の媒体、ファームウェア、またはハードウェア上で具現化されたコンピュータソフトウェアで、もしくは、それらのうちの1つ以上の組合せで実現可能である。この明細書で説明された主題の実現化例は、有形の媒体上で具現化された1つ以上のコンピュータプログラムとして、すなわち、データ処理装置による実行のために、またはデータ処理装置の動作を制御するために、1つ以上のコンピュータ記憶媒体上で符号化された、コンピュータプログラム命令の1つ以上のモジュールとして実現可能である。コンピュータ記憶媒体は、コンピュータ読取可能記憶装置、コンピュータ読取可能記憶基板、ランダムまたはシリアルアクセスメモリアレイまたはデバイス、もしくは、それらのうちの1つ以上の組合せであってもよく、またはそれに含まれていてもよい。コンピュータ記憶媒体はまた、1つ以上の別々のコンポーネントまたは媒体(たとえば、複数のCD、ディスク、または他の記憶装置)であってもよく、もしくはそれに含まれていてもよい。コンピュータ記憶媒体は、有形で非一時的なものであってもよい。
この明細書で説明された動作は、1つ以上のコンピュータ読取可能記憶装置上に格納され、または他のソースから受信されたデータに対して、データ処理装置によって行なわれる動作として実現可能である。
(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られる)コンピュータプログラムは、コンパイラ型言語またはインタープリタ型言語、宣言的言語または手続き型言語を含む任意の形のプログラミング言語で書くことができ、それは、スタンドアロンプログラムとして、もしくは、コンピュータ環境での使用に好適なモジュール、コンポーネント、サブルーチン、オブジェクト、または他のユニットとして、ということを含む任意の形でデプロイされ得る。コンピュータプログラムは、ファイルシステムのファイルに対応していてもよいが、対応する必要はない。プログラムは、他のプログラムまたはデータ(たとえば、マークアップ言語文書に格納された1つ以上のスクリプト)を保持するファイルの一部に格納されてもよく、当該プログラム専用の単一のファイルに格納されてもよく、もしくは、複数の連携ファイル(たとえば、1つ以上のモジュール、サブプログラム、またはコードの部分を格納するファイル)に格納されてもよい。コンピュータプログラムは、1つのコンピュータ上で、もしくは、1ヶ所に位置するかまたは複数箇所にわたって分散され、通信ネットワークによって相互接続された複数のコンピュータ上で、実行されるためにデプロイされ得る。通信ネットワークの例は、ローカルエリアネットワーク(local area network:「LAN」)およびワイドエリアネットワーク(wide area network:「WAN」)、インターネットワーク(たとえば、インターネット)、ならびに、ピアツーピアネットワーク(たとえば、アドホックピアツーピアネットワーク)を含む。
この明細書で説明されたプロセスおよび論理フローは、1つ以上のプログラマブルプロセッサが、入力データに対して動作して出力を生成することによってアクションを行なうように、1つ以上のコンピュータプログラムを実行することによって、行なわれてもよい。プロセスおよび論理フローはまた、専用論理回路、たとえばFPGA(field programmable gate array:フィールドプログラマブルゲートアレイ)またはASIC(application specific integrated circuit:特定用途向け集積回路)によって行なわれてもよく、装置も専用論理回路として実現されてもよい。そのような専用回路は、それが汎用プロセッサでなくても、コンピュータプロセッサと呼ばれてもよい。
この明細書は多くの特定の実現詳細を含んでいるが、これらは、任意の発明の、または請求され得ることの範囲に対する限定として解釈されるべきでなく、むしろ、特定の発明の特定の実現化例に特有の特徴の説明として解釈されるべきである。この明細書において別々の実現化例の文脈で説明されたある特徴はまた、単一の実現化例で組合されて実現されてもよい。反対に、単一の実現化例の文脈で説明されたさまざまな特徴も、複数の実現化例で別々に、または任意の好適な部分的組合せで実現されてもよい。さらに、特徴はある組合せで作用するとして上述されたかもしれず、さらにはそのように当初請求されたかもしれないが、請求された組合せからの1つ以上の特徴は、場合によっては、その組合せから削除されてもよく、請求された組合せは、部分的組合せ、または部分的組合せの変形に向けられてもよい。
同様に、動作はある特定の順序で図面に示されているが、これは、望ましい結果を達成するために、そのような動作が図示されたその特定の順序でまたは順次行なわれること、もしくは図示されたすべての動作が行なわれることを要求するとして理解されるべきではない。ある状況では、マルチタスク処理および並行処理が有利である場合がある。さらに、上述の実現化例におけるさまざまなシステムコンポーネントの分離は、すべての実現化例においてそのような分離を要求するとして理解されるべきではなく、説明されたプログラムコンポーネントおよびシステムは一般に、単一のソフトウェア製品にともに統合され、または複数のソフトウェア製品へとパッケージ化されてもよい、ということが理解されるべきである。
「または」への言及は、包括的であるとして解釈されてもよく、そのため、「または」を使用して説明されたどの用語も、単一の説明された用語、1つ以上の説明された用語、および説明された用語のすべて、のうちのいずれを示していてもよい。「第1」、「第2の」、「第3の」などといった表示は、必ずしも順序を示すよう意図されてはおらず、一般に、単に同じまたは同様の項目または要素を区別するために使用される。
このように、主題の特定の実現化例を説明してきた。他の実現化例は、請求項の範囲内にある。場合によっては、請求項に記載されたアクションは、異なる順序で行なわれてもよく、依然として望ましい結果を達成することができる。加えて、添付図面に示すプロセスは、望ましい結果を達成するために、図示された特定の順序または順次の順序を必ずしも必要としない。ある実現化例では、マルチタスク処理または並行処理が利用されてもよい。
110:ネットワークデバイス、112、144:メモリ、148:プロセッサ、150:アプリケーション、161:一次送信キュー、162、163、165:トラフィックシェーピングキュー、164:ネットワークインターフェイスドライバ、166:データトラフィックシェーピングモジュール、168:ネットワークカード。

Claims (20)

  1. ネットワークデバイスであって、
    ネットワークカードと、
    少なくとも1つのプロセッサと、
    メモリと、
    前記少なくとも1つのプロセッサ上で実行されるネットワークインターフェイスドライバとを含み、
    前記ネットワークインターフェイスドライバは、
    ソフトウェアアプリケーションによって生成され発送された第1の組のデータパケットを、前記ネットワークカードによる送信のために受信し、
    受信された前記第1の組のデータパケットに関連付けられた記述子を第1の順序で一次送信キューに格納し、
    受信された前記第1の組のデータパケットに関連付けられた前記記述子を、前記ネットワークカードおよび前記少なくとも1つのプロセッサのうちの一方上で実行されるデータトラフィックシェーピングモジュールに転送し、
    受信された前記第1の組のパケットのうちの1つのパケットが前記ネットワークカードによって順調に送信されたという判断に応答して、パケット送信完了メッセージを前記ソフトウェアアプリケーションに通信するように構成され、前記ソフトウェアアプリケーションは、前記ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットを前記ネットワークインターフェイスドライバに発送し、
    前記データトラフィックシェーピングモジュールは、
    複数のトラフィックシェーピングキューを維持するように構成され、各トラフィックシェーピングキューは少なくとも1つの関連付けられた送信速度規則を有し、前記データトラフィックシェーピングモジュールはさらに、
    前記一次送信キューから、前記ネットワークインターフェイスドライバによって転送されたデータパケットの前記記述子を受信し、
    受信された前記記述子に関連付けられた前記データパケットを分類し、
    受信された第1の記述子に関連付けられた第1のデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第1のデータパケットに関連付けられた前記第1の記述子を前記一次送信キューから除去し、分類の結果に基づいて前記第1の記述子を対応するトラフィックシェーピングキューに格納し、
    前記ネットワークカードに、前記トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれの前記トラフィックシェーピングキューに関連付けられた前記送信速度規則に従って送信させ、
    前記ネットワークインターフェイスドライバに、前記第1の順序とは異なる第2の順序でのデータパケットの順調な送信を通知するように構成される、ネットワークデバイス。
  2. 前記データトラフィックシェーピングモジュールは、前記ネットワークカード、および前記少なくとも1つのプロセッサ上で実行される実オペレーティングシステムのうちの一方の一部として含まれる、請求項1に記載のネットワークデバイス。
  3. 前記ネットワークインターフェイスドライバは、前記少なくとも1つのプロセッサ上で実行される実オペレーティングシステム内に含まれており、ゲストオペレーティングシステムを介して前記ソフトウェアアプリケーションと通信するように構成される、請求項1に記載のネットワークデバイス。
  4. 前記ネットワークインターフェイスドライバは、前記少なくとも1つのプロセッサ上で実行されるオペレーティングシステムの伝送制御プロトコル(TCP)スタックの第1の層内に含まれており、前記TCPスタックの上位層に含まれるソフトウェアアプリケーションと通信するように構成される、請求項1に記載のネットワークデバイス。
  5. 前記ネットワークカードは、
    第1のリソースを使用することによって前記第1のデータパケットを送信し、
    前記第1のデータパケットの送信に応答して、前記第1のリソースが前記ソフトウェアアプリケーションによってアクセス可能となるように前記第1のリソースを解放するように構成される、請求項1に記載のネットワークデバイス。
  6. 前記第1のリソースは、メモリバッファの一部である、請求項5に記載のネットワークデバイス。
  7. 前記データトラフィックシェーピングモジュールはさらに、
    前記第1の記述子を受信した後で、第2のデータパケットに関連付けられた第2の記述子を受信し、
    受信された前記第2の記述子に関連付けられた第2のデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第1のデータパケットを送信する前に、前記ネットワークカードに、前記一次送信キューに格納された前記第2の記述子に関連付けられた前記第2のデータパケットを送信させるように構成される、請求項1に記載のネットワークデバイス。
  8. 前記ネットワークカードは、複数のパケットを、前記複数のパケットを前記一次送信キューに格納する順序とはバラバラの順序で送信するように構成される、請求項1に記載のネットワークデバイス。
  9. 前記データトラフィックシェーピングモジュールはさらに、
    第1のストリームにおけるデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第1のストリームにおける前記データパケットに関連付けられた記述子を、前記トラフィックシェーピングキューのうちの第1のトラフィックシェーピングキューに格納し、
    前記第1のストリームとは異なる第2のストリームにおけるデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第2のストリームにおける前記データパケットに関連付けられた記述子を、前記トラフィックシェーピングキューのうちの第2のトラフィックシェーピングキューに格納するように構成される、請求項1に記載のネットワークデバイス。
  10. 前記ネットワークカードは、
    前記第1のトラフィックシェーピングキューに格納された複数のパケットを、前記複数のパケットを前記第1のトラフィックシェーピングキューに格納した順序で送信し、
    前記第2のトラフィックシェーピングキューに格納された複数のパケットを、前記複数のパケットを前記第2のトラフィックシェーピングキューに格納した順序で送信するように構成される、請求項9に記載のネットワークデバイス。
  11. 方法であって、
    ソフトウェアアプリケーションによって生成され発送された第1の組のデータパケットを、ネットワークカードによる送信のために、少なくとも1つのプロセッサ上で実行されるネットワークインターフェイスドライバによって受信することと、
    受信された前記第1の組のデータパケットに関連付けられた記述子を、前記ネットワークインターフェイスドライバによって、第1の順序で一次送信キューに格納することと、
    受信された前記第1の組のデータパケットに関連付けられた前記記述子を、前記ネットワークインターフェイスドライバによって、前記ネットワークカードおよび前記少なくとも1つのプロセッサのうちの一方上で実行されるデータトラフィックシェーピングモジュールに転送することと、
    受信された前記第1の組のパケットのうちの1つのパケットが前記ネットワークカードによって順調に送信されたという判断に応答して、前記ネットワークインターフェイスドライバによって、パケット送信完了メッセージを前記ソフトウェアアプリケーションに通信することとを含み、前記ソフトウェアアプリケーションは、前記ネットワークインターフェイスドライバからのパケット送信完了メッセージの受信を待ってから、追加のデータパケットを前記ネットワークインターフェイスドライバに発送し、前記方法はさらに、
    前記データトラフィックシェーピングモジュールによって、複数のトラフィックシェーピングキューを維持することを含み、各トラフィックシェーピングキューは少なくとも1つの関連付けられた送信速度規則を有し、前記方法はさらに、
    前記一次送信キューから、前記ネットワークインターフェイスドライバによって転送されたデータパケットの前記記述子を、前記データトラフィックシェーピングモジュールによって受信することと、
    受信された前記記述子に関連付けられた前記データパケットを、前記データトラフィックシェーピングモジュールによって分類することと、
    前記データトラフィックシェーピングモジュールによって、受信された第1の記述子に関連付けられた第1のデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第1のデータパケットに関連付けられた前記第1の記述子を前記一次送信キューから除去し、分類の結果に基づいて前記第1の記述子を対応するトラフィックシェーピングキューに格納することと、
    前記データトラフィックシェーピングモジュールによって、前記ネットワークカードに、前記トラフィックシェーピングキューに格納された記述子に関連付けられたデータパケットを、それぞれの前記トラフィックシェーピングキューに関連付けられた前記送信速度規則に従って送信させることと、
    前記データトラフィックシェーピングモジュールによって、前記ネットワークインターフェイスドライバに、前記第1の順序とは異なる第2の順序でのデータパケットの順調な送信を通知することとを含む、方法。
  12. 前記データトラフィックシェーピングモジュールは、前記ネットワークカード、および前記少なくとも1つのプロセッサ上で実行される実オペレーティングシステムのうちの一方の一部として含まれる、請求項11に記載の方法。
  13. 前記ネットワークインターフェイスドライバは、前記少なくとも1つのプロセッサ上で実行される実オペレーティングシステム内に含まれており、ゲストオペレーティングシステムを介して前記ソフトウェアアプリケーションと通信するように構成される、請求項11に記載の方法。
  14. 前記ネットワークインターフェイスドライバは、前記少なくとも1つのプロセッサ上で実行されるオペレーティングシステムの伝送制御プロトコル(TCP)スタックの第1の層内に含まれており、前記TCPスタックの上位層に含まれるソフトウェアアプリケーションと通信するように構成される、請求項11に記載の方法。
  15. 第1のリソースを使用することによって、前記第1のデータパケットを前記ネットワークカードによって送信することと、
    前記第1のデータパケットの送信に応答して、前記第1のリソースが前記ソフトウェアアプリケーションによってアクセス可能となるように、前記第1のリソースを前記ネットワークカードによって解放することとをさらに含む、請求項11に記載の方法。
  16. 前記第1のリソースは、メモリバッファの一部である、請求項15に記載の方法。
  17. 前記第1の記述子を受信した後で、第2のデータパケットに関連付けられた第2の記述子を、前記データトラフィックシェーピングモジュールによって受信することと、
    前記データトラフィックシェーピングモジュールによって、受信された前記第2の記述子に関連付けられた第2のデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第1のデータパケットを送信する前に、前記ネットワークカードに、前記一次送信キューに格納された前記第2の記述子に関連付けられた前記第2のデータパケットを送信させることとをさらに含む、請求項11に記載の方法。
  18. 前記ネットワークカードによって、複数のパケットを、前記複数のパケットを前記一次送信キューに格納する順序とはバラバラの順序で送信することをさらに含む、請求項11に記載の方法。
  19. 前記データトラフィックシェーピングモジュールによって、第1のストリームにおけるデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第1のストリームにおける前記データパケットに関連付けられた記述子を、前記トラフィックシェーピングキューのうちの第1のトラフィックシェーピングキューに格納することと、
    前記データトラフィックシェーピングモジュールによって、前記第1のストリームとは異なる第2のストリームにおけるデータパケットの、前記ネットワークカードによる送信が遅延されるべきであると判断し、そのような判断に応答して、前記第2のストリームにおける前記データパケットに関連付けられた記述子を、前記トラフィックシェーピングキューのうちの第2のトラフィックシェーピングキューに格納することとをさらに含む、請求項11に記載の方法。
  20. 前記ネットワークカードによって、前記第1のトラフィックシェーピングキューに格納された複数のパケットを、前記複数のパケットを前記第1のトラフィックシェーピングキューに格納した順序で送信することと、
    前記ネットワークカードによって、前記第2のトラフィックシェーピングキューに格納された複数のパケットを、前記複数のパケットを前記第2のトラフィックシェーピングキューに格納した順序で送信することとをさらに含む、請求項19に記載の方法。
JP2016251237A 2016-03-10 2016-12-26 ネットワークデバイスおよびトラフィックシェーピング方法 Active JP6632966B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/066,411 US9838321B2 (en) 2016-03-10 2016-03-10 Systems and method for single queue multi-stream traffic shaping with delayed completions to avoid head of line blocking
US15/066,411 2016-03-10

Publications (3)

Publication Number Publication Date
JP2017163530A JP2017163530A (ja) 2017-09-14
JP2017163530A5 JP2017163530A5 (ja) 2019-11-28
JP6632966B2 true JP6632966B2 (ja) 2020-01-22

Family

ID=57614273

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016251237A Active JP6632966B2 (ja) 2016-03-10 2016-12-26 ネットワークデバイスおよびトラフィックシェーピング方法

Country Status (5)

Country Link
US (1) US9838321B2 (ja)
EP (1) EP3217613B1 (ja)
JP (1) JP6632966B2 (ja)
CN (1) CN107181698B (ja)
DK (1) DK3217613T3 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10250571B2 (en) * 2015-08-24 2019-04-02 Cavium, Llc Systems and methods for offloading IPSEC processing to an embedded networking device
US10148581B2 (en) * 2016-05-30 2018-12-04 Mellanox Technologies, Ltd. End-to-end enhanced reliable datagram transport
US11153289B2 (en) * 2017-07-28 2021-10-19 Alibaba Group Holding Limited Secure communication acceleration using a System-on-Chip (SoC) architecture
CN109962859A (zh) * 2017-12-26 2019-07-02 北京华为数字技术有限公司 一种报文调度方法及设备
US10649784B2 (en) 2018-05-29 2020-05-12 Red Hat, Inc. Reverse order queue updates by virtual devices
US11258714B1 (en) 2018-09-28 2022-02-22 Google Llc Fine grain traffic shaping offload for a network interface card
CN111988200B (zh) * 2020-08-18 2022-03-08 湖南快乐阳光互动娱乐传媒有限公司 基于真实流量的自动回归测试方法及装置
KR20220082563A (ko) 2020-12-10 2022-06-17 삼성전자주식회사 스토리지 장치 및 이의 동작 방법

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3107077B2 (ja) * 1999-02-22 2000-11-06 住友電気工業株式会社 通信方法及び通信装置
EP1382165A2 (en) * 2001-04-13 2004-01-21 MOTOROLA INC., A Corporation of the state of Delaware Manipulating data streams in data stream processors
US7046628B2 (en) 2001-09-24 2006-05-16 Intel Corporation Apparatus and method for just-in-time transfer of transmit commands to a network interface
US20040103248A1 (en) * 2002-10-08 2004-05-27 Hass David T. Advanced telecommunications processor
US7924828B2 (en) 2002-10-08 2011-04-12 Netlogic Microsystems, Inc. Advanced processor with mechanism for fast packet queuing operations
JP2004363681A (ja) * 2003-06-02 2004-12-24 Matsushita Electric Ind Co Ltd パケットシェーピング方法、この方法を実施するパケットシェーピング装置及びコンピュータプログラム、並びにコンピュータプログラム記憶媒体
US7685250B2 (en) * 2005-03-09 2010-03-23 Intel Corporation Techniques for providing packet rate pacing
CN100466603C (zh) * 2005-05-17 2009-03-04 华为技术有限公司 对网络中传输的业务流进行整形的方法及装置
US20070258445A1 (en) * 2006-05-02 2007-11-08 Harris Corporation Systems and methods for protocol filtering for quality of service
CN101834787A (zh) * 2010-04-12 2010-09-15 中兴通讯股份有限公司 调度数据的方法和系统
CN102761489B (zh) * 2012-07-17 2015-07-22 中国科学技术大学苏州研究院 基于流水线模式的数据包零拷贝的核间通信方法
US8861538B2 (en) 2012-09-06 2014-10-14 Unisys Corporation Throttling for fast data packet transfer operations

Also Published As

Publication number Publication date
US9838321B2 (en) 2017-12-05
DK3217613T3 (da) 2020-03-09
EP3217613A1 (en) 2017-09-13
CN107181698B (zh) 2021-09-03
CN107181698A (zh) 2017-09-19
JP2017163530A (ja) 2017-09-14
EP3217613B1 (en) 2019-12-04
US20170264554A1 (en) 2017-09-14

Similar Documents

Publication Publication Date Title
JP6632966B2 (ja) ネットワークデバイスおよびトラフィックシェーピング方法
CN108337186B (zh) 用于可扩缩业务整形的设备和方法
US11736402B2 (en) Fast data center congestion response based on QoS of VL
TWI392288B (zh) 用於多核心通訊處理的系統及方法
US9455915B2 (en) Hierarchical congestion control with congested flow identification hardware
CN108337185B (zh) 具有时间索引数据结构的可缩放流量整形的设备和方法
Susanto et al. Stream: Decentralized opportunistic inter-coflow scheduling for datacenter networks
US10153979B2 (en) Prioritization of network traffic in a distributed processing system
US20170078204A1 (en) Congestion sensitive path-balancing
JP2009506618A (ja) 伝送情報を処理して、転送するシステムおよび方法
US11831550B2 (en) Fine grain traffic shaping offload for a network interface card
US11502967B2 (en) Methods and apparatuses for packet scheduling for software-defined networking in edge computing environment
KR20160042441A (ko) 애플리케이션-인식 네트워크 관리
US10909067B2 (en) Multi-node zero-copy mechanism for packet data processing
JP2017163530A5 (ja)
US20170171098A1 (en) System, method, and recording medium for queue management in a forwarder
US10171354B2 (en) Communication processing system, communication processing apparatus, communication processing method, and storage medium
Susanto et al. Creek: Inter many-to-many coflows scheduling for datacenter networks
Wang et al. An Incast-Coflow-Aware Minimum-Rate-Guaranteed Congestion Control Protocol for Datacenter Applications
Chen et al. Inspecting the performance of packet schedulers over a large-scale OpenFlow-based network
WO2023106981A1 (en) Reconfiguration of node of fat tree network for differentiated services
KR20180107706A (ko) 계층적 네트워크에서 다중코어를 이용한 패킷 처리 방법 및 그 장치

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191016

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191016

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20191016

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20191118

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20191126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191211

R150 Certificate of patent or registration of utility model

Ref document number: 6632966

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250