[要約] RFC 7806は、キューイング、マーキング、ドロッピングに関するガイドラインであり、ネットワークトラフィックの管理と品質向上を目的としています。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 7806 R. Pan
Category: Informational Cisco Systems
ISSN: 2070-1721 April 2016
On Queuing, Marking, and Dropping
キューイング、マーキング、およびドロップについて
Abstract
概要
This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.
このノートでは、キューイングおよびマーキング/ドロップアルゴリズムについて説明します。これらのアルゴリズムは結合して実装することもできますが、この注記では、仕様、測定、および比較によって、さまざまなアルゴリズムとシステム動作へのそれらの寄与を切り離す必要があると主張しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7806.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7806で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Fair Queuing: Algorithms and History . . . . . . . . . . . . 3
2.1. Generalized Processor Sharing . . . . . . . . . . . . . . 3
2.1.1. GPS Comparisons: Transmission Quanta . . . . . . . . 4
2.1.2. GPS Comparisons: Flow Definition . . . . . . . . . . 4
2.1.3. GPS Comparisons: Unit of Measurement . . . . . . . . 5
2.2. GPS Approximations . . . . . . . . . . . . . . . . . . . 5
2.2.1. Definition of a Queuing Algorithm . . . . . . . . . . 5
2.2.2. Round-Robin Models . . . . . . . . . . . . . . . . . 6
2.2.3. Calendar Queue Models . . . . . . . . . . . . . . . . 7
2.2.4. Work-Conserving Models and Stochastic Fairness
Queuing . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5. Non-Work-Conserving Models and Virtual Clock . . . . 9
3. Queuing, Marking, and Dropping . . . . . . . . . . . . . . . 10
3.1. Queuing with Tail Mark/Drop . . . . . . . . . . . . . . . 11
3.2. Queuing with CoDel Mark/Drop . . . . . . . . . . . . . . 11
3.3. Queuing with RED or PIE Mark/Drop . . . . . . . . . . . . 11
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
In the discussion of Active Queue Management (AQM), there has been discussion of the coupling of queue management algorithms such as Stochastic Fairness Queuing [SFQ], Virtual Clock [VirtualClock], or Deficit Round Robin [DRR] with mark/drop algorithms such as Controlled Delay (CoDel) [DELAY-AQM] or Proportional Integral controller Enhanced (PIE) [AQM-PIE]. In the interest of clarifying the discussion, we document possible implementation approaches to that and analyze the possible effects and side effects. The language and model derive from the Architecture for Differentiated Services [RFC2475].
アクティブキュー管理（AQM）の説明では、確率的公平性キューイング[SFQ]、仮想クロック[VirtualClock]、または赤丸ラウンドロビン[DRR]などのキュー管理アルゴリズムと、マーク/ドロップアルゴリズムなどの結合について説明しています。 Controlled Delay（CoDel）[DELAY-AQM]またはProportional Integral Controller Enhanced（PIE）[AQM-PIE]として。ディスカッションを明確にするために、可能な実装方法を文書化し、考えられる影響と副作用を分析します。言語とモデルは、Architectural for Differentiated Services [RFC2475]から派生しています。
This note is informational and is intended to describe reasonable possibilities without constraining outcomes. This is not so much about "right" or "wrong" as it is "what might be reasonable" and discusses several possible implementation strategies. Also, while queuing might be implemented in almost any layer, the note specifically addresses queues that might be used in the Differentiated Services Architecture and are therefore at or below the IP layer.
この注記は情報提供であり、結果を制約することなく合理的な可能性を説明することを目的としています。これは「正しい」または「間違っている」という意味ではなく、「合理的かもしれない」ものであり、いくつかの可能な実装戦略について説明しています。また、キューイングはほとんどすべての層で実装される可能性がありますが、このノートでは特に、差別化サービスアーキテクチャで使用される可能性があり、したがってIP層以下のキューについて説明します。
There is extensive history in the set of algorithms collectively referred to as "fair queuing". The model was initially discussed in [RFC970], which proposed it hypothetically as a solution to the TCP Silly Window Syndrome issue in BSD 4.1. The problem was that, due to a TCP implementation bug, some senders would settle into sending a long stream of very short segments, which unnecessarily consumed bandwidth on TCP and IP headers and occupied short packet buffers, thereby disrupting competing sessions. Nagle suggested that if packet streams were sorted by their source address and the sources treated in a round-robin fashion, a sender's effect on end-to-end latency and increased loss rate would primarily affect only itself. This touched off perhaps a decade of work by various researchers on what was and is termed "fair queuing", philosophical discussions of the meaning of the word "fair", operational reasons that one might want a "weighted" or "predictably unfair" queuing algorithm, and so on.
「フェアキューイング」と総称される一連のアルゴリズムには、長い歴史があります。このモデルは当初[RFC970]で議論され、BSD 4.1のTCP Silly Window Syndrome問題の解決策として仮想的に提案されました。問題は、TCP実装のバグが原因で、TCPとIPヘッダーの帯域幅を不必要に消費し、短いパケットバッファーを占有して非常に短いセグメントの長いストリームを送信することに落ち着く送信者がいて、競合するセッションを中断することでした。 Nagleは、パケットストリームが送信元アドレスでソートされ、送信元がラウンドロビン方式で処理された場合、送信者がエンドツーエンドのレイテンシと損失率の増加に及ぼす影響は、主にそれ自体にのみ影響することを示唆しました。これはおそらく、「フェアキューイング」と呼ばれるもの、および呼ばれるものに関するさまざまな研究者による10年の作業、「フェア」という言葉の意味に関する哲学的議論、「加重」または「予測可能に不公平」なキューイングが必要になる可能性のある運用上の理由から生まれました。アルゴリズムなど。
Conceptually, any fair queuing algorithm attempts to implement some approximation to the Generalized Processor Sharing [GPS] model.
概念的には、公平なキューイングアルゴリズムは、一般化されたプロセッサ共有[GPS]モデルの近似を実装しようとします。
The GPS model, in its essence, presumes that a set of identified data streams, called "flows", pass through an interface. Each flow has a rate when measured over a period of time; a voice session might, for example, require 64 kbit/s plus whatever overhead is necessary to deliver it, and a TCP session might have variable throughput depending on where it is in its evolution. The premise of Generalized Processor Sharing is that on all time scales, the flow occupies a predictable bit rate so that if there is enough bandwidth for the flow in the long term, it also lacks nothing in the short term. "All time scales" is obviously untenable in a packet network -- and even in a traditional Time-Division Multiplexer (TDM) circuit switch network -- because a timescale shorter than the duration of a packet will only see one packet at a time. However, it provides an ideal for other models to be compared against.
GPSモデルは、本質的に、「フロー」と呼ばれる一連の識別されたデータストリームがインターフェイスを通過することを前提としています。一定の期間にわたって測定した場合、各フローにはレートがあります。たとえば、音声セッションでは64 kbit / sに加えて、配信に必要なオーバーヘッドが必要になる場合があります。また、TCPセッションのスループットは、進化の過程によって異なります。 Generalized Processor Sharingの前提は、すべての時間スケールで、フローが予測可能なビットレートを占めるため、長期的にフローに十分な帯域幅がある場合、短期的には何も欠けないことです。パケットの持続時間より短いタイムスケールは一度に1つのパケットしか見えないため、「すべてのタイムスケール」は、パケットネットワークでは明らかに受け入れられません。従来の時分割多重（TDM）回線交換ネットワークでも同様です。ただし、他のモデルと比較するのに理想的です。
There are a number of attributes of approximations to the GPS model that bear operational consideration, including at least the transmission quanta, the definition of a "flow", and the unit of measurement. Implementation approaches have different practical impacts as well.
少なくとも伝送量子、「フロー」の定義、および測定単位を含む、運用上の考慮が必要なGPSモデルの近似には、いくつかの属性があります。実装アプローチにも、さまざまな実際的な影響があります。
The most obvious comparison between the GPS model and common approximations to it is that real world data is not delivered uniformly, but in some quantum. The smallest quantum in a packet network is a packet. But quanta can be larger; for example, in video applications, it is common to describe data flow in frames per second, where a frame describes a picture on a screen or the changes made from a previous one. A single video frame is commonly on the order of tens of packets. If a codec is delivering thirty frames per second, it is conceivable that the packets comprising a frame might be sent as thirty bursts per second, with each burst sent at the interface rate of the camera or other sender. Similarly, TCP exchanges have an initial window (common values of which include 1, 2, 3, 4 [RFC3390], and 10 [RFC6928]), and there are also reports of bursts of 64 KB at the relevant Maximum Segment Size (MSS), which is to say about 45 packets in one burst, presumably coming from TCP Segment Offload ((TSO) also called TCP Offload Engine (TOE)) engines (at least one implementation is known to be able to send a burst of 256 KB). After that initial burst, TCP senders commonly send pairs of packets but may send either smaller or larger bursts [RFC5690].
GPSモデルとそれに対する一般的な近似の最も明白な比較は、実際のデータが均一にではなく、ある量で提供されることです。パケットネットワークで最小のクォンタムはパケットです。しかし、量子はもっと大きくなる可能性があります。たとえば、ビデオアプリケーションでは、1秒あたりのフレーム数でデータフローを記述するのが一般的です。フレームは、画面上の画像または前の画像からの変更を表します。単一のビデオフレームは、通常、数十パケット程度です。コーデックが毎秒30フレームを配信している場合、フレームを構成するパケットは毎秒30バーストとして送信され、各バーストはカメラまたは他の送信者のインターフェイスレートで送信される可能性があります。同様に、TCP交換には初期ウィンドウ（1、2、3、4 [RFC3390]、および10 [RFC6928]を含む一般的な値）があり、関連する最大セグメントサイズ（MSS）で64 KBのバーストのレポートもあります。 ）、つまり1つのバーストで約45パケット、おそらくTCPセグメントオフロード（（TSO）はTCPオフロードエンジン（TOE）とも呼ばれます）エンジン（少なくとも1つの実装は256 KBのバーストを送信できることが知られています） ）。その最初のバーストの後、TCP送信者は通常、パケットのペアを送信しますが、より小さいまたはより大きいバーストを送信する場合があります[RFC5690]。
An important engineering trade-off relevant to GPS is the definition of a "flow". A flow is, by definition, a defined data stream. Common definitions include:
GPSに関連する重要なエンジニアリング上のトレードオフは、「フロー」の定義です。フローは、定義により、定義されたデータストリームです。一般的な定義は次のとおりです。
o packets in a single transport layer session ("microflow"), identified by a five-tuple [RFC2990];
o 5つのタプル[RFC2990]で識別される、単一のトランスポート層セッション（「microflow」）内のパケット。
o packets between a single pair of addresses, identified by a source and destination address or prefix;
o 送信元と宛先のアドレスまたはプレフィックスで識別される、1組のアドレス間のパケット。
o packets from a single source address or prefix [RFC970];
o 単一の送信元アドレスまたはプレフィックスからのパケット[RFC970];
o packets to a single destination address or prefix; and
o 単一の宛先アドレスまたはプレフィックスへのパケット。そして
o packets to or from a single subscriber, customer, or peer [RFC6057]. In Service Provider operations, this might be a neighboring Autonomous System; in broadband, this might be a residential customer.
o 単一の加入者、顧客、またはピアとの間のパケット[RFC6057]。サービスプロバイダーの操作では、これは隣接する自律システムである可能性があります。ブロードバンドでは、これは住宅顧客である可能性があります。
The difference should be apparent. Consider a comparison between sorting by source address or destination address, to pick two examples, in the case that a given router interface has N application sessions going through it between N/2 local destinations and N remote sources. Sorting by source, or in this case by source/destination pair, would give each remote peer an upper-bound guarantee of 1/N of the available capacity, which might be distributed very unevenly among the local destinations. Sorting by destination would give each local destination an upper-bound guarantee of 2/N of the available capacity, which might be distributed very unevenly among the remote systems and correlated sessions. Who is one fair to? In both cases, they deliver equal service by their definition, but that might not be someone else's definition.
違いは明らかです。特定のルーターインターフェイスにN / 2個のローカル宛先とN個のリモート送信元の間を通過するN個のアプリケーションセッションがある場合の2つの例を選択するために、送信元アドレスまたは宛先アドレスによる並べ替えの比較を検討してください。ソース、またはこの場合はソース/宛先のペアでソートすると、各リモートピアに使用可能な容量の1 / Nの上限保証が与えられ、ローカル宛先間で非常に不均一に分散される可能性があります。宛先でソートすると、各ローカル宛先に、使用可能な容量の2 / Nの上限保証が与えられます。これは、リモートシステムと相関セッションの間で非常に不均一に分散される可能性があります。誰が公正か？どちらの場合も、定義によって同等のサービスを提供しますが、それは他の誰かの定義ではない可能性があります。
Flow fairness, and the implications of TCP's congestion avoidance algorithms, is discussed extensively in [NoFair].
フローの公平性、およびTCPの輻輳回避アルゴリズムの意味については、[NoFair]で詳しく説明されています。
And finally, there is the question of what is measured for rate. If the only objective is to force packet streams to not dominate each other, it is sufficient to count packets. However, if the issue is the bit rate of a Service Level Agreement (SLA), one must consider the sizes of the packets (the aggregate throughput of a flow measured in bits or bytes). If predictable unfairness is a consideration, the value must be weighted accordingly.
そして最後に、レートを測定するものの問題があります。唯一の目的がパケットストリームを互いに支配しないようにすることである場合は、パケットをカウントするだけで十分です。ただし、問題がサービスレベルアグリーメント（SLA）のビットレートである場合は、パケットのサイズ（ビットまたはバイトで測定されたフローの総スループット）を考慮する必要があります。予測可能な不公平が考慮事項である場合、値はそれに応じて重み付けする必要があります。
[RFC7141] discusses measurement.
[RFC7141]は測定について説明しています。
Carrying the matter further, a queuing algorithm may also be termed "work conserving" or "non work conserving". A queue in a work-conserving algorithm, by definition, is either empty, in which case no attempt is being made to dequeue data from it, or contains something, in which case the algorithm continuously tries to empty the queue. A work-conserving queue that contains queued data at an interface with a given rate will deliver data at that rate until it empties. A non-work-conserving queue might stop delivering even though it still contains data. A common reason for doing this is to impose an artificial upper bound on a class of traffic that is lower than the rate of the underlying physical interface.
問題をさらに進めると、キューイングアルゴリズムは「作業節約」または「非作業節約」とも呼ばれます。作業節約アルゴリズムのキューは、定義により、空であるか、データをデキューする試みが行われていないか、何かが含まれている場合、アルゴリズムは継続的にキューを空にしようとします。特定のレートのインターフェイスにキューイングされたデータを含む作業節約キューは、空になるまでそのレートでデータを配信します。作業を保存しないキューは、データが含まれていても配信を停止する場合があります。これを行う一般的な理由は、基礎となる物理インターフェイスのレートよりも低いトラフィックのクラスに人為的な上限を課すことです。
In the discussion following, we assume a basic definition of a queuing algorithm. A queuing algorithm has, at minimum:
以下の説明では、キューイングアルゴリズムの基本的な定義を想定しています。キューイングアルゴリズムには、少なくとも次の機能があります。
o some form of internal storage for the elements kept in the queue;
o キューに保持されている要素の内部ストレージの形式。
o if it has multiple internal classifications, then it has
o 複数の内部分類がある場合は、
* a method for classifying elements and
* 要素を分類する方法と
* additional storage for the classifier and implied classes;
* 分類子と暗黙のクラスのための追加ストレージ。
o potentially, a method for creating the queue;
o 潜在的に、キューを作成するためのメソッド。
o potentially, a method for destroying the queue;
o 潜在的に、キューを破棄する方法。
o an enqueuing method for placing packets into the queue or queuing system; and
o パケットをキューまたはキューイングシステムに配置するためのエンキュー方法。そして
o a dequeuing method for removing packets from the queue or queuing system.
o キューまたはキューイングシステムからパケットを削除するためのデキュー方法。
There may also be other information or methods, such as the ability to inspect the queue. It also often has inspectable external attributes, such as the total volume of packets or bytes in queue, and may have limit thresholds, such as a maximum number of packets or bytes the queue might hold.
キューを検査する機能など、他の情報や方法がある場合もあります。また、キュー内のパケットまたはバイトの合計ボリュームなどの検査可能な外部属性を備えていることが多く、キューが保持できるパケットまたはバイトの最大数などの制限しきい値がある場合があります。
For example, a simple FIFO queue has a linear data structure, enqueues packets at the tail, and dequeues packets from the head. It might have a maximum queue depth and a current queue depth maintained in packets or bytes.
たとえば、単純なFIFOキューは線形データ構造を持ち、テールでパケットをエンキューし、ヘッドからパケットをデキューします。最大キュー深度と現在のキュー深度がパケットまたはバイト単位で維持される場合があります。
One class of implementation approaches, generically referred to as "Weighted Round Robin" (WRR), implements the structure of the queue as an array or ring of subqueues associated with flows for whatever definition of a flow is important.
実装アプローチの1つのクラスは、一般に「加重ラウンドロビン」（WRR）と呼ばれ、フローの定義が重要な場合に、フローに関連付けられたサブキューの配列またはリングとしてキューの構造を実装します。
The arriving packet must, of course, first be classified. If a hash is used as a classifier, the hash result might be used as an array index, selecting the subqueue that the packet will go into. One can imagine other classifiers, such as using a Differentiated Services Code Point (DSCP) value as an index into an array containing the queue number for a flow, or more complex access list implementations.
もちろん、到着するパケットは最初に分類されなければなりません。ハッシュが分類子として使用される場合、ハッシュ結果は配列インデックスとして使用され、パケットが入るサブキューを選択します。フローのキュー番号を含む配列へのインデックスとしてDiffServコードポイント（DSCP）値を使用する、またはより複雑なアクセスリストの実装など、他の分類子を想像できます。
In any event, a subqueue contains the traffic for a flow, and data is sent from each subqueue in succession.
いずれの場合でも、サブキューにはフローのトラフィックが含まれ、データは各サブキューから連続して送信されます。
Upon entering the queue, the enqueue method places a classified packet into a simple FIFO subqueue.
キューに入ると、エンキューメソッドは分類されたパケットを単純なFIFOサブキューに配置します。
On dequeue, the subqueues are searched in round-robin order, and when a subqueue is identified that contains data, the dequeue method removes a specified quantum of data from it. That quantum is at minimum a packet, but it may be more. If the system is intended to maintain a byte rate, there will be memory between searches of the excess previously dequeued.
デキューでは、サブキューはラウンドロビンの順序で検索され、データを含むサブキューが識別されると、デキューメソッドは指定されたデータの量をサブキューから削除します。その量子は最低でもパケットですが、それ以上になる場合もあります。システムがバイトレートを維持することを目的としている場合、以前にデキューされた超過分の検索の間にメモリが存在します。
+-+
+>|1|
| +-+
| |
| +-+ +-+
| |1| +>|3|
| +-+ | +-+
| | | |
| +-+ +-+ | +-+
| |1| +>|2| | |3|
| +-+ | +-+ | +-+
| A | A | A
| | | | | |
++--++ ++--++ ++--++
+->| Q |-->| Q |-->| Q |--+
| +----+ +----+ +----+ |
+----------------------------+
Figure 1: Round-Robin Queues
図1：ラウンドロビンキュー
Another class of implementation approaches, generically referred to as Calendar Queue Implementations [CalendarQueue], implements the structure of the queue as an array or ring of subqueues (often called "buckets") associated with time or sequence; each bucket contains the set of packets, which may be null, intended to be sent at a certain time or following the emptying of the previous bucket. The queue structure includes a look-aside table that indicates the current depth (which is to say, the next bucket) of any given class of traffic, which might similarly be identified using a hash, a DSCP, an access list, or any other classifier. Conceptually, the queues each contain zero or more packets from each class of traffic. One is the queue being emptied "now"; the rest are associated with some time or sequence in the future. The characteristics under "load" have been investigated in [Deadline].
別のクラスの実装アプローチは、一般にカレンダーキュー実装[CalendarQueue]と呼ばれ、時間またはシーケンスに関連付けられたサブキュー（しばしば「バケット」と呼ばれる）の配列またはリングとしてキューの構造を実装します。各バケットには、特定の時間に、または前のバケットが空になった後に送信されることを目的とした、nullの場合がある一連のパケットが含まれています。キュー構造には、特定のクラスのトラフィックの現在の深さ（つまり、次のバケット）を示すルックアサイドテーブルが含まれます。これは、ハッシュ、DSCP、アクセスリスト、またはその他の任意のクラスを使用して識別できます。分類子。概念的には、キューにはそれぞれ、トラフィックの各クラスからのゼロ個以上のパケットが含まれています。 1つは、「今」空になっているキューです。残りは、将来のある時間またはシーケンスに関連付けられています。 「負荷」下での特性は[デッドライン]で調査されました。
Upon entering the queue, the enqueue method, considering a classified packet, determines the current depth of that class with a view to scheduling it for transmission at some time or sequence in the future. If the unit of scheduling is a packet and the queuing quantum is one packet per subqueue, a burst of packets arrives in a given flow, and if at the start the flow has no queued data, the first packet goes into the "next" queue, the second into its successor, and so on. If there was some data in the class, the first packet in the burst would go into the bucket pointed to by the look-aside table. If the unit of scheduling is time, the explanation in Section 2.2.5 might be simplest to follow, but the bucket selected will be the bucket corresponding to a given transmission time in the future. A necessary side effect, memory being finite, is that there exist a finite number of "future" buckets. If enough traffic arrives to cause a class to wrap, one is forced to drop something (tail drop).
キューに入ると、エンキューメソッドは分類されたパケットを考慮して、そのクラスの現在の深さを決定し、ある時点または将来のシーケンスで送信するようにスケジュールすることを目的とします。スケジューリングの単位がパケットであり、キューイングクォンタムがサブキューごとに1パケットである場合、パケットのバーストが特定のフローに到着し、フローの開始時にキューにデータがない場合、最初のパケットは「次の」キューに入ります、後継者への2番目、というように続きます。クラスにデータがあった場合、バーストの最初のパケットは、ルックアサイドテーブルが指すバケットに送られます。スケジューリングの単位が時間の場合、セクション2.2.5の説明に従うのが最も簡単ですが、選択されるバケットは、将来の特定の送信時間に対応するバケットになります。メモリが有限であることの必要な副作用は、有限数の「将来の」バケットが存在することです。クラスを折り返すのに十分なトラフィックが到着すると、強制的に何かをドロップ（テールドロップ）します。
On dequeue, the buckets are searched at their stated times or in their stated sequence, and when a bucket is identified that contains data, the dequeue method removes a specified quantum of data from it and, by extension, from the associated traffic classes. A single bucket might contain data from a number of classes simultaneously.
デキューでは、バケットは指定された時間または指定された順序で検索されます。データが含まれているバケットが識別されると、デキューメソッドは、指定されたデータの量をバケットから、さらには関連するトラフィッククラスから削除します。 1つのバケットには、多数のクラスのデータが同時に含まれる場合があります。
+-+
+>|1|
| +-+
| |
| +-+ +-+
| |2| +>|2|
| +-+ | +-+
| | | |
| +-+ | +-+ +-+
| |3| | |1| +>|1|
| +-+ | +-+ | +-+
| A | A | A
| | | | | |
++--++ ++--++ ++--++
"now"+->| Q |-->| Q |-->| Q |-->...
+----+ +----+ +----+
A A A
|3 |2 |1
+++++++++++++++++++++++
|||| Flow ||||
+++++++++++++++++++++++
Figure 2: Calendar Queue
図2：カレンダーキュー
In any event, a subqueue contains the traffic for a point in time or a point in sequence, and data is sent from each subqueue in succession. If subqueues are associated with time, an interesting end case develops: if the system is draining a given subqueue and the time of the next subqueue arrives, what should the system do? One potentially valid line of reasoning would have it continue delivering the data in the present queue on the assumption that it will likely trade off for time in the next. Another potentially valid line of reasoning would have it discard any waiting data in the present queue and move to the next.
いずれの場合でも、サブキューには特定の時点または特定の時点のトラフィックが含まれており、データは各サブキューから連続して送信されます。サブキューが時間に関連付けられている場合、興味深い最終ケースが発生します。システムが特定のサブキューを排出していて、次のサブキューの時間が到着した場合、システムは何をすべきですか？正当な可能性のある推論の1行では、次の時間とトレードオフする可能性が高いと想定して、現在のキューにデータを配信し続けることになります。別の潜在的に有効な推論行では、現在のキューで待機中のデータを破棄し、次のキューに移動します。
Stochastic Fairness Queuing [SFQ] is an example of a work-conserving algorithm. This algorithm measures packets and considers a "flow" to be an equivalence class of traffic defined by a hashing algorithm over the source and destination IPv4 addresses. As packets arrive, the enqueue method performs the indicated hash and places the packet into the indicated subqueue. The dequeue method operates as described in Section 2.2.2; subqueues are inspected in round-robin sequence and a packet is removed if they contain one or more packets.
確率的公平性キューイング[SFQ]は、作業節約アルゴリズムの例です。このアルゴリズムはパケットを測定し、「フロー」を、送信元および宛先IPv4アドレスに対するハッシュアルゴリズムによって定義された同等のトラフィッククラスと見なします。パケットが到着すると、エンキューメソッドは指定されたハッシュを実行し、パケットを指定されたサブキューに配置します。 dequeueメソッドは、セクション2.2.2で説明されているように動作します。サブキューはラウンドロビンシーケンスで検査され、1つ以上のパケットが含まれている場合はパケットが削除されます。
The Deficit Round Robin [DRR] model modifies the quanta to bytes and deals with variable length packets. A subqueue descriptor contains a waiting quantum (the amount intended to be dequeued on the previous dequeue attempt that was not satisfied), a per-round quantum (the subqueue is intended to dequeue a certain number of bytes each round), and a maximum to permit (some multiple of the MTU). In each dequeue attempt, the dequeue method sets the waiting quantum to the smaller of the maximum quantum and the sum of the waiting and incremental quantum. It then dequeues up to the waiting quantum (in bytes) of packets in the queue and reduces the waiting quantum by the number of bytes dequeued. Since packets will not normally be exactly the size of the quantum, some dequeue attempts will dequeue more than others, but they will over time average the incremental quantum per round if there is data present.
Deficit Round Robin [DRR]モデルは、量子をバイトに変更し、可変長パケットを処理します。サブキュー記述子には、待機中のクォンタム（前回のデキュー試行で満たされなかったデキューを意図した量）、ラウンドごとのクォンタム（サブキューは、各ラウンドで特定のバイト数をデキューすることを意図しています）、および最大許可（MTUのいくつかの倍数）。デキューを試行するたびに、デキューメソッドは、待機中のクォンタムを、最大クォンタムと、待機中のクォンタムと増分クォンタムの合計の小さい方に設定します。次に、キュー内のパケットの待機クォンタム（バイト単位）までデキューし、デキューされたバイト数だけ待機クォンタムを減らします。パケットは通常、クォンタムのサイズと正確には一致しないため、いくつかのデキュー試行は他のキューより多くデキューされますが、データが存在する場合、ラウンドごとの増分クォンタムが時間平均されます。
[SFQ] and [DRR] could be implemented as described in Section 2.2.3. The weakness of a classical WRR approach is the search time expended inspecting and not choosing sub-queues that contain no data or not enough to trigger a transmission from them.
[SFQ]と[DRR]は、セクション2.2.3で説明されているように実装できます。従来のWRRアプローチの弱点は、検索に時間がかかり、データが含まれていないか、サブキューからの送信をトリガーするのに十分でないサブキューを選択しないことです。
Virtual Clock [VirtualClock] is an example of a non-work-conserving algorithm. It is trivially implemented as described in Section 2.2.3. It associates buckets with intervals in time that have durations on the order of microseconds to tens of milliseconds. Each flow is assigned a rate in bytes per interval. The flow entry maintains a point in time the "next" packet in the flow should be scheduled.
仮想時計[VirtualClock]は、非作業保存アルゴリズムの例です。セクション2.2.3で説明されているように、簡単に実装されます。これは、マイクロ秒から数十ミリ秒のオーダーの期間を持つ時間間隔にバケットを関連付けます。各フローには、間隔ごとのバイト数でレートが割り当てられます。フローエントリは、フロー内の「次の」パケットをスケジュールする必要がある時点を維持します。
On enqueue, the method determines whether the "next schedule" time is "in the past"; if so, the packet is scheduled "now", and if not, the packet is scheduled at that time. It then calculates the new "next schedule" time as the current "next schedule" time plus the length of the packet divided by the rate. If the resulting time is also in the past, the "next schedule" time is set to "now"; otherwise, it is set to the calculated time. As noted in Section 2.2.3, there is an interesting point regarding "too much time in the future"; if a packet is scheduled too far into the future, it may be marked or dropped in the AQM procedure, and if it runs beyond the end of the queuing system, may be defensively tail dropped.
エンキュー時に、このメソッドは「次のスケジュール」の時間が「過去」であるかどうかを判断します。その場合、パケットは「今」スケジュールされ、そうでない場合、パケットはその時にスケジュールされます。次に、新しい「次のスケジュール」時間を、現在の「次のスケジュール」時間とパケットの長さをレートで割ったものとして計算します。結果の時刻も過去の場合、「次のスケジュール」の時刻は「現在」に設定されます。それ以外の場合は、計算された時間に設定されます。 2.2.3節で述べたように、「未来が長すぎる」という点には興味深い点があります。パケットのスケジュールが遠すぎる場合は、AQM手順でマークまたはドロップされる可能性があり、キューシステムの最後を超えて実行される場合は、防御的にテールドロップされる可能性があります。
On dequeue, the bucket associated with the time "now" is inspected. If it contains a packet, the packet is dequeued and transmitted. If the bucket is empty and the time for the next bucket has not arrived, the system waits, even if there is a packet in the next bucket. As noted in Section 2.2.3, there is an interesting point regarding the queue associated with "now". If a subsequent bucket, even if it is actually empty, would be delayed by the transmission of a packet, one could imagine marking the packet Explicit Congestion Notification - Congestion Experienced (ECN-CE) [RFC3168] [RFC6679] or dropping the packet.
デキュー時に、「今」の時間に関連付けられたバケットが検査されます。パケットが含まれている場合、パケットはデキューされて送信されます。バケットが空で、次のバケットの時間が到着していない場合、システムは、次のバケットにパケットがある場合でも待機します。セクション2.2.3で述べたように、「今」に関連付けられたキューに関して興味深い点があります。後続のバケットが実際には空であっても、パケットの送信によって遅延する場合、パケットに明示的な輻輳通知-輻輳経験（ECN-CE）[RFC3168] [RFC6679]をマークするか、パケットをドロップすることを想像できます。
Queuing, marking, and dropping are integrated in any system that has a queue. If nothing else, as memory is finite, a system has to drop as discussed in Sections 2.2.3 and 2.2.5 in order to protect itself. However, host transports interpret drops as signals, so AQM algorithms use that as a mechanism to signal.
キューイング、マーキング、およびドロップは、キューを持つすべてのシステムに統合されています。それ以外の場合は、メモリが有限であるため、セクション2.2.3および2.2.5で説明されているように、システムを保護するためにシステムをドロップする必要があります。ただし、ホストトランスポートはドロップをシグナルとして解釈するため、AQMアルゴリズムはそれをシグナル伝達のメカニズムとして使用します。
It is useful to think of the effects of queuing as a signal as well. The receiver sends acknowledgements as data is received, so the arrival of acknowledgements at the sender paces the sender at approximately the average rate it is able to achieve through the network. This is true even if the sender keeps an arbitrarily large amount of data stored in network queues and is the basis for delay-based congestion control algorithms. So, delaying a packet momentarily in order to permit another session to improve its operation has the effect of signaling a slightly lower capacity to the sender.
キューイングの影響を信号として考えることも役立ちます。受信側はデータの受信時に確認応答を送信するため、送信側に確認応答が到着すると、ネットワークを介して達成できるおおよその平均速度で送信側のペースが調整されます。これは、送信者がネットワークキューに格納された任意の大量のデータを保持している場合にも当てはまり、遅延ベースの輻輳制御アルゴリズムの基礎となります。したがって、別のセッションが動作を改善できるようにパケットを一時的に遅延させると、送信側にわずかに低い容量を通知する効果があります。
In the default case in which a FIFO queue is used with defensive tail drop only, the effect is to signal to the sender in two ways:
防御テールドロップのみでFIFOキューが使用されるデフォルトの場合、効果は次の2つの方法で送信者に信号を送ることです。
o Ack clocking, which involves pacing the sender to send at approximately the rate it can deliver data to the receiver; and
o ACKクロッキング。これは、送信側が受信側にデータを配信できるほぼの速度で送信するように調整することを含みます。そして
o Defensive loss, which is when a sender sends faster than available capacity (such as by probing network capacity when fully utilizing that capacity) and overburdens a queue.
o 防御的損失。これは、送信者が利用可能な容量よりも速く送信し（その容量を完全に利用しているときにネットワーク容量をプローブするなど）、キューに過剰な負荷がかかる場合です。
In any case wherein a queuing algorithm is used along with CoDel [DELAY-AQM], the sequence of events is that a packet is time stamped, enqueued, dequeued, compared to a subsequent reading of the clock, and then acted on, whether by dropping it, marking and forwarding it, or simply forwarding it. This is to say that the only drop algorithm inherent in queuing is the defensive drop when the queue's resources are overrun. However, the intention of marking or dropping is to signal to the sender much earlier when a certain amount of delay has been observed. In a FIFO+CoDel, Virtual Clock+CoDel, or FlowQueue-Codel [FQ-CODEL] implementation, the queuing algorithm is completely separate from the AQM algorithm. Using them in series results in four signals to the sender:
CoDel [DELAY-AQM]とともにキューイングアルゴリズムが使用される場合、イベントのシーケンスは、次のクロックの読み取りと比較して、パケットにタイムスタンプが付けられ、キューに入れられ、キューから取り出されてから、ドロップ、マーキングして転送、または単に転送します。これは、キューのリソースがオーバーランした場合の、キューイングに固有のドロップアルゴリズムが防御的なドロップであるということです。ただし、マーキングまたはドロップの目的は、ある程度の遅延が観察されたときに、はるかに早く送信者に通知することです。 FIFO + CoDel、仮想クロック+ CoDel、またはFlowQueue-Codel [FQ-CODEL]の実装では、キューイングアルゴリズムはAQMアルゴリズムから完全に分離しています。それらを直列に使用すると、送信者に4つの信号が送信されます。
o Ack clocking, which involves pacing the sender to send at approximately the rate it can deliver data to the receiver through a queue;
o ACKクロッキング。これは、キューを介してレシーバーにデータを配信できるレートとほぼ同じ速度で送信者を送信するように調整します。
o Lossless signaling that a certain delay threshold has been reached, if ECN [RFC3168] [RFC6679] is in use;
o ECN [RFC3168] [RFC6679]が使用されている場合、特定の遅延しきい値に到達したことを示すロスレスシグナリング。
o Intentional signaling via loss that a certain delay threshold has been reached, if ECN is not in use; and
o ECNが使用されていない場合に、特定の遅延しきい値に達したことを示す、損失による意図的なシグナリング。そして
o Defensive loss, which is when a sender sends faster than available capacity (such as by probing network capacity when fully utilizing that capacity) and overburdens a queue.
o 防御的損失。これは、送信者が利用可能な容量よりも速く送信し（その容量を完全に利用しているときにネットワーク容量をプローブするなど）、キューに過剰な負荷がかかる場合です。
In any case wherein a queuing algorithm is used along with PIE [AQM-PIE], Random Early Detection (RED) [RFC7567], or other such algorithms, the sequence of events is that a queue is inspected, a packet is dropped, marked, or left unchanged, enqueued, dequeued, compared to a subsequent reading of the clock, and then forwarded on.
キューイングアルゴリズムがPIE [AQM-PIE]、ランダム早期検出（RED）[RFC7567]、または他のそのようなアルゴリズムと共に使用される場合、イベントのシーケンスは、キューが検査され、パケットがドロップされ、マークされます。 、または変更せずに、エンキュー、デキューし、その後のクロックの読み取りと比較して、次に転送します。
This is to say that the AQM Mark/Drop Algorithm precedes enqueue; if it has not been effective and as a result the queue is out of resources anyway, the defensive drop algorithm steps in, and failing that, the queue operates in whatever way it does. Hence, in a FIFO+PIE, SFQ+PIE, or Virtual Clock+PIE implementation, the queuing algorithm is again completely separate from the AQM algorithm. Using them in series results in four signals to the sender:
これは、AQMマーク/ドロップアルゴリズムがエンキューの前にあるということです。効果的でなかったためにキューがリソース不足になった場合、防御ドロップアルゴリズムが介入し、失敗すると、キューはどのように動作するかを確認します。したがって、FIFO + PIE、SFQ + PIE、または仮想クロック+ PIEの実装では、キューイングアルゴリズムはAQMアルゴリズムから完全に分離されています。それらを直列に使用すると、送信者に4つの信号が送信されます。
o Ack clocking, which involves pacing the sender to send at approximately the rate it can deliver data to the receiver through a queue;
o ACKクロッキング。これは、キューを介してレシーバーにデータを配信できるレートとほぼ同じ速度で送信者を送信するように調整します。
o Lossless signaling that a queue depth that corresponds to a certain delay threshold has been reached, if ECN is in use;
o ECNが使用されている場合、特定の遅延しきい値に対応するキューの深さに到達したことを示すロスレスシグナリング。
o Intentional signaling via loss that a queue depth that corresponds to a certain delay threshold has been reached, if ECN is not in use; and
o ECNが使用されていない場合に、特定の遅延しきい値に対応するキューの深さに達したことを示す、損失による意図的なシグナリング。そして
o Defensive loss, which is when a sender sends faster than available capacity (such as by probing network capacity when fully utilizing that capacity) and overburdens a queue.
o 防御的損失。これは、送信者が利用可能な容量よりも速く送信し（その容量を完全に利用しているときにネットワーク容量をプローブするなど）、キューに過剰な負荷がかかる場合です。
To summarize, in Section 2, implementation approaches for several classes of queuing algorithms were explored. Queuing algorithms such as SFQ, Virtual Clock, and FlowQueue-Codel [FQ-CODEL] have value in the network in that they delay packets to enforce a rate upper bound or to permit competing flows to compete more effectively. ECN marking and loss are also useful signals if used in a manner that enhances TCP / Steam Control Transmission Protocol (SCTP) operation or restrains unmanaged UDP data flows.
要約すると、セクション2では、いくつかのクラスのキューイングアルゴリズムの実装アプローチが検討されました。 SFQ、仮想クロック、FlowQueue-Codel [FQ-CODEL]などのキューイングアルゴリズムは、パケットを遅延させてレートの上限を強制したり、競合するフローがより効果的に競合できるようにするという点で、ネットワークに価値があります。 ECNマーキングと損失は、TCP / Steam Control Transmission Protocol（SCTP）の動作を強化したり、管理されていないUDPデータフローを抑制したりする方法で使用する場合にも有用な信号です。
Conceptually, queuing algorithms and mark/drop algorithms operate in series (as discussed in Section 3), not as a single algorithm. The observed effects differ: defensive loss protects the intermediate system and provides a signal, AQM mark/drop works to reduce mean latency, and the scheduling of flows works to modify flow interleave and acknowledgement pacing. Certain features like flow isolation are provided by fair-queuing-related designs but are not the effect of the mark/drop algorithm.
概念的には、キューイングアルゴリズムとマーク/ドロップアルゴリズムは、単一のアルゴリズムとしてではなく、連続して動作します（セクション3で説明）。観察された効果は異なります。防御的な損失は中間システムを保護し、信号を提供します。AQMマーク/ドロップは平均遅延を削減するように機能し、フローのスケジューリングはフローインターリーブと確認応答のペーシングを変更するように機能します。フロー分離などの特定の機能は、フェアキューイング関連の設計によって提供されますが、マーク/ドロップアルゴリズムの効果ではありません。
There is value in implementing and coupling the operation of both queuing algorithms and queue management algorithms, and there is definitely interesting research in this area, but specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.
キューイングアルゴリズムとキュー管理アルゴリズムの両方の操作を実装して結合することには価値があり、この分野には間違いなく興味深い研究がありますが、仕様、測定、および比較は、さまざまなアルゴリズムとそれらのシステム動作への寄与を切り離す必要があります。
This memo adds no new security issues; it observes implementation strategies for Diffserv implementation.
このメモは新しいセキュリティ問題を追加しません。 Diffserv実装の実装戦略を順守します。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。
[AQM-PIE] Pan, R., Natarajan, P., and F. Baker, "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", Work in Progress, draft-ietf-aqm-pie-06, April 2016.
[AQM-PIE]パン、R。、ナタラジャン、P。、およびF.ベイカー、「PIE：バッファブロート問題に対処するための軽量制御スキーム」、進行中の作業、draft-ietf-aqm-pie-06、2016年4月。
[CalendarQueue] Brown, R., "Calendar queues: a fast 0(1) priority queue implementation for the simulation event set problem", Communications of the ACM Volume 21, Issue 10, pp. 1220-1227, DOI 10.1145/63039.63045, October 1988, <http://dl.acm.org/citation.cfm?id=63045>.
[CalendarQueue]ブラウン、R。、「カレンダーキュー：シミュレーションイベントセット問題の高速0（1）優先度キューの実装」、ACMボリューム21の通信、第10号、pp。1220-1227、DOI 10.1145 / 63039.63045、 1988年10月、<http://dl.acm.org/citation.cfm?id=63045>。
[Deadline] Kruk, L., Lohoczky, J., Ramanan, K., and S. Shreve, "Heavy Traffic Analysis For EDF Queues With Reneging", The Annals of Applied Probability Volume 21, Issue No. 2, pp. 484-545, DOI 10.1214/10-AAP681, 2011, <http://www.math.cmu.edu/users/shreve/Reneging.pdf>.
[締め切り] Kruk、L.、Lohoczky、J.、Ramanan、K。、およびS. Shreve、「Rengingを使用したEDFキューの大量トラフィック分析」、 『適用された確率のボリューム21』、第2号、pp.484 -545、DOI 10.1214 / 10-AAP681、2011、<http://www.math.cmu.edu/users/shreve/Reneging.pdf>。
[DELAY-AQM] Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar, "Controlled Delay Active Queue Management", Work in Progress, draft-ietf-aqm-codel-03, March 2016.
[DELAY-AQM] Nichols、K.、Jacobson、V.、McGregor、A.、J。Iyengar、「Controlled Delay Active Queue Management」、Work in Progress、draft-ietf-aqm-codel-03、2016年3月。
[DRR] Shreedhar, M. and G. Varghese, "Efficient fair queuing using deficit round-robin", IEEE/ACM Transactions on Networking Volume 4, Issue 3, pp. 375-385, DOI 10.1109/90.502236, June 1996, <http://ieeexplore.ieee.org/stamp/ stamp.jsp?tp=&arnumber=502236>.
[DRR] Shreedhar、M。およびG. Varghese、「赤字ラウンドロビンを使用した効率的な公平なキューイング」、IEEE / ACM Transactions on Networking Volume 4、Issue 3、pp。375-385、DOI 10.1109 / 90.502236、1996年6月、< http://ieeexplore.ieee.org/stamp/ stamp.jsp？tp =＆arnumber = 502236>。
[FQ-CODEL] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm", Work in Progress, draft-ietf-aqm-fq-codel-06, March 2016.
[FQ-CODEL] Hoeiland-Joergensen、T.、McKenney、P.、Taht、D.、Gettys、J。、およびE. Dumazet、「FlowQueue-CoDelパケットスケジューラおよびアクティブキュー管理アルゴリズム」、Work in Progress、 draft-ietf-aqm-fq-codel-06、2016年3月。
[GPS] Demers, A., University of California, Berkeley, and Xerox PARC, "Analysis and Simulation of a Fair Queueing Algorithm", ACM SIGCOMM Computer Communication Review, Volume 19, Issue 4, pp. 1-12, DOI 10.1145/75247.75248, September 1989, <http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/ data/89/fq.pdf>.
[GPS] Demers、A。、カリフォルニア大学バークレー、およびXerox PARC、「フェアキューイングアルゴリズムの分析とシミュレーション」、ACM SIGCOMM Computer Communication Review、Volume 19、Issue 4、pp。1-12、DOI 10.1145 / 75247.75248、1989年9月、<http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/89/fq.pdf>。
[NoFair] Briscoe, B., "Flow rate fairness: dismantling a religion", ACM SIGCOMM Computer Communication Review, Volume 37, Issue 2, pp. 63-74, DOI 10.1145/1232919.1232926, April 2007, <http://dl.acm.org/citation.cfm?id=1232926>.
[NoFair] Briscoe、B。、「流量の公平性：宗教の解体」、ACM SIGCOMM Computer Communication Review、Volume 37、Issue 2、63-74ページ、DOI 10.1145 / 1232919.1232926、2007年4月、<http：// dl .acm.org / citation.cfm？id = 1232926>。
[RFC970] Nagle, J., "On Packet Switches With Infinite Storage", RFC 970, DOI 10.17487/RFC0970, December 1985, <http://www.rfc-editor.org/info/rfc970>.
[RFC970] Nagle、J。、「On Packet Switches With Infinite Storage」、RFC 970、DOI 10.17487 / RFC0970、1985年12月、<http://www.rfc-editor.org/info/rfc970>。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, DOI 10.17487/RFC2990, November 2000, <http://www.rfc-editor.org/info/rfc2990>.
[RFC2990] Huston、G。、「IP QoSアーキテクチャの次のステップ」、RFC 2990、DOI 10.17487 / RFC2990、2000年11月、<http://www.rfc-editor.org/info/rfc2990>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 2002, <http://www.rfc-editor.org/info/rfc3390>.
[RFC3390]オールマン、M。、フロイド、S.、C。パートリッジ、「TCPの初期ウィンドウの増加」、RFC 3390、DOI 10.17487 / RFC3390、2002年10月、<http://www.rfc-editor.org/info / rfc3390>。
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding Acknowledgement Congestion Control to TCP", RFC 5690, DOI 10.17487/RFC5690, February 2010, <http://www.rfc-editor.org/info/rfc5690>.
[RFC5690] Floyd、S.、Arcia、A.、Ros、D。、およびJ. Iyengar、「Adding Acknowledgement Congestion Control Control to TCP」、RFC 5690、DOI 10.17487 / RFC5690、2010年2月、<http：// www。 rfc-editor.org/info/rfc5690>。
[RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Woundy, "Comcast's Protocol-Agnostic Congestion Management System", RFC 6057, DOI 10.17487/RFC6057, December 2010, <http://www.rfc-editor.org/info/rfc6057>.
[RFC6057]バスティアン、C。、クリーバー、T。、リビングウッド、J。、ミルズ、J。、およびR.ワウンディ、「Comcastのプロトコルにとらわれない輻輳管理システム」、RFC 6057、DOI 10.17487 / RFC6057、2010年12月、< http://www.rfc-editor.org/info/rfc6057>。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <http://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y。、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<http：//www.rfc- editor.org/info/rfc6928>。
[RFC7141] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141, February 2014, <http://www.rfc-editor.org/info/rfc7141>.
[RFC7141] Briscoe、B。およびJ. Manner、「Byte and Packet Congestion Notification」、BCP 41、RFC 7141、DOI 10.17487 / RFC7141、2014年2月、<http://www.rfc-editor.org/info/rfc7141 >。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<http://www.rfc-editor.org/info/rfc7567>。
[SFQ] Mckenney, P., "Stochastic Fairness Queuing", Proceedings of IEEE INFOCOM '90, Volume 2, pp. 733-740, DOI 10.1109/INFCOM.1990.91316, June 1990, <http://www2.rdrop.com/~paulmck/scalability/paper/ sfq.2002.06.04.pdf>.
[SFQ] Mckenney、P。、「Stochastic Fairness Queuing」、Proceedings of IEEE INFOCOM '90、Volume 2、pp。733-740、DOI 10.1109 / INFCOM.1990.91316、June 1990、<http://www2.rdrop.com /〜paulmck / scalability / paper / sfq.2002.06.04.pdf>。
[VirtualClock] Zhang, L., "VirtualClock: A New Traffic Control Algorithm for Packet Switching Networks", Proceedings of the ACM Symposium on Communications Architectures and Protocols, Volume 20, DOI 10.1145/99508.99525, September 1990, <http://dl.acm.org/citation.cfm?id=99508.99525>.
[VirtualClock] Zhang、L.、 "VirtualClock：A New Traffic Control Algorithm for Packet Switching Networks"、Proceedings of the ACM Symposium on Communications Architectures and Protocols、Volume 20、DOI 10.1145 / 99508.99525、September 1990、<http：// dl .acm.org / citation.cfm？id = 99508.99525>。
Acknowledgements
謝辞
This note grew out of, and is in response to, mailing list discussions in AQM, in which some have pushed an algorithm to compare to AQM marking and dropping algorithms, but which includes flow queuing.
このメモは、AQMでのメーリングリストのディスカッションから発展したものであり、AQMマーキングおよびドロップアルゴリズムと比較するアルゴリズムをプッシュしましたが、フローキューイングが含まれています。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 United States
Fred Baker Cisco Systemsサンタバーバラ、カリフォルニア93117アメリカ合衆国
Email: fred@cisco.com
Rong Pan Cisco Systems Milpitas, California 95035 United States
Rong Pan Cisco Systems Milpitas、California 95035 United States
Email: ropan@cisco.com