[要約] RFC 9957は、DOCSIS 3.1技術に導入されたキュー保護（QProt）アルゴリズムの仕様と設計思想を説明する情報提供目的の文書です。共有低遅延キューにおいて、一部のフローがキューを構築する動作をとった場合に、その影響を迅速に検出しクラシックキューに再分類することで、他の低遅延トラフィックを保護します。
Independent Submission B. Briscoe, Ed.
Request for Comments: 9957 Independent
Category: Informational G. White
ISSN: 2070-1721 CableLabs
May 2026
This Informational RFC explains the specification of the queue protection algorithm introduced into Data-Over-Cable Service Interface Specification (DOCSIS) technology at version 3.1. A shared low-latency queue relies on the non-queue-building behaviour of every traffic flow using it. However, some flows might not take such care, either accidentally or maliciously. If a queue is about to exceed a threshold level of delay, the Queue Protection algorithm can rapidly detect the flows most likely to be responsible. It can then prevent harm to other traffic in the low-latency queue by ejecting selected packets (or all packets) of these flows. This document is designed for four audiences: a) congestion control designers who need to understand how to keep on the "good" side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm.
この情報 RFC では、バージョン 3.1 で Data-Over-Cable Service Interface Supplemental (DOCSIS) テクノロジーに導入されたキュー保護アルゴリズムの仕様について説明します。共有低遅延キューは、それを使用するすべてのトラフィック フローの非キュー構築動作に依存します。ただし、一部のフローでは、偶然または悪意により、そのような注意が払われない場合があります。キューが遅延のしきい値レベルを超えようとしている場合、キュー保護アルゴリズムは原因となっている可能性が最も高いフローを迅速に検出できます。これらのフローの選択されたパケット (またはすべてのパケット) を排出することで、低遅延キュー内の他のトラフィックへの被害を防ぐことができます。このドキュメントは 4 つの対象読者を対象としています。a) アルゴリズムの「良い」側を維持する方法を理解する必要がある輻輳制御設計者。b) アルゴリズムをより深く理解したいと考えているアルゴリズムの実装者。c) おそらく非 DOCSIS シナリオ向けの、同様の目標を持つアルゴリズムの設計者。d) アルゴリズムの評価に興味のある研究者。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他の RFC ストリームとは独立した、RFC シリーズへの貢献です。RFC 編集者は独自の裁量でこの文書を公開することを選択しており、実装または展開におけるこの文書の価値については何も述べていません。RFC 編集者によって出版が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9957.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9957 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。
1. Introduction
1.1. Document Roadmap
1.2. Terminology
1.3. Source Material
2. Approach (In Brief)
2.1. Mechanism
2.2. Policy
2.2.1. Policy Conditions
2.2.2. Policy Action
3. Necessary Flow Behaviour
4. Pseudocode Walk-Through
4.1. Input Parameters, Constants, and Variables
4.2. QProt Data Path
4.2.1. The qprotect() Function
4.2.2. The pick_bucket() Function
4.2.3. The fill_bucket() Function
4.2.4. The calcProbNative() Function
5. Rationale
5.1. Rationale: Blame for Queuing, Not for Rate in Itself
5.2. Rationale: Constant Aging of the Queuing Score
5.3. Rationale: Transformed Queuing Score
5.4. Rationale: Policy Conditions
5.5. Rationale: Reclassification as the Policy Action
6. Limitations
7. IANA Considerations
8. Security Considerations
8.1. Resource Exhaustion Attacks
8.1.1. Exhausting Flow State Storage
8.1.2. Exhausting Processing Resources
9. Comments Solicited
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
This Informational RFC explains the specification of the queue protection (QProt) algorithm introduced into DOCSIS technology at version 3.1 [DOCSIS].
この情報 RFC では、バージョン 3.1 [DOCSIS] で DOCSIS テクノロジーに導入されたキュー保護 (QProt) アルゴリズムの仕様について説明します。
Although the algorithm is defined in Annex P of [DOCSIS], it relies on cross references to other parts of the set of specifications. This document pulls all the strands together into one self-contained document. The core of the document is a similar pseudocode walk-through to that in the DOCSIS specification, but it also includes additional material:
このアルゴリズムは [DOCSIS] の付録 P で定義されていますが、一連の仕様の他の部分への相互参照に依存しています。この文書は、すべての要素を 1 つの自己完結型文書にまとめたものです。この文書の中核は、DOCSIS 仕様と同様の疑似コードのウォークスルーですが、追加の資料も含まれています。
i. a brief overview,
i. 簡単な概要、
ii. a definition of how a data sender needs to behave to avoid triggering queue protection, and
ii.キュー保護のトリガーを回避するためにデータ送信者がどのように動作する必要があるかの定義、および
iii. a section giving the rationale for the design choices.
iii.設計上の選択の理論的根拠を示すセクション。
Low queuing delay depends on hosts sending their data smoothly, either at a low rate or responding to Explicit Congestion Notification (ECN) (see [RFC8311] and [RFC9331]). Therefore, low-latency queuing is something hosts create themselves, not something the network gives them. This tends to ensure that self-interest alone does not drive flows to mismark their packets for the low-latency queue. However, traffic from an application that does not behave in a non-queue-building way might erroneously be classified into a low-latency queue, whether accidentally or maliciously. QProt protects other traffic in the low-latency queue from the harm due to excess queuing that would otherwise be caused by such anomalous behaviour.
キューイング遅延が低いかどうかは、ホストが低速で、または明示的輻輳通知 (ECN) に応答してデータをスムーズに送信するかどうかに依存します ([RFC8311] および [RFC9331] を参照)。したがって、低遅延キューはホストが自ら作成するものであり、ネットワークが提供するものではありません。これにより、自己利益だけでフローがパケットを低遅延キューに誤ってマークすることがなくなる傾向があります。ただし、キュー構築以外の方法で動作しないアプリケーションからのトラフィックは、偶然か悪意かにかかわらず、誤って低遅延キューに分類される可能性があります。QProt は、低遅延キュー内の他のトラフィックを、そのような異常な動作によって引き起こされる過剰なキューイングによる害から保護します。
In normal scenarios without misclassified traffic, QProt is not expected to intervene at all in the classification or forwarding of packets.
トラフィックが誤って分類されない通常のシナリオでは、QProt はパケットの分類や転送にまったく介入することは期待されません。
An overview of how low-latency support has been added to DOCSIS technology is given in [LLD]. In each direction of a DOCSIS link (upstream and downstream), there are two queues: one for Low-Latency (LL) and one for Classic traffic, in an arrangement similar to the IETF's Dual-Queue Coupled Active Queue Management (AQM) [RFC9332]. The two queues enable a transition from "Classic" to "Scalable" congestion control so that low latency can become the norm for any application, including ones seeking both full throughput and low latency, not just low-rate applications that have been more traditionally associated with a low-latency service. The Classic queue is only necessary for traffic such as traditional (Reno [RFC5681] / Cubic [RFC9438]) TCP that needs about a round trip of buffering to fully utilize the link; therefore, this traffic has no incentive to mismark itself as low latency. The QProt function is located at the ingress to the Low-Latency queue. Therefore, in the upstream, QProt is located on the cable modem (CM); in the downstream, it is located on the CM Termination System (CMTS). If an arriving packet triggers queue protection, the QProt algorithm ejects the packet from the Low-Latency queue and reclassifies it into the Classic queue.
低遅延サポートが DOCSIS テクノロジーにどのように追加されるかについての概要は、[LLD] に記載されています。DOCSIS リンクの各方向（アップストリームとダウンストリーム）には 2 つのキューがあります。1 つは低遅延（LL）用、もう 1 つはクラシック トラフィック用で、IETF のデュアル キュー結合アクティブ キュー管理（AQM）[RFC9332] と同様の配置です。2 つのキューにより、「クラシック」から「スケーラブル」輻輳制御への移行が可能になるため、従来より低遅延サービスと関連付けられてきた低レート アプリケーションだけでなく、フル スループットと低遅延の両方を求めるアプリケーションも含め、あらゆるアプリケーションで低遅延が標準となります。Classic キューは、リンクを完全に利用するために約往復のバッファリングを必要とする従来の (Reno [RFC5681] / Cubic [RFC9438]) TCP などのトラフィックにのみ必要です。したがって、このトラフィックには、それ自体を低遅延として誤ってマークする動機はありません。QProt 関数は、低遅延キューの入口にあります。したがって、アップストリームでは、QProt はケーブル モデム (CM) 上に配置されます。ダウンストリームでは、CM Termination System（CMTS）上にあります。到着したパケットがキュー保護をトリガーした場合、QProt アルゴリズムはパケットを低遅延キューから取り出し、クラシック キューに再分類します。
If QProt is used in settings other than DOCSIS links, it would be a simple matter to detect queue-building flows by using slightly different conditions and/or to trigger a different action as a consequence, as appropriate for the scenario, e.g., dropping instead of reclassifying packets or perhaps accumulating a second per-flow score to decide whether to redirect a whole flow rather than just certain packets. Such work is for future study and out of scope of the present document.
QProt が DOCSIS リンク以外の設定で使用されている場合、シナリオに応じて、わずかに異なる条件を使用してキュー構築フローを検出したり、結果として別のアクションをトリガーしたりすることは簡単です。たとえば、パケットを再分類する代わりにドロップしたり、特定のパケットだけでなくフロー全体をリダイレクトするかどうかを決定するために 2 番目のフローごとのスコアを蓄積したりすることもあります。このような研究は将来の研究のためのものであり、本書の範囲外です。
The QProt algorithm is based on a rigorous approach to quantifying how much each flow contributes to congestion, which is used in economics to allocate responsibility for the cost of one party's behaviour on others (the economic externality). Another important feature of the approach is that the metric used for the queuing score is based on the same variable that determines the level of ECN signalling seen by the sender (see [RFC8311] and [RFC9331]). This makes the internal queuing score visible externally as ECN markings. This transparency is necessary to be able to objectively state (in Section 3) how a flow can keep on the "good" side of the algorithm.
QProt アルゴリズムは、各フローが輻輳にどの程度寄与しているかを定量化する厳密なアプローチに基づいています。これは、一方の当事者の行動のコストに対する責任を他方に割り当てるために経済学で使用されます (経済的外部性)。このアプローチのもう 1 つの重要な特徴は、キューイング スコアに使用されるメトリックが、送信者から見た ECN シグナリングのレベルを決定する同じ変数に基づいていることです ([RFC8311] および [RFC9331] を参照)。これにより、内部キュー スコアが ECN マーキングとして外部から見えるようになります。この透明性は、フローがどのようにアルゴリズムの「良い」側を維持できるかを (セクション 3 で) 客観的に述べることができるようにするために必要です。
The core of the document is the walk-through of the DOCSIS QProt algorithm's pseudocode in Section 4.
このドキュメントの中心となるのは、セクション 4 の DOCSIS QProt アルゴリズムの疑似コードのウォークスルーです。
Prior to that, Section 2 summarizes the approach used in the algorithm. Then, Section 3 considers QProt from the perspective of the end-system by defining the behaviour that a flow needs to comply with to avoid the QProt algorithm ejecting its packets from the low-latency queue.
その前に、セクション 2 でアルゴリズムで使用されるアプローチを要約します。次に、セクション 3 では、QProt アルゴリズムが低遅延キューからパケットを追い出すことを回避するためにフローが準拠する必要がある動作を定義することにより、エンドシステムの観点から QProt を検討します。
Section 5 gives deeper insight into the principles and rationale behind the algorithm. Then, Section 6 explains the limitations of the approach. The usual closing sections follow.
セクション 5 では、アルゴリズムの背後にある原理と理論的根拠についてさらに詳しく説明します。次に、セクション 6 でこのアプローチの制限について説明します。通常の終了セクションが続きます。
The normative language for the DOCSIS QProt algorithm is in the DOCSIS specifications [DOCSIS], [DOCSIS-CM-OSS], and [DOCSIS-CCAP-OSS]: not in this Informational RFC. If there is any inconsistency, the DOCSIS specifications take precedence.
DOCSIS QProt アルゴリズムの規範的な言語は、DOCSIS 仕様 [DOCSIS]、[DOCSIS-CM-OSS]、および [DOCSIS-CCAP-OSS] にありますが、この情報 RFC にはありません。矛盾がある場合は、DOCSIS 仕様が優先されます。
The following terms and abbreviations are used:
次の用語と略語が使用されます。
CM:
CM:
Cable Modem
ケーブルモデム
CMTS:
CMTS:
CM Termination System
CM終端システム
Congestion-rate:
混雑率:
The transmission rate counting only bits or bytes contained within packets of a flow that have the Congestion Experienced (CE) codepoint set in the IP-ECN field [RFC3168] (including IP headers unless specified otherwise). Congestion-bit-rate and congestion-volume were introduced in [RFC7713] and [RFC6789].
IP-ECN フィールド [RFC3168] に設定された Congestion Experienced (CE) コードポイントを持つフローのパケット内に含まれるビットまたはバイトのみをカウントする送信速度 (特に指定がない限り、IP ヘッダーを含む)。輻輳ビットレートと輻輳ボリュームは [RFC7713] と [RFC6789] で導入されました。
DOCSIS:
文書:
Data-Over-Cable Service Interface Specification. "DOCSIS" is a registered trademark of Cable Television Laboratories, Inc. ("CableLabs").
データ オーバー ケーブル サービス インターフェイスの仕様。「DOCSIS」は、Cable Television Laboratories, Inc. (「CableLabs」) の登録商標です。
QProt:
Qプロット:
The DOCSIS Queue Protection function
DOCSISキュー保護機能
non-queue-building:
非キュー構築:
A flow that tends not to build a queue.
行列ができにくい流れ。
Note the use of lowercase "non-queue-building", which describes the behaviour of a flow, in contrast to uppercase Non-Queue-Building (NQB), which refers to a Diffserv marking [RFC9956]. A flow identifying itself as uppercase NQB may not, in fact, behave in a non-queue-building way, which is what the QProt algorithm is intended to detect.
Diffserv マーキング [RFC9956] を指す大文字の Non-Queue-Building (NQB) とは対照的に、フローの動作を説明する小文字の「non-queue-building」を使用していることに注意してください。自分自身を大文字の NQB として識別するフローは、実際にはキューを構築しない方法で動作しない可能性があります。これは、QProt アルゴリズムが検出することを目的としています。
queue-building:
キュー構築:
A flow that builds a queue. If it is classified into the Low-Latency queue, it is therefore a candidate for the QProt algorithm to detect and sanction.
キューを構築するフロー。したがって、低レイテンシ キューに分類された場合、QProt アルゴリズムが検出して承認する対象となります。
ECN:
ECN:
Explicit Congestion Notification [RFC3168]
明示的な輻輳通知 [RFC3168]
ECN marking or ECN signalling:
ECN マーキングまたは ECN シグナリング:
Setting the IP-ECN field of an increasing proportion of packets to the Congestion Experienced (CE) codepoint [RFC3168] as queuing worsens.
キューイングが悪化するにつれて、増加するパケットの IP-ECN フィールドを Congestion Experienced (CE) コードポイント [RFC3168] に設定します。
Parts of this document are reproduced from [DOCSIS] with kind permission of Cable Television Laboratories, Inc. ("CableLabs").
この文書の一部は、Cable Television Laboratories, Inc. (以下「CableLabs」) の許可を得て [DOCSIS] から転載されています。
The QProt algorithm is divided into mechanism and policy. There is only a tiny amount of policy code, but policy might need to be changed in the future. So, where hardware implementation is being considered, it would be advisable to implement the policy aspects in firmware or software:
QProt アルゴリズムはメカニズムとポリシーに分かれています。ポリシー コードの量はごくわずかですが、将来的にポリシーの変更が必要になる可能性があります。したがって、ハードウェアの実装を検討している場合は、ファームウェアまたはソフトウェアでポリシーの側面を実装することをお勧めします。
* The mechanism aspects identify flows, maintain flow state, and accumulate per-flow queuing scores;
* メカニズムの側面では、フローを識別し、フロー状態を維持し、フローごとのキューイング スコアを蓄積します。
* The policy aspects can be divided into conditions and actions:
* ポリシーの側面は、条件とアクションに分類できます。
- The conditions are the logic that determines when action should be taken to avert the risk of queuing delay becoming excessive;
- 条件は、キュー遅延が過剰になるリスクを回避するためにいつアクションを実行するかを決定するロジックです。
- The actions determine how this risk is averted, e.g., by redirecting packets from a flow into another queue or by reclassifying a whole flow that seems to be misclassified.
- アクションは、パケットをフローから別のキューにリダイレクトするか、誤って分類されたと思われるフロー全体を再分類するなど、このリスクを回避する方法を決定します。
The algorithm maintains per-flow state, where "flow" usually means an end-to-end (Layer 4) 5-tuple. The flow state consists of a queuing score that decays over time. Indeed, it is transformed into time units so that it represents the flow state's own expiry time (explained in Section 5.3). A higher queuing score pushes out the expiry time further.
アルゴリズムはフローごとの状態を維持します。ここで、「フロー」とは通常、エンドツーエンド (レイヤー 4) の 5 タプルを意味します。フロー状態は、時間の経過とともに減衰するキュー スコアで構成されます。実際、これはフロー状態自体の有効期限を表すように時間単位に変換されます (セクション 5.3 で説明)。キュー スコアが高くなると、有効期限がさらに長くなります。
Non-queue-building flows tend to release their flow state rapidly: it usually expires reasonably early in the gap between the packets of a normal flow. Then, the memory can be recycled for packets from other flows that arrive in-between. Thus, only queue-building flows hold flow state persistently.
キューを構築しないフローは、フロー状態を急速に解放する傾向があります。通常、通常のフローのパケット間のギャップのかなり早い段階で期限切れになります。その後、中間に到着する他のフローからのパケットのためにメモリを再利用できます。したがって、キュー構築フローのみがフロー状態を永続的に保持します。
The simplicity and effectiveness of the algorithm is due to the definition of the queuing score. The queueing score represents the share of blame for queuing that each flow bears. The scoring algorithm uses the same internal variable, probNative, that the AQM for the low-latency queue uses to ECN-mark packets. (The other two forms of marking, Classic and coupled, are driven by Classic traffic; therefore, they are not relevant to protection of the LL queue). In this way, the queuing score accumulates the size of each arriving packet of a flow but scaled by the value of probNative (in the range 0 to 1) at the instant the packet arrives. Therefore, a flow's score accumulates faster:
アルゴリズムの単純さと有効性は、キュー スコアの定義によるものです。キューイング スコアは、各フローが負うキューイングの責任の割合を表します。スコアリング アルゴリズムは、低遅延キューの AQM がパケットを ECN マークするために使用するのと同じ内部変数 probNative を使用します。(他の 2 つのマーキング形式、クラシックおよび結合は、クラシック トラフィックによって駆動されるため、LL キューの保護には関係ありません)。このようにして、キューイング スコアはフローの各到着パケットのサイズを累積しますが、パケットが到着した瞬間の probNative の値 (0 ～ 1 の範囲) によってスケールされます。したがって、フローのスコアはより速く蓄積されます。
* the higher the degree of queuing and
* キューイングの度合いが高くなるほど、
* the faster the flow's packets arrive when there is queuing.
* キューがある場合、フローのパケットの到着が速くなります。
Section 5.1 explains further why this score represents blame for queuing.
セクション 5.1 では、このスコアがキューイングの責任を表す理由をさらに説明します。
Thus, the algorithm accumulates a queuing score that would rise at the so-called congestion-rate of the flow (see Section 1.2), i.e., the rate at which the flow is contributing to congestion or the rate at which the AQM is forwarding bytes of the flow that are ECN-marked. However, rather than growing continually, the queuing score is also reduced (or "aged") at a constant rate. This is because it is unavoidable for capacity-seeking flows to induce a continuous low level of congestion as they track available capacity. Section 5.2 explains why this allowance can be set to the same constant for any scalable flow, whatever its bit rate. As a result, the queuing score rises (or falls) according to the difference between the congestion-rate of the flow and the allowed aging rate.
したがって、アルゴリズムは、フローのいわゆる輻輳率 (セクション 1.2 を参照)、つまり、フローが輻輳に寄与している率、または AQM が ECN マークが付いているフローのバイトを転送している率で上昇するキューイング スコアを蓄積します。ただし、キュー スコアも継続的に増加するのではなく、一定の割合で減少 (または「老化」) します。これは、容量を求めるフローが利用可能な容量を追跡する際に、継続的に低レベルの輻輳を引き起こすことが避けられないためです。セクション 5.2 では、ビット レートに関係なく、スケーラブルなフローに対してこの許容値を同じ定数に設定できる理由を説明します。その結果、フローの輻輳率と許容エージング率の差に応じて、キューイング スコアが上昇（または下降）します。
For implementation efficiency, the queuing score is transformed into time units. It then represents the expiry time of the flow state (as already discussed above). Then, it does not need to be explicitly aged because the natural passage of time implicitly "ages" an expiry time. The transformation into time units simply involves dividing the queuing score of each packet by the constant aging rate (this is explained further in Section 5.3).
実装効率を高めるために、キューイング スコアは時間単位に変換されます。これは、(すでに上で説明したように) フロー状態の有効期限を表します。その場合、自然な時間の経過によって暗黙的に有効期限が「老化」するため、明示的に老化させる必要はありません。時間単位への変換には、各パケットのキュー スコアを一定のエージング レートで割ることが含まれます (これについてはセクション 5.3 で詳しく説明します)。
The algorithm uses the queuing score to determine whether to eject each packet only at the time it first arrives. This limits the policies available. For instance, when queueing delay exceeds a threshold, it is not feasible to eject a packet from the flow with the highest queuing score because that would involve searching the queue for such a packet (if, indeed, one were still in the queue). Nonetheless, it is still possible to develop a policy that protects the low latency of the queue by making the queuing score threshold stricter the greater the excess of queuing delay relative to the threshold (this is explained in Section 5.4).
このアルゴリズムは、キューイング スコアを使用して、各パケットを最初に到着したときにのみ排出するかどうかを決定します。これにより、利用可能なポリシーが制限されます。たとえば、キューイング遅延がしきい値を超えた場合、最も高いキューイング スコアを持つフローからパケットを排出することは現実的ではありません。これは、キュー内でそのようなパケットを検索する必要があるためです (実際にまだキュー内にパケットがあった場合)。それにもかかわらず、しきい値に対するキュー遅延の超過が大きいほどキュー スコアのしきい値を厳しくすることで、キューの低遅延を保護するポリシーを開発することは可能です (これについてはセクション 5.4 で説明します)。
At the time of writing, the DOCSIS QProt specification states that, when the policy conditions are met, the action taken to protect the low-latency queue is to reclassify a packet into the Classic queue (this is justified in Section 5.5).
執筆時点では、DOCSIS QProt 仕様では、ポリシー条件が満たされた場合、低遅延キューを保護するために実行されるアクションは、パケットをクラシック キューに再分類することであると記載されています (これはセクション 5.5 で正当化されています)。
The QProt algorithm described here can be used for responsive and/or unresponsive flows.
ここで説明する QProt アルゴリズムは、応答性および/または非応答性のフローに使用できます。
* It is possible to objectively describe the least responsive way that a flow will need to respond to congestion signals in order to avoid triggering queue protection, no matter the link capacity and no matter how much other traffic there is.
* リンク容量や他のトラフィックの量に関係なく、キュー保護のトリガーを回避するためにフローが輻輳信号に応答する必要がある最も応答性の低い方法を客観的に記述することができます。
* It is not possible to describe how fast or smooth an unresponsive flow should be to avoid queue protection because this depends on how much other traffic there is and the capacity of the link, which an application is unable to know. However, the more smoothly an unresponsive flow paces its packets and the lower its rate relative to typical broadband link capacities, the less likelihood that it will risk causing enough queueing to trigger queue protection.
* キュー保護を回避するために応答しないフローがどのくらい速くまたはスムーズであるかを説明することはできません。これは、他のトラフィックの量とリンクの容量に依存し、アプリケーションはそれを知ることができないためです。ただし、応答しないフローがよりスムーズにパケットのペーシングを行い、一般的なブロードバンド リンク容量と比較してそのレートが低いほど、キュー保護をトリガーするのに十分なキューが発生する危険性が低くなります。
Responsive low-latency flows can use a Low Latency, Low Loss, and Scalable throughput (L4S) ECN codepoint [RFC9331] to get classified into the low-latency queue.
応答性の高い低遅延フローは、低遅延、低損失、スケーラブル スループット (L4S) ECN コードポイント [RFC9331] を使用して、低遅延キューに分類できます。
A sender can arrange for flows that are smooth but do not respond to ECN marking to be classified into the low-latency queue by using the Non-Queue-Building (NQB) Diffserv codepoint [RFC9956], which the DOCSIS specifications support, or an operator can use various other local classifiers.
送信者は、DOCSIS 仕様がサポートする Non-Queue-Building (NQB) Diffserv コードポイント [RFC9956] を使用して、スムーズであるが ECN マーキングに応答しないフローを低遅延キューに分類できるように手配したり、オペレーターが他のさまざまなローカル分類子を使用したりできます。
As already explained in Section 2.1, the QProt algorithm is driven from the same variable that drives the ECN-marking probability in the Low-Latency or "LL" queue (the "Native" AQM of the LL queue is defined in the Immediate Active Queue Management Annex of [DOCSIS]). The algorithm that calculates this internal variable is run on the arrival of every LL packet, whether or not it is ECN-capable, so that it can be used by the QProt algorithm. But the variable is only used to ECN-mark packets that are ECN-capable.
セクション 2.1 ですでに説明したように、QProt アルゴリズムは、低レイテンシーまたは「LL」キューの ECN マーキング確率を駆動する同じ変数から駆動されます (LL キューの「ネイティブ」AQM は、[DOCSIS] の即時アクティブ キュー管理付録で定義されています)。この内部変数を計算するアルゴリズムは、ECN 対応かどうかに関係なく、すべての LL パケットの到着時に実行されるため、QProt アルゴリズムで使用できます。ただし、この変数は、ECN 対応のパケットを ECN マークするためにのみ使用されます。
Not only does this dual use of the variable improve processing efficiency, but it also makes the basis of the QProt algorithm visible and transparent, at least for responsive ECN-capable flows. Then, it is possible to state objectively that a flow can avoid triggering queue protection by keeping the bit rate of ECN-marked packets (the congestion-rate) below AGING, which is a configured constant of the algorithm (default 2^19 B/s ≈ 4 Mb/s). Note that it is in a congestion controller's own interest to keep its average congestion-rate well below this level (e.g., ~1 Mb/s) to ensure that it does not trigger queue protection during transient dynamics.
この変数の二重使用により、処理効率が向上するだけでなく、少なくとも応答性の高い ECN 対応フローに関しては、QProt アルゴリズムの基礎が可視化され、透明になります。次に、ECN マーク付きパケットのビット レート (輻輳率) を、アルゴリズムの設定定数 (デフォルトは 2^19 B/s ≈ 4 Mb/s) である AGING 未満に保つことで、フローがキュー保護のトリガーを回避できると客観的に述べることができます。過渡的なダイナミクス中にキュー保護がトリガーされないようにするために、平均輻輳率をこのレベル (たとえば、~1 Mb/s) よりも十分に下回るように維持することが、輻輳コントローラ自身の利益になることに注意してください。
If the QProt algorithm is used in other settings, it would still need to be based on the visible level of congestion signalling, in a similar way to the DOCSIS approach. Without transparency of the basis of the algorithm's decisions, end-systems would not be able to avoid triggering queue protection on an objective basis.
QProt アルゴリズムが他の設定で使用される場合でも、DOCSIS アプローチと同様の方法で、目に見えるレベルの輻輳シグナリングに基づく必要があります。アルゴリズムの決定の基礎が透明性がなければ、エンドシステムは客観的な基準に基づいてキュー保護のトリガーを避けることができなくなります。
The operator input parameters that set the parameters in the first two blocks of pseudocode below are defined for cable modems (CMs) in [DOCSIS-CM-OSS] and for CMTSs in [DOCSIS-CCAP-OSS]. Then, further constants are either derived from the input parameters or hard-coded.
以下の疑似コードの最初の 2 つのブロックでパラメータを設定するオペレータ入力パラメータは、[DOCSIS-CM-OSS] ではケーブル モデム（CM）に対して、[DOCSIS-CCAP-OSS] では CMTS に対して定義されています。次に、追加の定数が入力パラメータから導出されるか、ハードコーディングされます。
Defaults and units are shown in square brackets. Defaults (or indeed any aspect of the QProt algorithm) are subject to change, so the latest DOCSIS specifications are the definitive references. Also, any operator might set certain parameters to non-default values.
デフォルトと単位は角括弧内に示されています。デフォルト (または実際には QProt アルゴリズムのあらゆる側面) は変更される可能性があるため、最新の DOCSIS 仕様が最終的なリファレンスとなります。また、オペレータは特定のパラメータをデフォルト以外の値に設定する可能性があります。
// Input Parameters
MAX_RATE; // Configured maximum sustained rate [b/s]
QPROTECT_ON; // Queue Protection is enabled [Default: TRUE]
CRITICALqL_us; // LL queue threshold delay [µs] Default: MAXTH_us
CRITICALqLSCORE_us;// The threshold queuing score [Default: 4000 µs]
LG_AGING; // The aging rate of the q'ing score [Default: 19]
// as log base 2 of the congestion-rate [lg(B/s)]
// Input Parameters for the calcProbNative() algorithm:
MAXTH_us; // Max LL AQM marking threshold [Default: 1000 µs]
LG_RANGE; // Log base 2 of the range of ramp [lg(ns)]
// Default: 2^19 = 524288 ns (roughly 525 µs)
// Constants, either derived from input parameters or hard-coded
T_RES; // Resolution of t_exp [ns]
// Convert units (approx)
AGING = pow(2, (LG_AGING-30) ) * T_RES; // lg([B/s]) to [B/T_RES]
CRITICALqL = CRITICALqL_us * 1000; // [µs] to [ns]
CRITICALqLSCORE = CRITICALqLSCORE_us * 1000/T_RES; // [µs] to [T_RES]
// Threshold for the q'ing score condition
CRITICALqLPRODUCT = CRITICALqL * CRITICALqLSCORE;
qLSCORE_MAX = 5E9 / T_RES; // Max queuing score = 5 s
ATTEMPTS = 2; // Max attempts to pick a bucket (vendor-specific)
BI_SIZE = 5; // Bit-width of index number for non-default buckets
NBUCKETS = pow(2, BI_SIZE); // No. of non-default buckets
MASK = NBUCKETS-1; // convenient constant, with BI_SIZE LSBs set
// Queue Protection exit states
EXIT_SUCCESS = 0; // Forward the packet
EXIT_SANCTION = 1; // Redirect the packet
MAX_PROB = 1; // For integer arithmetic, would use a large int
// e.g., 2^31, to allow space for overflow
MAXTH = MAXTH_us * 1000; // Max marking threshold [ns]
MAX_FRAME_SIZE = 2000; // DOCSIS-wide constant [B]
// Minimum marking threshold of 2 MTU for slow links [ns]
FLOOR = 2 * 8 * MAX_FRAME_SIZE * 10^9 / MAX_RATE;
RANGE = (1 << LG_RANGE); // Range of ramp [ns]
MINTH = max ( MAXTH - RANGE, FLOOR);
MAXTH = MINTH + RANGE; // Max marking threshold [ns]
Throughout the pseudocode, most variables are integers. The only exceptions are floating-point variables representing probabilities (MAX_PROB and probNative) and the AGING parameter. The actual DOCSIS QProt algorithm is defined using integer arithmetic, but in the floating-point arithmetic used in this document, 0 <= probNative <= 1. Also, the pseudocode omits overflow checking and it would need to be made robust to non-default input parameters.
疑似コード全体を通じて、ほとんどの変数は整数です。唯一の例外は、確率を表す浮動小数点変数 (MAX_PROB および probNative) と AGING パラメーターです。実際の DOCSIS QProt アルゴリズムは整数演算を使用して定義されていますが、このドキュメントで使用されている浮動小数点演算では、0 <= probNative <= 1 です。また、擬似コードはオーバーフロー チェックを省略しているため、デフォルト以外の入力パラメータに対して堅牢にする必要があります。
The resolution for expressing time, T_RES, needs to be chosen to ensure that expiry times for buckets can represent times that are a fraction (e.g., 1/10) of the expected packet interarrival time for the system.
時間を表現するための解像度 T_RES は、バケットの有効期限がシステムの予想されるパケット到着間隔時間の一部 (たとえば、1/10) の時間を表現できるように選択する必要があります。
The following definitions explain the purpose of important variables and functions.
次の定義では、重要な変数と関数の目的を説明します。
// Public variables:
qdelay; // The current queuing delay of the LL queue [ns]
probNative; // Native marking probability of LL queue within [0,1]
// External variables
packet; // The structure holding packet header fields
packet.size; // The size of the current packet [B]
packet.uflow; // The flow identifier of the current packet
// (e.g., 5-tuple or 4-tuple if IPsec)
// Irrelevant details of DOCSIS function to return qdelay are removed
qdelayL(...) // Returns current delay of the low-latency Q [ns]
Pseudocode for how the algorithm categorizes packets by flow ID to populate the variable packet.uflow is not given in detail here. The application's flow ID is usually defined by a common 5-tuple (or 4-tuple) of:
アルゴリズムがフロー ID によってパケットを分類して変数 packet.uflow を設定する方法の疑似コードについては、ここでは詳しく説明しません。アプリケーションのフロー ID は通常、次の共通の 5 タプル (または 4 タプル) で定義されます。
* source and destination IP addresses of the innermost IP header found;
* 見つかった最も内側の IP ヘッダーの送信元および宛先 IP アドレス。
* the protocol (IPv4) or next header (IPv6) field in this IP header
* この IP ヘッダーのプロトコル (IPv4) または次のヘッダー (IPv6) フィールド
* either of:
* 次のいずれか:
- source and destination port numbers, for TCP, UDP, UDP-Lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), etc.
- TCP、UDP、UDP-Lite、ストリーム制御伝送プロトコル (SCTP)、データグラム輻輳制御プロトコル (DCCP) などの送信元ポート番号と宛先ポート番号。
- Security Parameter Index (SPI) for IPsec Encapsulating Security Payload (ESP) [RFC4303].
- IPsec カプセル化セキュリティ ペイロード (ESP) のセキュリティ パラメータ インデックス (SPI) [RFC4303]。
The Microflow Classification section of the Queue Protection Annex of the DOCSIS specification [DOCSIS] defines various strategies to find these headers by skipping extension headers or encapsulations. If they cannot be found, the specification defines various less-specific 3-tuples that would be used. The DOCSIS specification should be referred to for all these strategies, which will not be repeated here.
DOCSIS 仕様 [DOCSIS] のキュー保護付録のマイクロフロー分類セクションでは、拡張ヘッダーやカプセル化をスキップしてこれらのヘッダーを見つけるためのさまざまな戦略が定義されています。それらが見つからない場合、仕様では使用される、あまり具体的ではないさまざまな 3 タプルが定義されています。これらすべての戦略については DOCSIS 仕様を参照する必要がありますが、ここでは繰り返しません。
The array of bucket structures defined below is used by all the QProt functions:
以下に定義されているバケット構造の配列は、すべての QProt 関数で使用されます。
struct bucket { // The leaky bucket structure to hold per-flow state
id; // identifier (e.g., 5-tuple) of flow using bucket
t_exp; // expiry time in units of T_RES
// (t_exp - now) = flow's transformed q'ing score
};
struct bucket buckets[NBUCKETS+1];
All the functions of QProt operate on the data path, driven by packet arrivals.
QProt のすべての機能は、パケットの到着によって駆動されてデータ パス上で動作します。
The following functions that maintain per-flow queuing scores and manage per-flow state are considered primarily as mechanism:
フローごとのキューイング スコアを維持し、フローごとの状態を管理する次の機能は、主にメカニズムとして考慮されます。
pick_bucket(uflow_id); // Returns bucket identifier
fill_bucket(bucket_id, pkt_size, probNative); /* Returns queuing
* score */
calcProbNative(qdelay); /* Returns ECN-marking probability of the
* Native LL AQM */
The following function is primarily concerned with policy:
次の機能は主にポリシーに関係します。
qprotect(packet, ...); /* Returns exit status to either forward
* or redirect the packet */
('...' suppresses distracting detail.)
(「...」は気を散らす詳細を抑制します。)
Future modifications to policy aspects are more likely than modifications to mechanisms. Therefore, policy aspects would be less appropriate candidates for any hardware acceleration.
将来的には、メカニズムの変更よりも政策の側面が変更される可能性が高くなります。したがって、ポリシーの側面は、ハードウェア アクセラレーションの候補としてはあまり適切ではありません。
The entry point to these functions is qprotect(), which is called after packet classification and AQM (including ECN marking) yet before each packet is enqueued into the appropriate queue, queue_id, as follows:
これらの関数へのエントリ ポイントは qprotect() です。これは、パケットの分類と AQM (ECN マーキングを含む) の後、各パケットが適切なキュー queue_id にエンキューされる前に、次のように呼び出されます。
classifier(packet) {
// Determine which queue using ECN, DSCP, and any local-use fields
queue_id = classify(packet);
// LQ & CQ are macros for valid queue IDs returned by classify()
if (queue_id == LQ) {
// if packet classified to Low-Latency Service Flow
aqm_mark(packet); // apply ECN marking, as needed based on AQM
if (QPROTECT_ON) {
if (qprotect(packet, ...) == EXIT_SANCTION) {
// redirect packet to Classic Service Flow
queue_id = CQ;
}
}
return queue_id;
}
On each packet arrival at the Low-Latency (LL) queue, qprotect() measures the current delay of the LL queue and derives the Native LL marking probability from it. Then, it uses pick_bucket to find the bucket already holding the flow's state or to allocate a new bucket if the flow is new or its state has expired (the most likely case). Then, the queuing score is updated by the fill_bucket() function. That completes the mechanism aspects.
パケットが低遅延 (LL) キューに到着するたびに、qprotect() は LL キューの現在の遅延を測定し、そこからネイティブ LL マーキング確率を導き出します。次に、pick_bucket を使用して、フローの状態をすでに保持しているバケットを検索するか、フローが新しい場合、またはその状態が期限切れになっている場合 (最も可能性の高いケース)、新しいバケットを割り当てます。次に、fill_bucket() 関数によってキューイング スコアが更新されます。これでメカニズムの部分は完了です。
The comments against the subsequent policy conditions and actions should be self-explanatory at a superficial level. The deeper rationale for these conditions is given in Section 5.4.
その後の政策条件や行動に対するコメントは、表面的なレベルでは自明であるべきです。これらの条件のより深い理論的根拠は、セクション 5.4 で説明されています。
// Per-packet Queue Protection
qprotect(packet, ...) {
bckt_id; // bucket index
qLscore; // queuing score of pkt's flow in units of T_RES
qdelay = qL.qdelay(...);
probNative = calcProbNative(qdelay);
bckt_id = pick_bucket(packet.uflow);
qLscore = fill_bucket(buckets[bckt_id], packet.size, probNative);
// Determine whether to sanction packet
if ( ( ( qdelay > CRITICALqL ) // Test if qdelay over threshold...
// ...and if flow's q'ing score scaled by qdelay/CRITICALqL
// ...exceeds CRITICALqLSCORE
&& ( qdelay * qLscore > CRITICALqLPRODUCT ) )
// or qLSCORE_MAX reached
|| ( qLscore >= qLSCORE_MAX ) )
return EXIT_SANCTION;
else
return EXIT_SUCCESS;
}
The pick_bucket() function is optimized for flow state that will normally have expired from packet to packet of the same flow. It is just one way of finding the bucket associated with the flow ID of each packet: it might be possible to develop more efficient alternatives.
pick_bucket() 関数は、通常、同じフローのパケットごとに期限切れになるフロー状態に合わせて最適化されています。これは、各パケットのフロー ID に関連付けられたバケットを見つける方法の 1 つにすぎません。より効率的な代替手段を開発できる可能性があります。
The algorithm is arranged so that the bucket holding any live (non-expired) flow state associated with a packet will always be found before a new bucket is allocated. The constant ATTEMPTS, defined earlier, determines how many hashes are used to find a bucket for each flow. (Actually, only one hash is generated; then, by default, 5 bits of it at a time are used as the hash value because, by default, there are 2^5 = 32 buckets).
このアルゴリズムは、パケットに関連付けられたライブ (有効期限が切れていない) フロー状態を保持するバケットが、新しいバケットが割り当てられる前に常に見つかるように構成されています。前に定義した定数 ATTEMPTS は、各フローのバケットを見つけるために使用されるハッシュの数を決定します。(実際には、生成されるハッシュは 1 つだけです。デフォルトでは 2^5 = 32 個のバケットがあるため、デフォルトでは一度に 5 ビットがハッシュ値として使用されます)。
The algorithm stores the flow's own ID in its flow state. So, when a packet of a flow arrives, the algorithm tries up to ATTEMPTS times to hash to a bucket, looking for the flow's own ID. If found, it uses that bucket, first resetting the expiry time to "now" if it has expired.
このアルゴリズムは、フロー自体の ID をフロー状態に保存します。そのため、フローのパケットが到着すると、アルゴリズムは最大 ATTEMPTS 回までバケットへのハッシュを試行し、フロー自身の ID を探します。見つかった場合は、そのバケットを使用し、有効期限が切れている場合は、まず有効期限を「現在」にリセットします。
If it does not find the flow's ID, and the expiry time is still current, the algorithm can tell that another flow is using that bucket, and it continues to look for a bucket for the flow. Even if it finds another flow's bucket where the expiry time has passed, it doesn't immediately use it. It merely remembers it as the potential bucket to use. But first it runs through all the ATTEMPTS hashes to look for a bucket assigned to the flow ID. Then, if a live bucket is not already associated with the packet's flow, the algorithm should have already set aside an existing bucket with a score that has aged out. Given this bucket is no longer necessary to hold state for its previous flow, it can be recycled for use by the present packet's flow.
フローの ID が見つからず、有効期限がまだ現在の場合、アルゴリズムは別のフローがそのバケットを使用していることを認識し、フローのバケットの検索を続けます。有効期限が過ぎた別のフローのバケットが見つかった場合でも、それはすぐには使用されません。使用する可能性のあるバケットとしてそれを記憶しているだけです。ただし、最初にすべての ATTEMPTS ハッシュを実行して、フロー ID に割り当てられたバケットを探します。次に、ライブ バケットがまだパケットのフローに関連付けられていない場合、アルゴリズムは期限切れになったスコアを持つ既存のバケットをすでに確保しているはずです。このバケットは以前のフローの状態を保持する必要がなくなったため、現在のパケットのフローで使用するためにリサイクルできます。
If all else fails, there is one additional bucket (called the dregs) that can be used. If the dregs is still in live use by another flow, subsequent flows that cannot find a bucket of their own all share it, adding their score to the one in the dregs. A flow might get away with using the dregs on its own, but when there are many mismarked flows, multiple flows are more likely to collide in the dregs, including innocent flows. The choice of number of buckets and number of hash attempts determines how likely it will be that this undesirable scenario will occur.
他のすべてが失敗した場合は、使用できる追加のバケット (残骸と呼ばれます) が 1 つあります。残りが別のフローによってまだライブで使用されている場合、独自のバケットを見つけることができない後続のフローはすべてそのバケットを共有し、そのスコアを残りのフローに追加します。フローは単独で残渣を使用することで問題を解決できる可能性がありますが、マークが間違っているフローが多数ある場合、無害なフローを含む複数のフローが残骸内で衝突する可能性が高くなります。バケットの数とハッシュの試行回数の選択によって、この望ましくないシナリオが発生する可能性が決まります。
// Pick the bucket associated with flow uflw
pick_bucket(uflw) {
now; // current time
j; // loop counter
h32; // holds hash of the packet's flow IDs
h; // bucket index being checked
hsav; // interim chosen bucket index
h32 = hash32(uflw); // 32-bit hash of flow ID
hsav = NBUCKETS; // Default bucket
now = get_time_now(); // in units of T_RES
// The for loop checks ATTEMPTS buckets for ownership by flow ID
// It also records the 1st bucket, if any, that could be recycled
// because it's expired.
// Must not recycle a bucket until all ownership checks completed
for (j=0; j<ATTEMPTS; j++) {
// Use least signif. BI_SIZE bits of hash for each attempt
h = h32 & MASK;
if (buckets[h].id == uflw) { // Once uflw's bucket found...
if (buckets[h].t_exp <= now) // ...if bucket has expired...
buckets[h].t_exp = now; // ...reset it
return h; // Either way, use it
}
else if ( (hsav == NBUCKETS) // If not seen expired bucket yet
// and this bucket has expired
&& (buckets[h].t_exp <= now) ) {
hsav = h; // set it as the interim bucket
}
h32 >>= BI_SIZE; // Bit-shift hash for next attempt
}
// If reached here, no tested bucket was owned by the flow ID
if (hsav != NBUCKETS) {
// If here, found an expired bucket within the above for loop
buckets[hsav].t_exp = now; // Reset expired bucket
} else {
// If here, we're having to use the default bucket (the dregs)
if (buckets[hsav].t_exp <= now) { // If dregs has expired...
buckets[hsav].t_exp = now; // ...reset it
}
}
buckets[hsav].id = uflw; // In either case, claim for recycling
return hsav;
}
The fill_bucket() function both accumulates and ages the queuing score over time, as outlined in Section 2.1. To make aging the score efficient, the increment of the queuing score is transformed into units of time by dividing by AGING so that the result represents the new expiry time of the flow.
fill_bucket() 関数は、セクション 2.1 で説明したように、時間の経過とともにキューイング スコアを蓄積し、経過させます。スコアのエージングを効率的に行うために、キューイング スコアの増分は AGING で除算して時間単位に変換され、結果がフローの新しい有効期限を表すようになります。
Given that probNative is already used to select which packets to ECN-mark, it might be thought that the queuing score could just be incremented by the full size of each selected packet, instead of incrementing it by the product of every packet's size (pkt_sz) and probNative. However, the unpublished experience of one of the authors with other congestion policers has found that the score then increments far too jumpily, particularly when probNative is low.
どのパケットに ECN マークを付けるかを選択するために probNative がすでに使用されていることを考えると、キューイング スコアは、すべてのパケットのサイズ (pkt_sz) と probNative の積によって増加するのではなく、選択された各パケットのフル サイズによって増加するだけでよいと考えられるかもしれません。ただし、著者の 1 人が他の輻輳ポリサーを使用した未発表の経験によると、特に probNative が低い場合、スコアが急激に増加しすぎることがわかりました。
A deeper explanation of the queuing score is given in Section 5.
キューイング スコアの詳細については、セクション 5 で説明します。
fill_bucket(bckt_id, pkt_sz, probNative) {
now; // current time
now = get_time_now(); // in units of T_RES
// Add packet's queuing score
// For integer arithmetic, a bit-shift can replace the division
qLscore = min(buckets[bckt_id].t_exp - now
+ probNative * pkt_sz / AGING, qLSCORE_MAX);
buckets[bckt_id].t_exp = now + qLscore;
return qLscore;
}
To derive this queuing score, the QProt algorithm uses the linear ramp function calcProbNative() to normalize instantaneous queuing delay of the LL queue into a probability in the range [0,1], which it assigns to probNative.
このキューイング スコアを導出するために、QProt アルゴリズムは線形ランプ関数 calcProbNative() を使用して、LL キューの瞬間的なキュー遅延を [0,1] の範囲の確率に正規化し、それを probNative に割り当てます。
calcProbNative(qdelay){
if ( qdelay >= MAXTH ) {
probNative = MAX_PROB;
} else if ( qdelay > MINTH ) {
probNative = MAX_PROB * (qdelay - MINTH)/RANGE;
// In practice, the * and the / would use a bit-shift
} else {
probNative = 0;
}
return probNative;
}
Figure 1 shows the bit rates of two flows as stacked areas. It poses the question of which flow is more to blame for queuing delay: the unresponsive constant bit rate flow (c) that is consuming about 80% of the capacity or the flow sending regular short unresponsive bursts (b)? The smoothness of c seems better for avoiding queuing, but its high rate does not. However, if flow c were not there, or ran slightly more slowly, b would not cause any queuing.
図 1 は、2 つのフローのビット レートを積み上げた領域として示しています。ここでは、どちらのフローがキューイング遅延の原因であるかという疑問が生じます。容量の約 80% を消費している応答しない固定ビット レートのフロー (c) と、定期的に短い応答しないバーストを送信するフロー (b) のどちらでしょうか。c の滑らかさはキューイングを回避するのに優れているように見えますが、その高いレートはそうではありません。ただし、フロー c が存在しないか、実行速度がわずかに遅い場合は、b によってキューは発生しません。
^ bit rate (stacked areas)
| ,-. ,-. ,-. ,-. ,-.
|--|b|----------|b|----------|b|----------|b|----------|b|---Capacity
|__|_|__________|_|__________|_|__________|_|__________|_|_____
|
| c
|
|
|
+---------------------------------------------------------------->
time
Figure 1: Which is more to blame for queuing delay?
図 1: キュー遅延の原因はどちらにあるでしょうか?
To explain queuing scores, in the following it will initially be assumed that the QProt algorithm is accumulating queuing scores but not taking any action as a result.
キューイング スコアを説明するために、以下では、QProt アルゴリズムがキューイング スコアを蓄積しているが、その結果として何もアクションを実行していないことを最初に仮定します。
To quantify the responsibility that each flow bears for queuing delay, the QProt algorithm accumulates the product of the rate of each flow and the level of congestion, both measured at the instant each packet arrives. The instantaneous flow rate is represented at each discrete event when a packet arrives by the packet's size, which accumulates faster the more packets arrive within each unit of time. The level of congestion is normalized to a dimensionless number between 0 and 1 (probNative). This fractional congestion level is used in preference to a direct dependence on queuing delay for two reasons:
各フローがキューイング遅延に対して負う責任を定量化するために、QProt アルゴリズムは、各パケットが到着した瞬間に測定される各フローのレートと輻輳レベルの積を累積します。瞬間的な流量は、パケットが到着したときの各離散イベントでパケットのサイズによって表され、各単位時間内に到着するパケットが増えるほど、より速く累積されます。輻輳のレベルは、0 ～ 1 の無次元数に正規化されます (確率的)。この部分的な輻輳レベルは、次の 2 つの理由により、キューイング遅延に直接依存するよりも優先して使用されます。
* to be able to ignore very low levels of queuing that contribute insignificantly to delay
* 遅延にあまり寄与しない非常に低レベルのキューを無視できるようにする
* to be able to erect a steep barrier against excessive queuing delay
* 過度のキュー遅延に対して急峻な障壁を築くことができる
The unit of the resulting queue score is "congested-bytes" per second, which distinguishes it from just bytes per second.
結果として得られるキュー スコアの単位は 1 秒あたりの「輻輳バイト」であり、単なる 1 秒あたりのバイト数とは区別されます。
Then, during the periods between bursts (b), neither flow accumulates any queuing score: the high rate of c is benign. But, during each burst, if we say the rate of c and b are 80% and 45% of capacity, thus causing 25% overload, they each bear (80/125)% and (45/125)% of the responsibility for the queuing delay (64% and 36%). The algorithm does not explicitly calculate these percentages. They are just the outcome of the number of packets arriving from each flow during the burst.
次に、バースト間の期間 (b)、どちらのフローもキューイング スコアを蓄積しません。c の割合が高いのは問題ありません。しかし、各バースト中に、c と b の割合が容量の 80% と 45% であり、したがって 25% の過負荷が発生するとすると、それらはそれぞれ、キュー遅延 (64% と 36%) の (80/125)% と (45/125)% の責任を負うことになります。アルゴリズムはこれらのパーセンテージを明示的に計算しません。これらは、バースト中に各フローから到着したパケット数の結果にすぎません。
To summarize, the queuing score never sanctions rate solely on its own account. It only sanctions rate inasmuch as it causes queuing.
要約すると、キュー スコアは、それ自体の理由だけでレートを制裁することはありません。キューイングを引き起こす場合に限り、料金を制裁するだけです。
^ bit rate (stacked areas) ,
| ,-. |\ ,-
|------Capacity-|b|----------,-.----------|b|----------|b\-----
| __|_|_______ |b| /``\| _...-._-': | ,.--
| ,-. __/ \__|_|_ _/ |/ \|/
| |b| ___/ \___/ __ r
| |_|/ v \__/ \_______ _/\____/
| _/ \__/
|
+---------------------------------------------------------------->
time
Figure 2: Responsibility for Queuing: A More Complex Scenario
図 2: キューイングの責任: より複雑なシナリオ
Figure 2 gives a more complex illustration of the way the queuing score assigns responsibility for queuing (limited to the precision that ASCII art can illustrate). The figure shows the bit rates of three flows represented as stacked areas labelled b, v, and r. The unresponsive bursts (b) are the same as in the previous example, but a variable-rate video (v) replaces flow c. Its rate varies as the complexity of the video scene varies. Also, on a slower timescale, in response to the level of congestion, the video adapts its quality. However, on a short timescale it appears to be unresponsive to small amounts of queuing. Also, partway through, a low-latency responsive flow (r) joins in, aiming to fill the balance of capacity left by the other two.
図 2 は、キューイング スコアがキューイングの責任を割り当てる方法をより複雑に示しています (ASCII アートで示すことができる精度に限定されます)。この図は、b、v、r のラベルが付いた積み重ねられた領域として表される 3 つのフローのビット レートを示しています。応答しないバースト (b) は前の例と同じですが、可変レートのビデオ (v) がフロー c を置き換えます。ビデオ シーンの複雑さが変化すると、そのレートも変化します。また、より遅いタイムスケールでは、混雑のレベルに応じてビデオの品質が調整されます。ただし、短期間では、少量のキューには反応しないように見えます。また、途中で、他の 2 つによって残された容量のバランスを埋めることを目的として、低遅延の応答フロー (r) が加わります。
The combination of the first burst and the low application-limited rate of the video causes neither flow to accumulate queuing score. In contrast, the second burst causes similar excessive overload (125%) to the example in Figure 1. Then, the video happens to reduce its rate (probably due to a less-complex scene) so the third burst causes only a little congestion. Let us assume the resulting queue causes probNative to rise to just 1%, then the queuing score will only accumulate 1% of the size of each packet of flows v and b during this burst.
最初のバーストとビデオの低いアプリケーション制限レートの組み合わせにより、どちらのフローもキューイング スコアを蓄積しません。対照的に、2 番目のバーストは、図 1 の例と同様の過剰な過負荷 (125%) を引き起こします。その後、ビデオはたまたまそのレートを下げます (おそらくシーンがそれほど複雑ではないため)。そのため、3 番目のバーストはわずかな輻輳のみを引き起こします。結果のキューによって確率が 1% に上昇すると仮定すると、キューイング スコアは、このバースト中にフロー v および b の各パケット サイズの 1% しか蓄積されません。
The fourth burst happens to arrive just as the new responsive flow (r) has filled the available capacity, so it leads to very rapid growth of the queue. After a round trip, the responsive flow rapidly backs off, and the adaptive video also backs off more rapidly than it would normally because of the very high congestion level. The rapid response to congestion of flow r reduces the queuing score that all three flows accumulate, but they each still bear the cost in proportion to the product of the rates at which their packets arrive at the queue and the value of probNative when they do so. Thus, during the fifth burst, they all accumulate a lower score than the fourth because the queuing delay is not as excessive.
4 番目のバーストは、新しい応答フロー (r) が利用可能な容量を満たしたときにたまたま到着するため、キューが非常に急速に増大します。ラウンドトリップの後、応答性の高いフローは急速に後退し、輻輳レベルが非常に高いため、アダプティブ ビデオも通常よりも急速に後退します。フロー r の輻輳への迅速な応答により、3 つのフローすべてが蓄積するキューイング スコアが減少しますが、パケットがキューに到着する速度と到着時の probNative の値の積に比例したコストがそれぞれ負担されます。したがって、5 回目のバーストでは、キュー遅延がそれほど過剰ではないため、すべてのバーストが 4 回目よりも低いスコアを蓄積します。
Even well-behaved flows will not always be able to respond fast enough to dynamic events. Also, well-behaved flows, e.g., Data Center TCP (DCTCP) [RFC8257], TCP Prague [PRAGUE-CC], Bottleneck Bandwidth and Round-trip propagation time version 3 (BBRv3) [BBRv3], or the L4S variant of SCReAM [SCReAM] for real-time media [RFC8298], can maintain a very shallow queue by continual careful probing for more while also continually subtracting a little from their rate (or congestion window) in response to low levels of ECN signalling. Therefore, the QProt algorithm needs to continually offer a degree of forgiveness to age out the queuing score as it accumulates.
適切に動作するフローであっても、常に動的イベントに十分な速さで応答できるとは限りません。また、データセンター TCP (DCTCP) [RFC8257]、TCP プラハ [PRAGUE-CC]、ボトルネック帯域幅とラウンドトリップ伝播時間バージョン 3 (BBRv3) [BBRv3]、またはリアルタイム メディア用の SCReAM [SCReAM] の L4S バリアント [RFC8298] など、行儀の良いフローは、より多くのデータを継続的に注意深くプローブすることで、非常に浅いキューを維持できます。また、低レベルの ECN シグナリングに応じて、レート (または輻輳ウィンドウ) から継続的に少し減算します。したがって、QProt アルゴリズムは、キュー スコアが蓄積するにつれて、キュー スコアを期限切れにするために一定の許容度を継続的に提供する必要があります。
Scalable congestion controllers, such as those above, maintain their congestion window in inverse proportion to the congestion level, probNative. That leads to the important property that, on average, a scalable flow holds the product of its congestion window and the congestion level constant, no matter the capacity of the link or how many other flows it competes with. For instance, if the link capacity doubles, a scalable flow induces half the congestion probability. Or, if three scalable flows compete for the capacity, each flow will reduce to one third of the capacity they would use on their own and increase the congestion level by 3x. Therefore, in steady state, a scalable flow will induce the same constant amount of "congested-bytes" per round trip, whatever the link capacity and no matter how many flows are sharing the capacity.
上記のようなスケーラブルな輻輳コントローラは、輻輳レベル (probNative) に反比例して輻輳ウィンドウを維持します。これは、リンクの容量や競合する他のフローの数に関係なく、平均して、スケーラブルなフローは輻輳ウィンドウと輻輳レベルの積を一定に保つという重要な特性につながります。たとえば、リンク容量が 2 倍になると、スケーラブルなフローにより発生する輻輳確率は半分になります。または、3 つのスケーラブルなフローが容量をめぐって競合する場合、各フローは単独で使用する容量の 3 分の 1 に減少し、輻輳レベルが 3 倍に増加します。したがって、定常状態では、リンク容量に関係なく、また容量を共有しているフローの数に関係なく、スケーラブルなフローは往復ごとに同じ一定量の「輻輳バイト」を引き起こします。
This suggests that the QProt algorithm will not sanction a well-behaved scalable flow if it ages out the queuing score at a sufficient constant rate. The constant will need to be somewhat above the average of a well-behaved scalable flow to allow for normal dynamics.
これは、キューイング スコアが十分な一定のレートで期限切れになる場合、QProt アルゴリズムが正常に動作するスケーラブル フローを承認しないことを示唆しています。通常のダイナミクスを考慮して、定数は正常に動作するスケーラブルなフローの平均よりも若干大きい必要があります。
Relating QProt's aging constant to a scalable flow does not mean that a flow has to behave like a scalable flow: it can be less aggressive but not more aggressive. For instance, a longer RTT flow can run at a lower congestion-rate than the aging rate, but it can also increase its aggressiveness to equal the rate of short RTT scalable flows [ScalingCC]. The constant aging of QProt also means that a long-running unresponsive flow will be prone to trigger QProt if it runs faster than a competing responsive scalable flow would. And, of course, if a flow causes excessive queuing in the short term, its queuing score will still rise faster than the constant aging process will decrease it. Then, QProt will still eject the flow's packets before they harm the low latency of the shared queue.
QProt のエージング定数をスケーラブルなフローに関連付けることは、フローがスケーラブルなフローのように動作する必要があることを意味するものではありません。攻撃性を低くすることはできますが、より積極的にすることはできません。たとえば、長い RTT フローはエージング レートよりも低い輻輳率で実行できますが、その積極性を高めて、短い RTT のスケーラブル フローのレートと同等にすることもできます [ScalingCC]。QProt の継続的なエージングは、競合する応答性のあるスケーラブルなフローよりも高速に実行される場合、長時間応答しないフローが QProt をトリガーする傾向があることも意味します。そしてもちろん、フローが短期的に過度のキューイングを引き起こした場合でも、そのキューイング スコアは、一定のエージング プロセスによってキューイング スコアが低下するよりも速く上昇します。その後、QProt は、共有キューの低レイテンシに悪影響を及ぼす前に、フローのパケットを排出します。
The QProt algorithm holds a flow's queuing score state in a structure called a "bucket". This is because of its similarity to a regular leaky bucket (except the contents of the bucket do not represent bytes).
QProt アルゴリズムは、フローのキューイング スコア状態を「バケット」と呼ばれる構造に保持します。これは、通常のリーキー バケットと類似しているためです (バケットの内容がバイトを表さない点を除く)。
probNative * pkt_sz probNative * pkt_sz / AGING
| |
| V | | V |
| : | ___ | : |
|_____| ___ |_____|
| | ___ | |
|__ __| |__ __|
| |
V V
AGING * Dt Dt
Figure 3: Transformation of Queuing Score
図 3: キュー スコアの変化
The accumulation and aging of the queuing score is shown on the left of Figure 3 in token bucket form. Dt is the difference between the times when the scores of the current and previous packets were processed.
キューイング スコアの蓄積と経過をトークン バケット形式で図 3 の左側に示します。Dt は、現在のパケットのスコアと前のパケットのスコアが処理された時間の差です。
A transformed equivalent of this token bucket is shown on the right of Figure 3, dividing both the input and output by the constant rate, AGING. The result is a bucket-depth that represents time and it drains at the rate that time passes.
このトークン バケットの変換された等価物が図 3 の右側に示されており、入力と出力の両方を定率 AGING で割っています。結果は時間を表すバケットの深さとなり、時間の経過に応じて排出されます。
As a further optimization, the time the bucket was last updated is not stored with the flow state. Instead, when the bucket is initialized, the queuing score is added to the system time "now" and the resulting expiry time is written into the bucket. Subsequently, if the bucket has not expired, the incremental queuing score is added to the time already held in the bucket. Then, the queuing score always represents the expiry time of the flow state itself. This means that the queuing score does not need to be aged explicitly because it ages itself implicitly.
さらなる最適化として、バケットが最後に更新された時刻はフロー状態とともに保存されません。代わりに、バケットが初期化されるときに、キューイング スコアが「現在」のシステム時間に追加され、その結果の有効期限がバケットに書き込まれます。その後、バケットの有効期限が切れていない場合、増分キュー スコアがバケットにすでに保持されている時間に追加されます。したがって、キューイング スコアは常にフロー状態自体の有効期限を表します。これは、キュー スコア自体が暗黙的に経過するため、キュー スコアを明示的に経過させる必要がないことを意味します。
Pseudocode for the QProt policy conditions is given in Section 4.1 within the second half of the qprotect() function. When each packet arrives, after finding its flow state and updating the queuing score of the packet's flow, the algorithm checks whether the shared queue delay exceeds a constant threshold CRITICALqL (e.g., 2 ms), as repeated below for convenience:
QProt ポリシー条件の疑似コードは、セクション 4.1 の qprotect() 関数の後半に記載されています。各パケットが到着すると、そのフロー状態を検出し、パケットのフローのキューイング スコアを更新した後、アルゴリズムは、便宜上以下で繰り返すように、共有キュー遅延が一定のしきい値 CRITICALqL (例: 2 ミリ秒) を超えているかどうかをチェックします。
if ( ( qdelay > CRITICALqL ) // Test if qdelay over threshold...
// ...and if flow's q'ing score scaled by qdelay/CRITICALqL
// ...exceeds CRITICALqLSCORE
&& ( qdelay * qLscore > CRITICALqLPRODUCT ) )
// Recall that CRITICALqLPRODUCT = CRITICALqL * CRITICALqLSCORE
If the queue delay threshold is exceeded, the flow's queuing score is temporarily scaled up by the ratio of the current queue delay to the threshold queuing delay, CRITICALqL (the reason for the scaling is given next). If this scaled up score exceeds another constant threshold CRITICALqLSCORE, the packet is ejected. The actual last line of code above multiplies both sides of the second condition by CRITICALqL to avoid a costly division.
キュー遅延のしきい値を超えると、フローのキューイング スコアは、現在のキュー遅延とキュー遅延しきい値 CRITICALqL の比によって一時的にスケールアップされます (スケールの理由は次に説明します)。このスケールアップされたスコアが別の一定のしきい値 CRITICALqLSCORE を超える場合、パケットは排出されます。上記のコードの実際の最後の行は、コストのかかる除算を避けるために、2 番目の条件の両側に CRITICALqL を乗算します。
This approach allows each packet to be assessed once, as it arrives. Once queue delay exceeds the threshold, it has two implications:
このアプローチにより、各パケットが到着時に 1 回評価されるようになります。キュー遅延がしきい値を超えると、次の 2 つの影響が生じます。
* The current packet might be ejected, even though there are packets already in the queue from flows with higher queuing scores. However, any flow that continues to contribute to the queue will have to send further packets, giving an opportunity to eject them as well, as they subsequently arrive.
* キューイング スコアの高いフローからのパケットがすでにキュー内にある場合でも、現在のパケットが排出される可能性があります。ただし、キューに寄与し続けるフローはさらにパケットを送信する必要があり、その後到着するパケットを排出する機会も与えられます。
* The next packets to arrive might not be ejected because they might belong to flows with low queuing scores. In this case, queue delay could continue to rise with no opportunity to eject a packet. This is why the queuing score is scaled up by the current queue delay. Then, the more the queue has grown without ejecting a packet, the more the algorithm "raises the bar" to further packets.
* 次に到着するパケットは、キューイング スコアの低いフローに属している可能性があるため、排出されない可能性があります。この場合、パケットを排出する機会がないまま、キュー遅延が増加し続ける可能性があります。これが、現在のキュー遅延によってキュー スコアがスケールアップされる理由です。そして、パケットを排出せずにキューが大きくなるにつれて、アルゴリズムはさらなるパケットに対する「基準を引き上げ」ます。
The above approach is preferred over the extra per-packet processing cost of searching the buckets for the flow with the highest queuing score and searching the queue for one of its packets to eject (if one is still in the queue).
上記のアプローチは、キューイング スコアが最も高いフローをバケットで検索したり、取り出すパケットの 1 つをキューで検索したり (キューにパケットがまだある場合) という余分なパケットごとの処理コストよりも優先されます。
Figure 4 explains this approach graphically. On the horizontal axis, it shows actual harm, meaning the queuing delay in the shared queue. On the vertical axis, it shows the behaviour record of the flow associated with the currently arriving packet, represented in the algorithm by the flow's queuing score. The shaded region represents the combination of actual harm and behaviour record that will lead to the packet being ejected.
図 4 は、このアプローチを図で説明しています。横軸は実害を示し、共有キューのキュー遅延を意味します。縦軸には、現在到着しているパケットに関連付けられたフローの動作記録が表示され、アルゴリズムではフローのキューイング スコアによって表されます。影付きの領域は、パケットの排出につながる実際の害と行動記録の組み合わせを表します。
Note that, by default, CRITICALqL_us is set to the maximum threshold of the ramp marking algorithm MAXTH_us. However, there is some debate as to whether setting it to the minimum threshold instead would improve QProt performance. This would roughly double the ratio of qdelay to CRITICALqL, which is compared against the CRITICALqLSCORE threshold. Therefore, the threshold would have to be roughly doubled accordingly.
デフォルトでは、CRITICALqL_us はランプ マーキング アルゴリズムの最大しきい値 MAXTH_us に設定されていることに注意してください。ただし、代わりに最小しきい値に設定することで QProt のパフォーマンスが向上するかどうかについては議論があります。これにより、CRITICALqLSCORE しきい値と比較される、qlay 対 CRITICALqL の比率がおよそ 2 倍になります。したがって、それに応じてしきい値を約 2 倍にする必要があります。
Behaviour Record:
Queueing Score of
Arriving Packet's Flow
^
| + |/ / / / / / / / / / / / / / / / / / /
| + N | / / / / / / / / / / / / / / / / / / /
| + |/ / / / / / / / / /
| + | / / / / E (Eject packet) / / / / /
| + |/ / / / / / / / / /
| + | / / / / / / / / / / / / / / / / / / /
| + |/ / / / / / / / / / / / / / / / / / /
| +| / / / / / / / / / / / / / / / / / / /
| |+ / / / / / / / / / / / / / / / / / /
| N | + / / / / / / / / / / / / / / / / /
| (No actual | +/ / / / / / / / / / / / / / /
| harm) | + / / / / / / / / / / / /
| | P (Pass over) + ,/ / / / / / / /
| | ^ + /./ /_/
+--------------+------------------------------------------>
CRITICALqL Actual Harm: Shared Queue Delay
Figure 4: Graphical Explanation of the Policy Conditions
図 4: ポリシー条件の図による説明
The regions labelled "N" represent cases where the first condition is not met -- no actual harm -- queue delay is below the critical threshold, CRITICALqL.
「N」とラベル付けされた領域は、最初の条件が満たされていない場合、つまり実際の害はなく、キュー遅延がクリティカルしきい値 CRITICALqL を下回っている場合を表します。
The region labelled "E" represents cases where there is actual harm (queue delay exceeds CRITICALqL) and the queuing score associated with the arriving packet is high enough to be able to eject it with certainty.
「E」とラベル付けされた領域は、実際に害があり (キュー遅延が CRITICALqL を超える)、到着パケットに関連付けられたキューイング スコアが十分に高く、確実にパケットを排出できる場合を表します。
The region labelled "P" represents cases where there is actual harm, but the queuing score of the arriving packet is insufficient to eject it, so it has to be passed over. This adds to queuing delay, but the alternative would be to risk sanctioning an innocent flow. It can be seen that, as actual harm increases, the judgement of innocence becomes increasingly stringent; the behaviour record of the next packet's flow does not have to be as bad to eject it.
「P」とラベル付けされた領域は、実際に害があるが、到着したパケットのキューイング スコアがそれを排出するには不十分であるため、パスオーバーする必要がある場合を表します。これによりキューの遅延が増加しますが、別の方法としては、無害なフローを認可するリスクを冒すことになります。実害が増大するにつれて、無罪の判断がますます厳しくなることがわかります。次のパケットのフローの動作記録がそれほど悪くなくても、それを排出できます。
Conditioning ejection on actual harm helps prevent VPN packets being ejected unnecessarily. VPNs consisting of multiple flows can tend to accumulate queuing score faster than it is aged out because the aging rate is intended for a single flow. However, whether or not some traffic is in a VPN, the queue delay threshold (CRITICALqL) will be no more likely to be exceeded. Therefore, conditioning ejection on actual harm helps reduce the chance that VPN traffic will be ejected by the QProt function.
実際の害に応じて排出を条件設定すると、VPN パケットが不必要に排出されるのを防ぐことができます。複数のフローで構成される VPN は、エージング レートが単一のフローを対象としているため、キューイング スコアがエージングアウトするよりも早く蓄積される傾向があります。ただし、一部のトラフィックが VPN 内にあるかどうかに関係なく、キュー遅延しきい値 (CRITICALqL) を超える可能性は低くなります。したがって、実際の害に応じて排出を条件付けることは、VPN トラフィックが QProt 機能によって排出される可能性を減らすのに役立ちます。
When the DOCSIS QProt algorithm deems that it is necessary to eject a packet to protect the Low-Latency queue, it redirects the packet to the Classic queue. In the Low-Latency DOCSIS architecture (as in Dual-Queue Coupled AQMs generally), the Classic queue is expected to frequently have a larger backlog of packets, which is caused by classic congestion controllers interacting with a Classic AQM (which has a latency target of 10 ms) as well as other bursty traffic.
DOCSIS QProt アルゴリズムは、低遅延キューを保護するためにパケットを排出する必要があると判断すると、パケットをクラシック キューにリダイレクトします。低遅延 DOCSIS アーキテクチャ（一般的なデュアル キュー結合 AQM と同様）では、クラシック キューに大量のパケット バックログが頻繁に発生すると予想されます。これは、クラシック AQM（遅延目標が 10 ミリ秒）と対話するクラシック輻輳コントローラや他のバースト性トラフィックが原因で発生します。
Therefore, typically, an ejected packet will experience higher queuing delay than it would otherwise, and it could be re-ordered within its flow (assuming QProt does not eject all packets of an anomalous flow). The mild harm caused to the performance of the ejected packet's flow is deliberate. It gives senders a slight incentive to identify their packets correctly.
したがって、通常、排出されたパケットはそうでない場合よりも長いキューイング遅延を経験し、そのフロー内で再順序付けされる可能性があります (QProt が異常なフローのすべてのパケットを排出しないと仮定します)。排出されたパケットのフローのパフォーマンスに軽度の悪影響を与えるのは、意図的なものです。これにより、送信者はパケットを正確に識別するわずかなインセンティブが得られます。
If there were no such harm, there would be nothing to prevent all flows from identifying themselves as suitable for classification into the low-latency queue and just letting QProt sort the resulting aggregate into queue-building and non-queue-building flows. This might seem like a useful alternative to requiring senders to correctly identify their flows. However, handling of misclassified flows is not without a cost. The more packets that have to be reclassified, the more often the delay of the low-latency queue would exceed the threshold. Also, more memory would be required to hold the extra flow state.
そのような害がなければ、すべてのフローが低レイテンシ キューへの分類に適していると認識し、結果として得られた集計をキュー構築フローと非キュー構築フローに QProt に分類させることを妨げるものは何もありません。これは、送信者にフローを正しく識別するよう要求することに代わる便利な手段のように思えるかもしれません。ただし、誤って分類されたフローの処理にはコストがかかります。再分類する必要があるパケットが多いほど、低遅延キューの遅延がしきい値を超える頻度が高くなります。また、追加のフロー状態を保持するには、より多くのメモリが必要になります。
When a packet is redirected into the Classic queue, an operator might want to alter the identifier(s) that originally caused it to be classified into the Low-Latency queue so that the packet will not be classified into another low-latency queue further downstream. However, redirection of occasional packets can be due to unusually high transient load just at the specific bottleneck, not necessarily at any other bottleneck and not necessarily due to bad flow behaviour. Therefore, Section 5.4.1.2 of [RFC9331] precludes a network node from altering the end-to-end ECN field to exclude traffic from L4S treatment. Instead a local-use identifier ought to be used (e.g., Diffserv codepoint or VLAN tag) so that each operator can apply its own policy, without prejudging what other operators ought to do.
パケットがクラシック キューにリダイレクトされる場合、オペレータは、パケットがさらに下流にある別の低遅延キューに分類されないように、パケットが低遅延キューに分類される原因となった識別子を変更したい場合があります。ただし、時折発生するパケットのリダイレクトは、特定のボトルネックでの異常に高い一時的負荷が原因である可能性があり、必ずしも他のボトルネックで発生するわけではなく、フロー動作の不良が原因であるとは限りません。したがって、[RFC9331] のセクション 5.4.1.2 は、ネットワーク ノードがエンドツーエンド ECN フィールドを変更してトラフィックを L4S 処理から除外することを禁止しています。代わりに、ローカル使用の識別子 (Diffserv コードポイントや VLAN タグなど) を使用して、各オペレーターが他のオペレーターが何をすべきかを予断することなく独自のポリシーを適用できるようにする必要があります。
Although not supported in the DOCSIS specifications, QProt could be extended to recognize that large numbers of redirected packets belong to the same flow. This might be detected when the bucket expiry time t_exp exceeds a threshold. Depending on policy and implementation capabilities, QProt could then install a classifier to redirect a whole flow into the Classic queue, with an idle timeout to remove stale classifiers. In these "persistent offender" cases, QProt might also overwrite each redirected packet's DSCP, in order to protect other potential low-latency queues downstream. The DOCSIS specifications do not discuss sanctioning whole flows; further discussion is beyond the scope of the present document.
DOCSIS 仕様ではサポートされていませんが、QProt を拡張して、リダイレクトされた多数のパケットが同じフローに属することを認識できるようにすることができます。これは、バケットの有効期限 t_exp がしきい値を超えたときに検出される可能性があります。ポリシーと実装の機能に応じて、QProt は、古い分類子を削除するためのアイドル タイムアウトを使用して、フロー全体をクラシック キューにリダイレクトする分類子をインストールできます。このような「継続的な攻撃者」の場合、QProt は、ダウンストリームの他の潜在的な低遅延キューを保護するために、リダイレクトされた各パケットの DSCP を上書きすることもあります。DOCSIS 仕様では、フロー全体の認可については説明されていません。これ以上の議論は本書の範囲を超えます。
The QProt algorithm groups packets with common Layer 4 flow identifiers. It then uses this grouping to accumulate queuing scores and to sanction packets.
QProt アルゴリズムは、共通のレイヤー 4 フロー識別子を持つパケットをグループ化します。次に、このグループ化を使用してキューイング スコアを蓄積し、パケットを認可します。
This choice of identifier for grouping is pragmatic with no scientific basis. All the packets of a flow certainly pass between the same two endpoints. However, some applications might initiate multiple flows between the same endpoints, e.g., for media, control, data, etc. Others might use common flow identifiers for all these streams. Also, a user might group multiple application flows within the same encrypted VPN between the same Layer 4 tunnel endpoints. And, even if there were a one-to-one mapping between flows and applications, there is no reason to believe that the rate at which congestion can be caused ought to be allocated on a per-application-flow basis.
グループ化のための識別子のこの選択は実際的なものであり、科学的根拠はありません。フローのすべてのパケットは、同じ 2 つのエンドポイント間を確実に通過します。ただし、一部のアプリケーションは、メディア、制御、データなどの同じエンドポイント間で複数のフローを開始する場合があります。その他のアプリケーションは、これらすべてのストリームに共通のフロー識別子を使用する場合があります。また、ユーザーは、同じレイヤ 4 トンネル エンドポイント間の同じ暗号化された VPN 内で複数のアプリケーション フローをグループ化する場合があります。また、フローとアプリケーションの間に 1 対 1 のマッピングがあったとしても、輻輳が発生する可能性のあるレートがアプリケーション フローごとに割り当てられるべきであると考える理由はありません。
The use of a queuing score that excludes those aspects of flow rate that do not contribute to queuing (Section 5.1) goes some way to mitigating this limitation because the algorithm does not judge responsibility for queuing delay primarily on the combined rate of a set of flows grouped under one flow ID.
キューイングに寄与しないフロー レートの側面を除外するキューイング スコアの使用 (セクション 5.1) は、この制限を緩和するのにある程度役立ちます。これは、アルゴリズムが主に 1 つのフロー ID にグループ化された一連のフローの合計レートに基づいてキュー遅延の責任を判断しないためです。
This document has no IANA actions.
この文書には IANA のアクションはありません。
The whole of this document concerns traffic security. It considers the security question of how to identify and eject traffic that does not comply with the non-queue-building behaviour required to use a shared low-latency queue, whether accidentally or maliciously.
この文書全体は交通安全に関するものです。これは、共有低遅延キューを使用するために必要な非キュー構築動作に従わないトラフィックを、偶然か悪意にかかわらず、どのように識別して排除するかというセキュリティ上の問題を考慮しています。
Section 8.2 of [RFC9330] of the L4S architecture [RFC9330] introduces the problem of maintaining low latency by either self-restraint or enforcement and places DOCSIS Queue Protection (QProt) in context within a wider set of approaches to the problem.
L4S アーキテクチャ [RFC9330] の [RFC9330] のセクション 8.2 では、自制または強制によって低遅延を維持するという問題が導入されており、この問題に対する幅広いアプローチの中で DOCSIS キュー保護 (QProt) が位置づけられています。
The QProt algorithm has been designed to fail gracefully in the face of traffic crafted to overrun the resources used for the algorithm's own processing and flow state. This means that non-queue-building flows will always be less likely to be sanctioned than queue-building flows. But an attack could be contrived to deplete resources in such a way that the proportion of innocent (non-queue-building) flows that are incorrectly sanctioned could increase.
QProt アルゴリズムは、アルゴリズム自体の処理とフロー状態に使用されるリソースをオーバーランするように作成されたトラフィックに直面しても正常に失敗するように設計されています。これは、キューを構築しないフローは常に、キューを構築するフローよりも認可される可能性が低いことを意味します。しかし、誤って認可される無害な (キューを構築していない) フローの割合が増加するような方法でリソースを枯渇させる攻撃が考案される可能性があります。
Incorrect sanctioning is intended not to be catastrophic; it results in more packets from well-behaved flows being redirected into the Classic queue, which introduces more reordering into innocent flows.
不適切な制裁は大惨事にならないように意図されています。その結果、正常に動作するフローからのより多くのパケットがクラシック キューにリダイレクトされ、無害なフローへの再順序付けがさらに発生します。
To exhaust the number of buckets, the most efficient attack is to send enough long-running attack flows to increase the chance that an arriving flow will not find an available bucket and will, therefore, have to share the "dregs" bucket. For instance, if ATTEMPTS=2 and NBUCKETS=32, it requires about 94 attack flows, each using different port numbers, to increase the probability to 99% that an arriving flow will have to share the dregs, where it will share a high degree of redirection into the Classic queue with the remainder of the attack flows.
バケットの数を使い果たすための最も効率的な攻撃は、到着するフローが利用可能なバケットを見つけられず、そのため「残骸」バケットを共有する必要がある可能性を高めるために、十分な長時間実行の攻撃フローを送信することです。たとえば、ATTEMPTS=2 および NBUCKETS=32 の場合、到着フローが残りを共有する必要がある確率を 99% に高めるには、それぞれが異なるポート番号を使用する約 94 の攻撃フローが必要になります。この場合、残りの攻撃フローとクラシック キューへの高度なリダイレクトが共有されます。
For an attacker to keep buckets busy, it is more efficient to hold onto them by cycling regularly through a set of port numbers (94 in the above example) rather than to keep occupying and releasing buckets with single packet flows across a much larger number of ports.
攻撃者がバケットをビジー状態に保つには、非常に多数のポートにわたる単一のパケット フローでバケットを占有および解放し続けるよりも、一連のポート番号 (上記の例では 94) を定期的に循環させてバケットを保持する方が効率的です。
During such an attack, the coupled marking probability will have saturated at 100%. Therefore, to hold a bucket, the rate of an attack flow needs to be no less than the aging rate of each bucket: 4 Mb/s by default. However, for an attack flow to be sure to hold on to its bucket, it would need to send somewhat faster. Thus, an attack with 100 flows would need a total force of more than 100 * 4 Mb/s = 400 Mb/s.
このような攻撃中、結合マーキング確率は 100% で飽和します。したがって、バケットを保持するには、攻撃フローのレートが各バケットのエージング レート（デフォルトでは 4 Mb/s）以上である必要があります。ただし、攻撃フローがそのバケットを確実に保持するには、送信をいくらか速くする必要があります。したがって、100 フローによる攻撃には、100 * 4 Mb/s = 400 Mb/s を超える総力が必要になります。
This attack can be mitigated (but not prevented) by increasing the number of buckets. The required attack force scales linearly with the number of buckets, NBUCKETS. Therefore, if NBUCKETS were doubled to 64, twice as many 4 Mb/s flows would be needed to maintain the same impact on innocent flows.
この攻撃は、バケットの数を増やすことで軽減できます (ただし、防ぐことはできません)。必要な攻撃力は、バケット (NBUCKETS) の数に比例して増加します。したがって、NBUCKETS が 2 倍の 64 になった場合、無害なフローに対して同じ影響を維持するには 2 倍の 4 Mb/s フローが必要になります。
Probably the most effective mitigation would be to implement redirection of whole-flows once enough of the individual packets of a certain offending flow had been redirected. This would free up the buckets used to maintain the per-packet queuing score of persistent offenders. Whole-flow redirection is outside the scope of the current version of the QProt algorithm specified here, but it is briefly discussed at the end of Section 5.5.
おそらく最も効果的な軽減策は、特定の違反フローの個々のパケットが十分にリダイレクトされた後で、フロー全体のリダイレクトを実装することでしょう。これにより、執拗な攻撃者のパケットごとのキューイング スコアを維持するために使用されるバケットが解放されます。フロー全体のリダイレクションは、ここで指定されている QProt アルゴリズムの現在のバージョンの範囲外ですが、セクション 5.5 の最後で簡単に説明されています。
It might be considered that all the packets of persistently offending flows ought to be discarded rather than redirected. However, this is not recommended because attack flows might be able to pervert whole-flow discard, turning it onto at least some innocent flows, thus amplifying an attack that causes reordering into total deletion of some innocent flows.
継続的に違反するフローのパケットはすべて、リダイレクトされるのではなく破棄されるべきであると考えられるかもしれません。ただし、これは推奨されません。攻撃フローにより、フロー全体の破棄が不正に行われ、少なくとも一部の無害なフローに変更され、その結果、一部の無害なフローの完全な削除へと並べ替えを引き起こす攻撃が増幅される可能性があるためです。
The processing time needed to apply the QProt algorithm to each Low-Latency (LL) packet is small and intended not to take all the time available between each of a run of fairly small packets. However, an attack could use minimum sized packets launched from multiple input interfaces into a lower capacity output interface. Whether the QProt algorithm is vulnerable to processor exhaustion will depend on the specific implementation.
QProt アルゴリズムを各低遅延 (LL) パケットに適用するために必要な処理時間は短く、かなり小さなパケットの実行の間に利用可能な時間をすべて費やすことはありません。ただし、攻撃では、複数の入力インターフェイスから低容量の出力インターフェイスに送信される最小サイズのパケットが使用される可能性があります。QProt アルゴリズムがプロセッサーの枯渇に対して脆弱かどうかは、特定の実装によって異なります。
Addition of a capability to redirect persistently offending flows from LL to Classic would be the most effective way to reduce the per-packet processing cost of the QProt algorithm when under attack. As already mentioned in Section 8.1.1, this would also be an effective way to mitigate flow-state exhaustion attacks. Further discussion of whole-flow redirection is outside the scope of the present document but is briefly discussed at the end of Section 5.5.
継続的に問題を引き起こすフローを LL からクラシックにリダイレクトする機能を追加することは、攻撃を受けたときに QProt アルゴリズムのパケットごとの処理コストを削減する最も効果的な方法です。セクション 8.1.1 ですでに述べたように、これはフロー状態枯渇攻撃を軽減する効果的な方法でもあります。フロー全体のリダイレクトに関するこれ以上の説明は、この文書の範囲外ですが、セクション 5.5 の最後で簡単に説明します。
Evaluation and assessment of the algorithm by researchers is solicited. Comments and questions are also encouraged and welcome. They can be addressed to the authors.
研究者によるアルゴリズムの評価・評価を募集します。コメントや質問も歓迎です。それらは著者に宛てることができます。
[DOCSIS] CableLabs, "MAC and Upper Layer Protocols Interface
(MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable
Service Interface Specifications DOCSIS(r) 3.1 Version I17
or later, 21 January 2019,
<https://www.cablelabs.com/specifications/CM-SP-
MULPIv3.1>.
[DOCSIS-CCAP-OSS]
CableLabs, "CCAP Operations Support System Interface
Specification", Data-Over-Cable Service Interface
Specifications DOCSIS(r) 3.1 Version I14 or later, 7
February 2019, <https://www.cablelabs.com/specifications/
CM-SP-CCAP-OSSIv3.1>.
[DOCSIS-CM-OSS]
CableLabs, "Cable Modem Operations Support System
Interface Specification", Data-Over-Cable Service
Interface Specifications DOCSIS(r) 3.1 Version I14 or
later, 21 January 2019,
<https://www.cablelabs.com/specifications/CM-SP-CM-
OSSIv3.1>.
[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,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>.
[RFC9956] White, G., Fossati, T., and R. Geib, "A Non-Queue-Building
Per-Hop Behavior (NQB PHB) for Differentiated Services",
RFC 9956, DOI 10.17487/RFC9956, May 2026,
<https://www.rfc-editor.org/info/rfc9956>.
[BBRv3] "TCP BBR v3 Release", commit 90210de, 18 March 2025,
<https://github.com/google/bbr/blob/v3/README.md>.
[LLD] White, G., Sundaresan, K., and B. Briscoe, "Low Latency
DOCSIS: Technology Overview", CableLabs White Paper,
February 2019, <https://cablela.bs/low-latency-docsis-
technology-overview-february-2019>.
[PRAGUE-CC]
De Schepper, K., Tilmans, O., Briscoe, B., and V. Goel,
"Prague Congestion Control", Work in Progress, Internet-
Draft, draft-briscoe-iccrg-prague-congestion-control-04,
24 July 2024, <https://datatracker.ietf.org/doc/html/
draft-briscoe-iccrg-prague-congestion-control-04>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed.,
"Congestion Exposure (ConEx) Concepts and Use Cases",
RFC 6789, DOI 10.17487/RFC6789, December 2012,
<https://www.rfc-editor.org/info/rfc6789>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December
2017, <https://www.rfc-editor.org/info/rfc8298>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/info/rfc9330>.
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-
Queue Coupled Active Queue Management (AQM) for Low
Latency, Low Loss, and Scalable Throughput (L4S)",
RFC 9332, DOI 10.17487/RFC9332, January 2023,
<https://www.rfc-editor.org/info/rfc9332>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
[ScalingCC]
Briscoe, B. and K. De Schepper, "Resolving Tensions
between Congestion Control Scaling Requirements",
arXiv:1904.07605, Simula Technical Report TR-CS-2016-001,
DOI 10.48550/arXiv.1904.07605, July 2017,
<https://arxiv.org/abs/1904.07605>.
[SCReAM] "SCReAM", commit 0208f59, 10 November 2025,
<https://github.com/EricssonResearch/scream/blob/master/
README.md>.
Thanks to Tom Henderson, Magnus Westerlund, David Black, Adrian Farrel, and Gorry Fairhurst for their reviews of this document. The design of the QProt algorithm and the settings of the parameters benefited from discussion and critique from the participants of the cable industry working group on Low-Latency DOCSIS. CableLabs funded Bob Briscoe's initial work on this document.
この文書のレビューに協力してくれた Tom Henderson、Magnus Westerlund、David Black、Adrian Farrel、Gorry Fairhurst に感謝します。QProt アルゴリズムの設計とパラメータの設定は、低遅延 DOCSIS に関するケーブル業界ワーキング グループの参加者からの議論と批評から恩恵を受けました。CableLabs は、この文書に関する Bob Briscoe の最初の作業に資金を提供しました。
Bob Briscoe (editor)
Independent
United Kingdom
Email: ietf@bobbriscoe.net
URI: https://bobbriscoe.net/
Greg White
CableLabs
United States of America
Email: G.White@CableLabs.com