[要約] RFC 9332 は、異なる輻輳応答を持つフロー向けの2つのキューにおけるActive Queue Management（AQM）アルゴリズムを結合する枠組みを定義します。これにより、インターネットは標準のTCP-Renoフレンドリー（'Classic'）輻輳制御から'Scalable'輻輳制御への移行を可能にし、非常に低い待ち行列遅延、非常に低い輻輳損失、およびECNを変更した方法でのフローごとのスループットのスケーリングを実現します。
Internet Engineering Task Force (IETF) K. De Schepper
Request for Comments: 9332 Nokia Bell Labs
Category: Experimental B. Briscoe, Ed.
ISSN: 2070-1721 Independent
G. White
CableLabs
January 2023
Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)
低レイテンシ、低損失、スケーラブルスループット（L4S）のためのデュアルキュー結合アクティブキュー管理（AQM）
Abstract
概要
This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.
この仕様は、輻輳に対する異なる応答を持つフロー用に意図された2つのキューで、アクティブキュー管理（AQM）アルゴリズムを結合するためのフレームワークを定義します。これにより、インターネットが標準のTCP-レノにやさしい（「クラシック」）混雑コントロールのスケーリング問題から、「スケーラブルな」混雑コントロールのファミリーに移行する方法が提供されます。これらは、一貫して非常に低いキューイングレイテンシ、非常に低い輻輳損失、および明示的な混雑通知（ECN）を修正された方法で使用することにより、流量あたりのスループットのスケーリング用に設計されています。結合されたデュアルキュー（DualQ）まで、これらのスケーラブルなL4S混雑コントロールは、プライベートデータセンターなどのクリーンスレート環境を配置できる場所でのみ展開できます。
This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices.
この仕様では、最初に結合されたDualQがどのように機能するかを説明します。その後、それがうまく機能するために必要な規範的要件を与えます。これらはすべて2つのAQMが使用されていることに依存しませんが、特定のAQMの擬似コードの例が付録に示されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。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/rfc9332.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9332で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2023 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Outline of the Problem
1.2. Context, Scope, and Applicability
1.3. Terminology
1.4. Features
2. DualQ Coupled AQM
2.1. Coupled AQM
2.2. Dual Queue
2.3. Traffic Classification
2.4. Overall DualQ Coupled AQM Structure
2.5. Normative Requirements for a DualQ Coupled AQM
2.5.1. Functional Requirements
2.5.1.1. Requirements in Unexpected Cases
2.5.2. Management Requirements
2.5.2.1. Configuration
2.5.2.2. Monitoring
2.5.2.3. Anomaly Detection
2.5.2.4. Deployment, Coexistence, and Scaling
3. IANA Considerations
4. Security Considerations
4.1. Low Delay without Requiring Per-flow Processing
4.2. Handling Unresponsive Flows and Overload
4.2.1. Unresponsive Traffic without Overload
4.2.2. Avoiding Short-Term Classic Starvation: Sacrifice L4S
Throughput or Delay?
4.2.3. L4S ECN Saturation: Introduce Drop or Delay?
4.2.3.1. Protecting against Overload by Unresponsive
ECN-Capable Traffic
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Example DualQ Coupled PI2 Algorithm
A.1. Pass #1: Core Concepts
A.2. Pass #2: Edge-Case Details
Appendix B. Example DualQ Coupled Curvy RED Algorithm
B.1. Curvy RED in Pseudocode
B.2. Efficient Implementation of Curvy RED
Appendix C. Choice of Coupling Factor, k
C.1. RTT-Dependence
C.2. Guidance on Controlling Throughput Equivalence
Acknowledgements
Contributors
Authors' Addresses
This document specifies a framework for DualQ Coupled AQMs, which can serve as the network part of the L4S architecture [RFC9330]. A DualQ Coupled AQM consists of two queues: L4S and Classic. The L4S queue is intended for Scalable congestion controls that can maintain very low queuing latency (sub-millisecond on average) and high throughput at the same time. The Coupled DualQ acts like a semi-permeable membrane: the L4S queue isolates the sub-millisecond average queuing delay of L4S from Classic latency, while the coupling between the queues pools the capacity between both queues so that ad hoc numbers of capacity-seeking applications all sharing the same capacity can have roughly equivalent throughput per flow, whichever queue they use. The DualQ achieves this indirectly, without having to inspect transport-layer flow identifiers and without compromising the performance of the Classic traffic, relative to a single queue. The DualQ design has low complexity and requires no configuration for the public Internet.
このドキュメントは、L4Sアーキテクチャ[RFC9330]のネットワーク部分として機能するDualQ結合AQMのフレームワークを指定します。DualQ結合されたAQMは、L4とクラシックの2つのキューで構成されています。L4Sキューは、非常に低いキューイングレイテンシ（平均でサブミリ秒）を維持できるスケーラブルな輻輳制御を対象としており、同時に高スループットが高くなります。結合されたdualqは半透過性膜のように機能します。L4Sキューは、古典的なレイテンシからL4のサブミリ秒平均キューイング遅延を分離し、キュー間のカップリングは両方のキュー間の容量をプールして、容量を求める容量の適用の付加数がプールします同じ容量を共有するすべてのものは、フローごとにほぼ同等のスループットを持つことができます。DualQは、輸送層の流れ識別子を検査することなく、単一のキューと比較して古典的なトラフィックのパフォーマンスを損なうことなく、間接的にこれを実現します。DUALQ設計の複雑さは低く、パブリックインターネットの構成は必要ありません。
Latency is becoming the critical performance factor for many (perhaps most) applications on the public Internet, e.g., interactive web, web services, voice, conversational video, interactive video, interactive remote presence, instant messaging, online gaming, remote desktop, cloud-based applications, and video-assisted remote control of machinery and industrial processes. Once access network bitrates reach levels now common in the developed world, further increases offer diminishing returns unless latency is also addressed [Dukkipati06]. In the last decade or so, much has been done to reduce propagation time by placing caches or servers closer to users. However, queuing remains a major intermittent component of latency.
レイテンシは、パブリックインターネット、例えばインタラクティブなWeb、ウェブサービス、音声、会話ビデオ、インタラクティブビデオ、インタラクティブなリモートプレゼンス、インスタントメッセージング、オンラインゲーム、リモートデスクトップ、クラウド - クラウド - の多くの（おそらくほとんど）アプリケーションの重要なパフォーマンス要因になりつつあります。ベースのアプリケーション、および機械および産業プロセスのビデオ支援リモートコントロール。Access Network Bitratesが先進国で一般的なレベルに到達すると、レイテンシも対処されない限り、さらに増加するリターンが減少します[Dukkipati06]。過去10年ほどで、キャッシュやサーバーをユーザーの近くに配置することにより、伝播時間を短縮するために多くのことが行われました。ただし、キューイングは潜在性の主要な断続的なコンポーネントのままです。
Previously, very low latency has only been available for a few selected low-rate applications, that confine their sending rate within a specially carved-off portion of capacity, which is prioritized over other traffic, e.g., Diffserv Expedited Forwarding (EF) [RFC3246]. Up to now, it has not been possible to allow any number of low-latency, high throughput applications to seek to fully utilize available capacity, because the capacity-seeking process itself causes too much queuing delay.
以前は、非常に低いレイテンシは、選択されたいくつかの低レートアプリケーションでのみ利用可能でした。これにより、他のトラフィック（EF）[RFC3246など、他のトラフィックよりも優先順位付けされている容量の特別に刻まれた部分内に送信率が限定されています。]。これまで、容量を求めるプロセス自体がキューイングの遅延が大きすぎるため、利用可能な容量を完全に活用しようとする数の低い低下の高度なアプリケーションを許可することはできませんでした。
To reduce this queuing delay caused by the capacity-seeking process, changes either to the network alone or to end systems alone are in progress. L4S involves a recognition that both approaches are yielding diminishing returns:
容量を求めるプロセスによって引き起こされるこのキューイング遅延を減らすために、ネットワークのみに変更するか、システムのみを終了するように変更されています。L4には、両方のアプローチが収益の減少をもたらしているという認識が含まれます。
* Recent state-of-the-art AQM in the network, e.g., Flow Queue CoDel [RFC8290], Proportional Integral controller Enhanced (PIE) [RFC8033], and Adaptive Random Early Detection (ARED) [ARED01]), has reduced queuing delay for all traffic, not just a select few applications. However, no matter how good the AQM, the capacity-seeking (sawtoothing) rate of TCP-like congestion controls represents a lower limit that will cause either the queuing delay to vary or the link to be underutilized. These AQMs are tuned to allow a typical capacity-seeking TCP-Reno-friendly flow to induce an average queue that roughly doubles the base round-trip time (RTT), adding 5-15 ms of queuing on average for a mix of long-running flows and web traffic (cf. 500 microseconds with L4S for the same traffic mix [L4Seval22]). However, for many applications, low delay is not useful unless it is consistently low. With these AQMs, 99th percentile queuing delay is 20-30 ms (cf. 2 ms with the same traffic over L4S).
* ネットワーク内の最近の最先端のAQM、例えばフローキューコード[RFC8290]、比例積分コントローラーの強化（PIE）[RFC8033]、および適応性のあるランダム早期検出（ARED01）[ARED01]）は、キューイング遅延を減らしましたすべてのトラフィックに対して、選択されたいくつかのアプリケーションだけではありません。ただし、AQMがどれほど優れていても、TCPのような混雑コントロールの容量を求める（鋸歯状）レートは、キューイングの遅延が変化するか、リンクが十分に活用されない下限を表します。これらのAQMSは、典型的な容量を求めるTCP-Renoに優しいフローを可能にして、ベースラウンドトリップ時間（RTT）をほぼ2倍にする平均キューを誘導できるように調整され、長いミックスの平均5〜15ミリ秒のキューイングを追加します。ランニングフローとWebトラフィック（同じトラフィックミックスのL4Sを使用した500マイクロ秒を参照[L4Seval22]）。ただし、多くのアプリケーションでは、一貫して低い場合を除き、低遅延は有用ではありません。これらのAQMSでは、99パーセンタイルのキューイング遅延は20〜30ミリ秒です（L4Sで同じトラフィックで2ミリ秒を参照）。
* Similarly, recent research into using end-to-end congestion control without needing an AQM in the network (e.g., Bottleneck Bandwidth and Round-trip propagation time (BBR) [BBR-CC]) seems to have hit a similar queuing delay floor of about 20 ms on average, but there are also regular 25 ms delay spikes due to bandwidth probes and 60 ms spikes due to flow-starts.
* 同様に、ネットワーク内のAQMを必要とせずにエンドツーエンドの混雑制御を使用することに関する最近の研究（例：ボトルネックの帯域幅と往復伝播時間（BBR）[BBR-CC]）は、同様のキューイング遅延フロアにヒットしたようです平均で約20ミリ秒ですが、帯域幅プローブとフロースタートによる60ミリ秒のスパイクにより、通常の25ミリ秒の遅延スパイクもあります。
L4S learns from the experience of Data Center TCP (DCTCP) [RFC8257], which shows the power of complementary changes both in the network and on end systems. DCTCP teaches us that two small but radical changes to congestion control are needed to cut the two major outstanding causes of queuing delay variability:
L4Sは、データセンターTCP（DCTCP）[RFC8257]の経験から学習します。これは、ネットワークとエンドシステムの両方で相補的な変化の力を示しています。DCTCPは、キューイング遅延の変動の2つの主要な顕著な原因を削減するために、輻輳制御に対する2つの小さいが根本的な変化が必要であることを教えてくれます。
1. Far smaller rate variations (sawteeth) than Reno-friendly congestion controls.
1. リノにやさしい混雑制御よりもはるかに少ないレートのバリエーション（のこぎり）。
2. A shift of smoothing and hence smoothing delay from network to sender.
2. スムージングのシフト、したがって、ネットワークから送信者へのスムージング遅延。
Without the former, a 'Classic' (e.g., Reno-friendly) flow's RTT varies between roughly 1 and 2 times the base RTT between the machines in question. Without the latter, a 'Classic' flow's response to changing events is delayed by a worst-case (transcontinental) RTT, which could be hundreds of times the actual smoothing delay needed for the RTT of typical traffic from localized Content Delivery Networks (CDNs).
前者がいなければ、「クラシック」（例えば、リノフレンドリー）のフローのRTTは、問題のマシン間のベースRTTの約1倍から2倍の間で変化します。後者がなければ、変化するイベントに対する「クラシック」フローの応答は、最悪のケース（大陸横断）RTTによって遅れます。。
These changes are the two main features of the family of so-called 'Scalable' congestion controls (which include DCTCP, Prague, and Self-Clocked Rate Adaptation for Multimedia (SCReAM)). Both of these changes only reduce delay in combination with a complementary change in the network, and they are both only feasible with ECN, not drop, for the signalling:
これらの変更は、いわゆる「スケーラブルな」輻輳コントロールのファミリーの2つの主要な特徴です（DCTCP、プラハ、マルチメディアの自己2レートの適応（SCREAM））。これらの変更はどちらも、ネットワークの補完的な変化と組み合わせて遅延を減らすだけであり、どちらもシグナリングのためにDOPLではなくECNでのみ実行可能です。
1. The smaller sawteeth allow an extremely shallow ECN packet-marking threshold in the queue.
1. 小型の鋸は、キューに非常に浅いECNパケットマークのしきい値を可能にします。
2. No smoothing in the network means that every fluctuation of the queue is signalled immediately.
2. ネットワーク内の平滑化は、キューのすべての変動がすぐに通知されることを意味します。
Without ECN, either of these would lead to very high loss levels. In contrast, with ECN, the resulting high marking levels are just signals, not impairments. (Note that BBRv2 [BBRv2] combines the best of both worlds -- it works as a Scalable congestion control when ECN is available, but it also aims to minimize delay when ECN is absent.)
ECNがなければ、これらのいずれかが非常に高い損失レベルにつながります。対照的に、ECNでは、結果として生じる高いマーキングレベルは、障害ではなく信号にすぎません。（BBRV2 [BBRV2]は両方の世界の最高を組み合わせていることに注意してください。ECNが利用可能なときにスケーラブルな輻輳制御として機能しますが、ECNが存在しないときに遅延を最小限に抑えることも目指しています。）
However, until now, Scalable congestion controls (like DCTCP) did not coexist well in a shared ECN-capable queue with existing Classic (e.g., Reno [RFC5681] or CUBIC [RFC8312]) congestion controls -- Scalable controls are so aggressive that these 'Classic' algorithms would drive themselves to a small capacity share. Therefore, until now, L4S controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres (hence the name DCTCP).
ただし、これまで、スケーラブルな混雑コントロール（DCTCPなど）は、既存のクラシック（例えば、Reno [RFC5681]またはCubic [RFC8312]）の混雑コントロールと共有されたECN対応キューではうまく共存しませんでした。「クラシック」アルゴリズムは、自分自身を少量の共有に駆り立てます。したがって、これまで、L4Sコントロールは、プライベートデータセンターなどのクリーンスレート環境を配置できる場所でのみ展開できました（したがってDCTCPという名前）。
One way to solve the problem of coexistence between Scalable and Classic flows is to use a per-flow-queuing (FQ) approach such as FQ-CoDel [RFC8290]. It classifies packets by flow identifier into separate queues in order to isolate sparse flows from the higher latency in the queues assigned to heavier flows. However, if a Classic flow needs both low delay and high throughput, having a queue to itself does not isolate it from the harm it causes to itself. Also FQ approaches need to inspect flow identifiers, which is not always practical.
スケーラブルフローとクラシックフローの共存の問題を解決する1つの方法は、FQコデル[RFC8290]などの流量ごとの（FQ）アプローチを使用することです。フロー識別子によるパケットを個別のキューに分類して、重い流れに割り当てられたキューのより高い遅延からスパースフローを分離します。ただし、クラシックフローが低遅延と高スループットの両方を必要とする場合、それ自体にキューを持つことは、それがそれ自体に引き起こす危害からそれを隔離しません。また、FQアプローチでは、フロー識別子を検査する必要がありますが、これは必ずしも実用的ではありません。
In summary, Scalable congestion controls address the root cause of the latency, loss and scaling problems with Classic congestion controls. Both FQ and DualQ AQMs can be enablers for this smooth low-latency scalable behaviour. The DualQ approach is particularly useful because identifying flows is sometimes not practical or desirable.
要約すると、スケーラブルなうっ血コントロールは、古典的な混雑コントロールでの潜伏、損失、およびスケーリングの問題の根本原因に対処します。FQとDUALQ AQMSの両方が、このスムーズな低遅延スケーラブルな動作のイネーブラーになります。DualQアプローチは、フローを特定することが実用的または望ましくない場合があるため、特に便利です。
L4S involves complementary changes in the network and on end systems:
L4Sには、ネットワークとエンドシステムの補完的な変更が含まれます。
Network: A DualQ Coupled AQM (defined in the present document) or a modification to flow queue AQMs (described in paragraph "b" in Section 4.2 of the L4S architecture [RFC9330]).
ネットワーク：DualQ結合AQM（現在のドキュメントで定義）またはフローキューAQMS（L4Sアーキテクチャのセクション4.2 [RFC9330]のパラグラフ「B」で説明）をフローする修正。
End system: A Scalable congestion control (defined in Section 4 of the L4S ECN protocol spec [RFC9331]).
エンドシステム：スケーラブルな混雑制御（L4S ECNプロトコル仕様のセクション4で定義されています[RFC9331]）。
Packet identifier: The network and end-system parts of L4S can be deployed incrementally, because they both identify L4S packets using the experimentally assigned ECN codepoints in the IP header: ECT(1) and CE [RFC8311] [RFC9331].
パケット識別子：L4のネットワークおよびエンドシステムパーツは、IPヘッダーの実験的に割り当てられたECNコードポイントを使用してL4Sパケットを識別するため、段階的に展開できます。ECT（1）およびCE [RFC8311] [RFC9331]。
DCTCP [RFC8257] is an example of a Scalable congestion control for controlled environments that has been deployed for some time in Linux, Windows, and FreeBSD operating systems. During the progress of this document through the IETF, a number of other Scalable congestion controls were implemented, e.g., Prague over TCP and QUIC [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], and the L4S variant of SCReAM for real-time media [SCReAM-L4S] [RFC8298].
DCTCP [RFC8257]は、Linux、Windows、およびFreeBSDオペレーティングシステムにしばらく展開されてきた制御環境のスケーラブルな輻輳制御の例です。IETFを介したこのドキュメントの進行中に、他の多くのスケーラブルな輻輳制御が実装されました。たとえば、TCPおよびQUIC [Prague-CC] [Praguelinux]、BBRV2 [BBRV2] [BBR-CC]、およびL4Sバリアントのプラハが実装されました。リアルタイムメディアのスクリーム[Scream-L4S] [RFC8298]。
The focus of this specification is to enable deployment of the network part of the L4S service. Then, without any management intervention, applications can exploit this new network capability as the applications or their operating systems migrate to Scalable congestion controls, which can then evolve _while_ their benefits are being enjoyed by everyone on the Internet.
この仕様の焦点は、L4Sサービスのネットワーク部分の展開を有効にすることです。その後、管理介入がなければ、アプリケーションがアプリケーションまたはそのオペレーティングシステムがスケーラブルな混雑コントロールに移行するにつれて、アプリケーションはこの新しいネットワーク機能を活用できます。
The DualQ Coupled AQM framework can incorporate any AQM designed for a single queue that generates a statistical or deterministic mark/ drop probability driven by the queue dynamics. Pseudocode examples of two different DualQ Coupled AQMs are given in the appendices. In many cases the framework simplifies the basic control algorithm and requires little extra processing. Therefore, it is believed the Coupled AQM would be applicable and easy to deploy in all types of buffers such as buffers in cost-reduced mass-market residential equipment; buffers in end-system stacks; buffers in carrier-scale equipment including remote access servers, routers, firewalls, and Ethernet switches; buffers in network interface cards; buffers in virtualized network appliances, hypervisors; and so on.
DUALQ結合されたAQMフレームワークには、キューダイナミクスによって駆動される統計的または決定論的マーク/ドロップ確率を生成する単一キュー用に設計されたAQMを組み込むことができます。2つの異なるDUALQ結合AQMの擬似コード例は、付録に示されています。多くの場合、フレームワークは基本的な制御アルゴリズムを簡素化し、追加の処理はほとんど必要ありません。したがって、結合されたAQMが適用可能であり、コスト削減の大衆市場住宅用品のバッファなど、あらゆる種類のバッファーに簡単に展開できると考えられています。エンドシステムスタックのバッファー。リモートアクセスサーバー、ルーター、ファイアウォール、イーサネットスイッチなど、キャリアスケールの機器のバッファー。ネットワークインターフェイスカードのバッファー。仮想化されたネットワークアプライアンス、ハイパーバイザーのバッファー。等々。
For the public Internet, nearly all the benefit will typically be achieved by deploying the Coupled AQM into either end of the access link between a 'site' and the Internet, which is invariably the bottleneck (see Section 6.4 of [RFC9330] about deployment, which also defines the term 'site' to mean a home, an office, a campus, or mobile user equipment).
パブリックインターネットの場合、ほぼすべての利益は、通常、「サイト」とインターネットの間のアクセスリンクのいずれかの端に結合されたAQMを展開することで達成されます。また、「サイト」という用語は、家、オフィス、キャンパス、またはモバイルユーザー機器を意味することを定義しています）。
Latency is not the only concern of L4S:
L4の唯一の懸念はレイテンシだけではありません：
* The 'Low Loss' part of the name denotes that L4S generally achieves zero congestion loss (which would otherwise cause retransmission delays), due to its use of ECN.
* 名前の「低損失」部分は、ECNの使用により、L4Sが一般に混雑損失がゼロになっていることを示しています（そうでなければ再送信の遅延を引き起こすでしょう）。
* The 'Scalable throughput' part of the name denotes that the per-flow throughput of Scalable congestion controls should scale indefinitely, avoiding the imminent scaling problems with 'TCP-Friendly' congestion control algorithms [RFC3649].
* 名前の「スケーラブルなスループット」の部分は、スケーラブル輻輳制御のフローごとのスループットが無期限にスケーリングする必要があることを示しており、「TCPに優しい」輻輳制御アルゴリズム[RFC3649]の差し迫ったスケーリング問題を回避します。
The former is clearly in scope of this AQM document. However, the latter is an outcome of the end-system behaviour and is therefore outside the scope of this AQM document, even though the AQM is an enabler.
前者は明らかにこのAQMドキュメントの範囲にあります。ただし、後者は最終システムの動作の結果であるため、AQMがイネーブラーであるにもかかわらず、このAQMドキュメントの範囲外です。
The overall L4S architecture [RFC9330] gives more detail, including on wider deployment aspects such as backwards compatibility of Scalable congestion controls in bottlenecks where a DualQ Coupled AQM has not been deployed. The supporting papers [L4Seval22], [DualPI2Linux], [PI2], and [PI2param] give the full rationale for the AQM design, both discursively and in more precise mathematical form, as well as the results of performance evaluations. The main results have been validated independently when using the Prague congestion control [Boru20] (experiments are run using Prague and DCTCP, but only the former is relevant for validation, because Prague fixes a number of problems with the Linux DCTCP code that make it unsuitable for the public Internet).
全体的なL4Sアーキテクチャ[RFC9330]は、DualQ結合されたAQMが展開されていないボトルネックのスケーラブルな混雑コントロールの後方互換性などの幅広い展開の側面など、より詳細な詳細を提供します。サポートペーパー[L4Seval22]、[Dualpi2linux]、[Pi2]、および[Pi2Param]は、AQM設計の完全な根拠を示しています。主な結果は、プラハの混雑制御[BORU20]を使用する場合は独立して検証されています（PragueとDCTCPを使用して実験は実行されますが、Pragueは検証に関連しています。パブリックインターネット用）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The DualQ Coupled AQM uses two queues for two services:
Dualq結合されたAQMは、2つのサービスに2つのキューを使用しています。
Classic Service/Queue: The Classic service is intended for all the congestion control behaviours that coexist with Reno [RFC5681] (e.g., Reno itself, CUBIC [RFC8312], and TFRC [RFC5348]). The term 'Classic queue' means a queue providing the Classic service.
クラシックサービス/キュー：クラシックサービスは、Reno [RFC5681]（例えば、Reno自体、Cubic [RFC8312]、およびTFRC [RFC5348]と共存するすべての輻輳制御行動を対象としています。「クラシックキュー」という用語は、クラシックサービスを提供するキューを意味します。
Low Latency, Low Loss, and Scalable throughput (L4S) Service/ Queue: The 'L4S' service is intended for traffic from Scalable congestion control algorithms, such as the Prague congestion control [PRAGUE-CC], which was derived from Data Center TCP [RFC8257]. The L4S service is for more general traffic than just Prague -- it allows the set of congestion controls with similar scaling properties to Prague to evolve, such as the examples listed below (Relentless, SCReAM, etc.). The term 'L4S queue' means a queue providing the L4S service.
低レイテンシ、低損失、スケーラブルスループット（L4S）サービス/キュー：「L4S」サービスは、データセンターTCPから導出されたPrague輻輳制御[Prague-CC]などのスケーラブルな混雑制御アルゴリズムからのトラフィックを対象としています。[RFC8257]。L4Sサービスは、単なるプラハよりも一般的なトラフィックを対象としています。これにより、以下にリストされている例（容赦ない、叫びなど）など、プラハと同様のスケーリング特性を持つ一連の混雑コントロールを可能にします。「L4Sキュー」という用語は、L4Sサービスを提供するキューを意味します。
Classic Congestion Control: A congestion control behaviour that can coexist with standard Reno [RFC5681] without causing significantly negative impact on its flow rate [RFC5033]. With Classic congestion controls, such as Reno or CUBIC, because flow rate has scaled since TCP congestion control was first designed in 1988, it now takes hundreds of round trips (and growing) to recover after a congestion signal (whether a loss or an ECN mark) as shown in the examples in Section 5.1 of the L4S architecture [RFC9330] and in [RFC3649]. Therefore, control of queuing and utilization becomes very slack, and the slightest disturbances (e.g., from new flows starting) prevent a high rate from being attained.
古典的な混雑制御：流量に大きな悪影響を与えることなく、標準のリノ[RFC5681]と共存できる混雑制御挙動[RFC5033]。RenoやCubicなどの古典的な混雑コントロールにより、TCP混雑制御が1988年に設計されてから流量が拡大しているため、渋滞信号（損失またはECNのいずれか）の後に回復するには数百の往復（および成長）が必要です。マーク）L4Sアーキテクチャ[RFC9330]および[RFC3649]のセクション5.1の例に示されているように。したがって、キューイングと使用率の制御は非常に緩くなり、わずかな乱れ（例えば、新しいフローからの開始から）が達成されないようにします。
Scalable Congestion Control: A congestion control where the average time from one congestion signal to the next (the recovery time) remains invariant as flow rate scales, all other factors being equal. This maintains the same degree of control over queuing and utilization whatever the flow rate, as well as ensuring that high throughput is robust to disturbances. For instance, DCTCP averages 2 congestion signals per round trip, whatever the flow rate, as do other recently developed Scalable congestion controls, e.g., Relentless TCP [RELENTLESS], Prague [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], and the L4S variant of SCReAM for real-time media [SCReAM-L4S] [RFC8298]. For the public Internet, a Scalable transport has to comply with the requirements in Section 4 of [RFC9331] (a.k.a. the 'Prague L4S requirements').
スケーラブルな混雑制御：1つの輻輳信号から次の輻輳信号までの平均時間（回復時間）までの平均時間が、流量スケールとして不変のままで、他のすべての要因が等しい場合。これにより、流量が何であれ、キューイングと利用に対する同じ程度の制御が維持され、高スループットが乱れに堅牢であることを保証します。たとえば、DCTCPは、最近開発された他のスケーラブルな混雑コントロール、例えば容赦ないTCP [容赦ない]、プラハ[Prague-cc] [Praguelinux]、Bbrv2 [BBRV2] [BBRと同様に、流量が何であれ、往復あたり2つの混雑信号を平均します。-CC]、およびリアルタイムメディアのスクリームのL4Sバリアント[Scream-L4S] [RFC8298]。パブリックインターネットの場合、スケーラブルなトランスポートは、[RFC9331]のセクション4の要件に準拠する必要があります（別名「プラハL4S要件」）。
C: Abbreviation for Classic, e.g., when used as a subscript.
C：サブスクリプトとして使用する場合のクラシックの略語。
L: Abbreviation for L4S, e.g., when used as a subscript.
L：L4Sの略語、例えば、添え字として使用する場合。
The terms Classic or L4S can also qualify other nouns, such as 'codepoint', 'identifier', 'classification', 'packet', and 'flow'. For example, an L4S packet means a packet with an L4S identifier sent from an L4S congestion control.
ClassicまたはL4Sという用語は、「CodePoint」、「識別子」、「分類」、「パケット」、「フロー」などの他の名詞を認定することもできます。たとえば、L4Sパケットとは、L4Sの混雑制御から送信されたL4S識別子を備えたパケットを意味します。
Both Classic and L4S services can cope with a proportion of unresponsive or less-responsive traffic as well but, in the L4S case, its rate has to be smooth enough or low enough to not build a queue (e.g., DNS, Voice over IP (VoIP), game sync datagrams, etc.). The DualQ Coupled AQM behaviour is defined to be similar to a single First-In, First-Out (FIFO) queue with respect to unresponsive and overload traffic.
クラシックサービスとL4Sサービスはどちらも、反応しないまたは応答性の低いトラフィックの割合にも対処できますが、L4Sの場合、そのレートはキューを構築しないほど十分にスムーズまたは低くなければなりません（例：DNS、Voice over IP（VoIP）、ゲーム同期データグラムなど）。DUALQ結合されたAQM動作は、無反応および過負荷トラフィックに関して、最初の最初の（FIFO）キューに似ていると定義されます。
Reno-friendly: The subset of Classic traffic that is friendly to the standard Reno congestion control defined for TCP in [RFC5681]. The TFRC spec [RFC5348] indirectly implies that 'friendly' is defined as "generally within a factor of two of the sending rate of a TCP flow under the same conditions". 'Reno-friendly' is used here in place of 'TCP-friendly', given the latter has become imprecise, because the TCP protocol is now used with so many different congestion control behaviours, and Reno is used in non-TCP transports, such as QUIC [RFC9000].
リノフレンドリー：[RFC5681]のTCPに対して定義された標準的なリノ輻輳制御に友好的な古典的なトラフィックのサブセット。TFRC Spec [RFC5348]は、「フレンドリー」が「一般に、同じ条件下でTCPフローの送信率の2倍内」と定義されることを間接的に暗示しています。TCPプロトコルは現在非常に多くの異なる渋滞制御行動で使用されているため、「TCPフレンドリー」の代わりに「TCPフレンドリー」の代わりに「リノフレンドリー」が使用されています。QUIC [RFC9000]。
DualQ or DualQ AQM: Used loosely as shorthand for a Dual-Queue Coupled AQM, where the context makes 'Coupled AQM' obvious.
dualqまたはdualq aqm：デュアルキュー結合AQMの速記としてゆるく使用されます。コンテキストは「結合されたAQM」を明らかにします。
Classic ECN: The original Explicit Congestion Notification (ECN) protocol [RFC3168] that requires ECN signals to be treated as equivalent to drops, both when generated in the network and when responded to by the sender.
古典的なECN：ネットワークで生成された場合と送信者が応答した場合の両方で、ECN信号をドロップに相当するものとして扱う必要がある、元の明示的な混雑通知（ECN）プロトコル[RFC3168]。
For L4S, the names used for the four codepoints of the 2-bit IP-ECN field are unchanged from those defined in the ECN spec [RFC3168], i.e., Not-ECT, ECT(0), ECT(1), and CE, where ECT stands for ECN-Capable Transport and CE stands for Congestion Experienced. A packet marked with the CE codepoint is termed 'ECN-marked' or sometimes just 'marked' where the context makes ECN obvious.
L4Sの場合、2ビットIP-ECNフィールドの4つのコードポイントに使用される名前は、ECN仕様[RFC3168]で定義されているもの、つまり、not-ect、ect（0）、ect（1）、およびceから変化していません。、ECTはECN対応輸送の略で、CEが経験した混雑の略です。CEコードポイントでマークされたパケットは、「ECNマーク」と呼ばれるか、コンテキストがECNを明らかにする場合、「マーク」と呼ばれます。
The AQM couples marking and/or dropping from the Classic queue to the L4S queue in such a way that a flow will get roughly the same throughput whichever it uses. Therefore, both queues can feed into the full capacity of a link, and no rates need to be configured for the queues. The L4S queue enables Scalable congestion controls like DCTCP or Prague to give very low and consistently low latency, without compromising the performance of competing 'Classic' Internet traffic.
AQMは、クラシックキューからL4Sキューにマーキングおよび/またはドロップし、フローがどちらの場合でもほぼ同じスループットを取得するようにカップルします。したがって、どちらのキューもリンクの全容量にフィードを供給することができ、キュー用に料金を構成する必要はありません。L4Sキューは、競合する「クラシック」インターネットトラフィックのパフォーマンスを損なうことなく、DCTCPやプラハなどのスケーラブルな混雑制御を非常に低く、一貫して低レイテンシを与えることができます。
Thousands of tests have been conducted in a typical fixed residential broadband setting. Experiments used a range of base round-trip delays up to 100 ms and link rates up to 200 Mb/s between the data centre and home network, with varying amounts of background traffic in both queues. For every L4S packet, the AQM kept the average queuing delay below 1 ms (or 2 packets where serialization delay exceeded 1 ms on slower links), with the 99th percentile being no worse than 2 ms. No losses at all were introduced by the L4S AQM. Details of the extensive experiments are available in [L4Seval22] and [DualPI2Linux]. Subjective testing using very demanding high-bandwidth low-latency applications over a single shared access link is also described in [L4Sdemo16] and summarized in Section 6.1 of the L4S architecture [RFC9330].
数千のテストが、典型的な固定住宅ブロードバンド設定で実施されています。実験では、データセンターとホームネットワークの間で最大100ミリ秒のベースラウンドトリップ遅延と最大200 MB/sのリンクレートを使用し、両方のキューでさまざまなバックグラウンドトラフィックがありました。L4Sパケットごとに、AQMは平均キューイング遅延を1ミリ秒（または、シリアル化遅延が遅いリンクで1ミリ秒を超えた2つのパケット）を維持し、99パーセンタイルは2 msを超えていません。L4S AQMによって導入された損失はまったくありませんでした。広範な実験の詳細は、[L4Seval22]および[dualpi2linux]で入手できます。単一の共有アクセスリンクを介した非常に厳しい高帯域幅低遅延アプリケーションを使用した主観的テストは、[L4SDEMO16]でも説明されており、L4Sアーキテクチャ[RFC9330]のセクション6.1に要約されています。
In all these experiments, the host was connected to the home network by fixed Ethernet, in order to quantify the queuing delay that can be achieved by a user who cares about delay. It should be emphasized that L4S support at the bottleneck link cannot 'undelay' bursts introduced by another link on the path, for instance by legacy Wi-Fi equipment. However, if L4S support is added to the queue feeding the _outgoing_ WAN link of a home gateway, it would be counterproductive not to also reduce the burstiness of the _incoming_ Wi-Fi. Also, trials of Wi-Fi equipment with an L4S DualQ Coupled AQM on the _outgoing_ Wi-Fi interface are in progress, and early results of an L4S DualQ Coupled AQM in a 5G radio access network testbed with emulated outdoor cell edge radio fading are given in [L4S_5G].
これらすべての実験で、ホストは、遅延を気にするユーザーが達成できるキューイング遅延を定量化するために、固定イーサネットによってホームネットワークに接続されました。BottleneckリンクでのL4Sサポートは、たとえばレガシーWi-Fi機器によってパス上の別のリンクによって導入される「アンデレイ」バーストではないことを強調する必要があります。ただし、ホームゲートウェイの_outovering_wanリンクに供給されるキューにL4Sサポートが追加された場合、_incoming_wi-fiの破裂も減らないことは逆効果です。また、_outovering_Wi-FiインターフェイスのL4S DualQ結合AQMを使用したWi-Fi機器のトライアルが進行中であり、エミュレートされた屋外セルエッジラジオフェードを備えた5G無線アクセスネットワークのL4S DualQ結合AQMの初期の結果が与えられます[L4S_5G]で。
Unlike Diffserv EF, the L4S queue does not have to be limited to a small proportion of the link capacity in order to achieve low delay. The L4S queue can be filled with a heavy load of capacity-seeking flows (Prague, BBRv2, etc.) and still achieve low delay. The L4S queue does not rely on the presence of other traffic in the Classic queue that can be 'overtaken'. It gives low latency to L4S traffic whether or not there is Classic traffic. The tail latency of traffic served by the Classic AQM is sometimes a little better, sometimes a little worse, when a proportion of the traffic is L4S.
Diffserv EFとは異なり、L4Sキューは、低遅延を達成するためにリンク容量の少量に制限する必要はありません。L4Sキューは、容量を求めるフロー（プラハ、BBRV2など）で大量に満たされ、遅延が低いことがあります。L4Sキューは、「追い越す」可能性のある古典的なキューに他のトラフィックの存在に依存していません。古典的なトラフィックがあるかどうかにかかわらず、L4Sトラフィックに遅延が低くなります。古典的なAQMが提供するトラフィックのテールレイテンシは、トラフィックの割合がL4Sである場合、少し良く、時には少し悪い場合もあります。
The two queues are only necessary because:
次のために、2つのキューは必要です。
* The large variations (sawteeth) of Classic flows need roughly a base RTT of queuing delay to ensure full utilization.
* 古典的なフローの大きなバリエーション（のこぎり）は、完全な使用率を確保するために、キューイング遅延のベースRTTをほぼベースRTTする必要があります。
* Scalable flows do not need a queue to keep utilization high, but they cannot keep latency consistently low if they are mixed with Classic traffic.
* スケーラブルなフローは、使用率を高く保つためにキューを必要としませんが、古典的なトラフィックと混合されている場合、レイテンシを一貫して低く保つことはできません。
The L4S queue has latency priority within sub-round-trip timescales, but over longer periods the coupling from the Classic to the L4S AQM (explained below) ensures that it does not have bandwidth priority over the Classic queue.
L4Sキューは、サブラウンドトリップタイムスケール内でレイテンシの優先順位を持っていますが、長期にわたってクラシックからL4S AQMへの結合（以下で説明）により、クラシックキューよりも帯域幅の優先度がないことが保証されます。
There are two main aspects to the DualQ Coupled AQM approach:
DualQ結合されたAQMアプローチには、2つの主な側面があります。
1. The Coupled AQM that addresses throughput equivalence between Classic (e.g., Reno or CUBIC) flows and L4S flows (that satisfy the Prague L4S requirements).
1. クラシック（リノまたはキュービックなど）のフローとL4Sフロー（プラハL4S要件を満たす）のスループットの等価性に対処する結合されたAQM。
2. The Dual-Queue structure that provides latency separation for L4S flows to isolate them from the typically large Classic queue.
2. L4Sのレイテンシー分離を提供するデュアルキュー構造は、通常の大きな古典的なキューからそれらを分離するために流れます。
In the 1990s, the 'TCP formula' was derived for the relationship between the steady-state congestion window, cwnd, and the drop probability, p of standard Reno congestion control [RFC5681]. To a first-order approximation, the steady-state cwnd of Reno is inversely proportional to the square root of p.
1990年代には、「TCP式」は、定常状態の混雑ウィンドウCWNDと標準リノ輻輳制御[RFC5681]の低下確率の関係について導き出されました。一次近似に、リノの定常状態のCWNDは、pの平方根に反比例します。
The design focuses on Reno as the worst case, because if it does no harm to Reno, it will not harm CUBIC or any traffic designed to be friendly to Reno. TCP CUBIC implements a Reno-friendly mode, which is relevant for typical RTTs under 20 ms as long as the throughput of a single flow is less than about 350 Mb/s. In such cases, it can be assumed that CUBIC traffic behaves similarly to Reno. The term 'Classic' will be used for the collection of Reno-friendly traffic including CUBIC and potentially other experimental congestion controls intended not to significantly impact the flow rate of Reno.
デザインは最悪の場合にリノに焦点を当てています。なぜなら、リノに害を及ぼさない場合、キュービックやリノに友好的になるように設計されたトラフィックに害を及ぼさないからです。TCPキュービックは、単一のフローのスループットが約350 MB/s未満である限り、20ミリ秒未満の典型的なRTTに関連するリノフレンドリーモードを実装します。そのような場合、キュービック交通はリノと同様に動作すると想定できます。「クラシック」という用語は、キュービックや潜在的に他の実験的混雑コントロールを含むリノに優しいトラフィックの収集に使用されます。
A supporting paper [PI2] includes the derivation of the equivalent rate equation for DCTCP, for which cwnd is inversely proportional to p (not the square root), where in this case p is the ECN-marking probability. DCTCP is not the only congestion control that behaves like this, so the term 'Scalable' will be used for all similar congestion control behaviours (see examples in Section 1.2). The term 'L4S' is used for traffic driven by a Scalable congestion control that also complies with the additional 'Prague L4S requirements' [RFC9331].
サポートペーパー[PI2]には、CWNDがP（平方根ではなく）に反比例するDCTCPの等価速度方程式の導出が含まれます。この場合、PはECNマークの確率です。DCTCPはこのように振る舞う唯一の混雑制御ではないため、「スケーラブル」という用語は、すべての同様の混雑制御動作に使用されます（セクション1.2の例を参照）。「L4S」という用語は、追加の「プラハL4S要件」[RFC9331]にも準拠するスケーラブルな輻輳制御によって駆動されるトラフィックに使用されます。
For safe coexistence, under stationary conditions, a Scalable flow has to run at roughly the same rate as a Reno TCP flow (all other factors being equal). So the drop or marking probability for Classic traffic, p_C, has to be distinct from the marking probability for L4S traffic, p_L. The original ECN spec [RFC3168] required these probabilities to be the same, but [RFC8311] updates [RFC3168] to enable experiments in which these probabilities are different.
安全な共存の場合、定常条件下では、スケーラブルなフローは、リノTCPフロー（他のすべての要因が等しい）とほぼ同じ速度で実行する必要があります。したがって、古典的なトラフィックであるP_Cのドロップまたはマーキング確率は、L4SトラフィックP_Lのマーキング確率とは異なる必要があります。元のECN仕様[RFC3168]はこれらの確率を同じであることを要求しましたが、[RFC8311]は[RFC3168]を更新して、これらの確率が異なる実験を可能にします。
Also, to remain stable, Classic sources need the network to smooth p_C so it changes relatively slowly. It is hard for a network node to know the RTTs of all the flows, so a Classic AQM adds a _worst-case_ RTT of smoothing delay (about 100-200 ms). In contrast, L4S shifts responsibility for smoothing ECN feedback to the sender, which only delays its response by its _own_ RTT, as well as allowing a more immediate response if necessary.
また、安定したままであるために、古典的なソースはP_Cをスムーズにするためにネットワークを必要とするため、比較的ゆっくりと変化します。ネットワークノードがすべてのフローのRTTを知るのは難しいため、クラシックAQMは、スムージング遅延（約100〜200ミリ秒）の_Worst-Case_RTTを追加します。対照的に、L4Sは、ECNフィードバックを送信者にスムーズ化する責任をシフトします。これは、_Own_ RTTによってのみ応答を遅らせるだけでなく、必要に応じてより即時の応答を可能にします。
The Coupled AQM achieves safe coexistence by making the Classic drop probability p_C proportional to the square of the coupled L4S probability p_CL. p_CL is an input to the instantaneous L4S marking probability p_L, but it changes as slowly as p_C. This makes the Reno flow rate roughly equal the DCTCP flow rate, because the squaring of p_CL counterbalances the square root of p_C in the 'TCP formula' of Classic Reno congestion control.
結合されたAQMは、結合されたL4S確率P_CLの正方形に比例した古典的なドロップ確率P_Cを作成することにより、安全な共存を実現します。P_CLは、瞬時のL4Sマーキング確率P_Lへの入力ですが、P_Cと同じくらいゆっくりと変化します。これにより、P_CLの正方形が古典的なリノ輻輳制御の「TCPフォーミュラ」のP_Cの平方根を相殺するため、リノの流量がDCTCP流量にほぼ等しくなります。
Stating this as a formula, the relation between Classic drop probability, p_C, and the coupled L4S probability p_CL needs to take the following form:
これを式として述べる、古典的なドロップ確率、P_C、および結合されたL4S確率P_CLの関係は、次の形式を取る必要があります。
p_C = ( p_CL / k )^2, (1)
where k is the constant of proportionality, which is termed the 'coupling factor'.
ここで、kは「カップリング係数」と呼ばれる比例定数です。
Classic traffic needs to build a large queue to prevent underutilization. Therefore, a separate queue is provided for L4S traffic, and it is scheduled with priority over the Classic queue. Priority is conditional to prevent starvation of Classic traffic in certain conditions (see Section 2.4).
古典的なトラフィックは、十分な活用を防ぐために大きなキューを構築する必要があります。したがって、L4Sトラフィックには別のキューが提供され、クラシックキューよりも優先されます。優先度は、特定の条件での古典的なトラフィックの飢vを防ぐための条件です（セクション2.4を参照）。
Nonetheless, coupled marking ensures that giving priority to L4S traffic still leaves the right amount of spare scheduling time for Classic flows to each get equivalent throughput to DCTCP flows (all other factors, such as RTT, being equal).
それにもかかわらず、結合マーキングにより、L4Sトラフィックに優先順位を与えることにより、クラシックフローに適切な量の予備のスケジューリング時間が残っていることが保証されます。
Both the Coupled AQM and DualQ mechanisms need an identifier to distinguish L4S (L) and Classic (C) packets. Then the coupling algorithm can achieve coexistence without having to inspect flow identifiers, because it can apply the appropriate marking or dropping probability to all flows of each type. A separate specification [RFC9331] requires the network to treat the ECT(1) and CE codepoints of the ECN field as this identifier. An additional process document has proved necessary to make the ECT(1) codepoint available for experimentation [RFC8311].
結合されたAQMとDUALQメカニズムの両方には、L4S（L）とクラシック（C）パケットを区別するための識別子が必要です。次に、カップリングアルゴリズムは、各タイプのすべてのフローに適切なマーキングまたはドロップの確率を適用できるため、フロー識別子を検査することなく共存を実現できます。個別の仕様[RFC9331]では、この識別子としてECNフィールドのECT（1）とCEコードポイントを処理するためのネットワークが必要です。ECT（1）CodePointを実験に利用できるようにするために、追加のプロセスドキュメントが必要であることが証明されています[RFC8311]。
For policy reasons, an operator might choose to steer certain packets (e.g., from certain flows or with certain addresses) out of the L queue, even though they identify themselves as L4S by their ECN codepoints. In such cases, the L4S ECN protocol [RFC9331] states that the device "MUST NOT alter the end-to-end L4S ECN identifier" so that it is preserved end to end. The aim is that each operator can choose how it treats L4S traffic locally, but an individual operator does not alter the identification of L4S packets, which would prevent other operators downstream from making their own choices on how to treat L4S traffic.
政策上の理由から、オペレーターは、ECNコードポイントによってL4として自分自身を識別している場合でも、特定のパケット（特定のフローまたは特定のアドレスから）をLキューから操作することを選択する場合があります。このような場合、L4S ECNプロトコル[RFC9331]は、デバイスが「エンドツーエンドのL4S ECN識別子を変更してはならない」と述べているため、端から端まで保存されます。目的は、各オペレーターがL4Sトラフィックをローカルでどのように扱うかを選択できることですが、個々のオペレーターはL4Sパケットの識別を変更しないことです。
In addition, an operator could use other identifiers to classify certain additional packet types into the L queue that it deems will not risk harm to the L4S service, for instance, addresses of specific applications or hosts; specific Diffserv codepoints such as EF, Voice-Admit, or the Non-Queue-Building (NQB) per-hop behaviour; or certain protocols (e.g., ARP and DNS) (see Section 5.4.1 of [RFC9331]. Note that [RFC9331] states that "a network node MUST NOT change Not-ECT or ECT(0) in the IP-ECN field into an L4S identifier." Thus, the L queue is not solely an L4S queue; it can be considered more generally as a low-latency queue.
さらに、オペレーターは他の識別子を使用して、特定のアプリケーションまたはホストのアドレスなど、L4Sサービスに害を及ぼさないと思われるLキューに特定の追加パケットタイプを分類することができます。EF、ボイスアドミット、または非キュービルディング（NQB）1ホップごとの動作などの特定のDiffServ CodePoints。または特定のプロトコル（例：ARPおよびDNS）（[RFC9331]のセクション5.4.1を参照してください。[RFC9331]は、「ネットワークノードは、IP-ECNフィールドのNot-ectまたはEct（0）を変更してはならないと述べています。したがって、Lキューは単にL4Sキューではありません。より一般的に低遅延キューと見なすことができます。
Figure 1 shows the overall structure that any DualQ Coupled AQM is likely to have. This schematic is intended to aid understanding of the current designs of DualQ Coupled AQMs. However, it is not intended to preclude other innovative ways of satisfying the normative requirements in Section 2.5 that minimally define a DualQ Coupled AQM. Also, the schematic only illustrates operation under normally expected circumstances; behaviour under overload or with operator-specific classifiers is deferred to Section 2.5.1.1.
図1は、DUALQ結合されたAQMが持っている可能性が高い全体の構造を示しています。この概略図は、DualQ結合されたAQMの現在の設計の理解を支援することを目的としています。ただし、DualQ結合されたAQMを最小限に定義するセクション2.5の規範的要件を満たす他の革新的な方法を排除することを意図したものではありません。また、回路図は、通常予想される状況下での操作のみを示しています。過負荷またはオペレーター固有の分類器を使用した動作は、セクション2.5.1.1に延期されます。
The classifier on the left separates incoming traffic between the two queues (L and C). Each queue has its own AQM that determines the likelihood of marking or dropping (p_L and p_C). In [PI2], it has been proved that it is preferable to control load with a linear controller, then square the output before applying it as a drop probability to Reno-friendly traffic (because Reno congestion control decreases its load proportional to the square root of the increase in drop). So, the AQM for Classic traffic needs to be implemented in two stages: i) a base stage that outputs an internal probability p' (pronounced 'p-prime') and ii) a squaring stage that outputs p_C, where
左の分類器は、2つのキュー（LとC）の間の入っているトラフィックを分離します。各キューには、マークまたはドロップの可能性を決定する独自のAQMがあります（P_LおよびP_C）。[PI2]では、線形コントローラーで負荷を制御することが望ましいことが証明されています。その後、出力を角にしてから、リノに優しいトラフィックにドロップ確率として適用します（リノ輻輳制御は四角根に比例して負荷を減らすためドロップの増加の）。したがって、クラシックトラフィックのAQMは、2つの段階で実装する必要があります。i）内部確率p '（「p-prime」と発音）を出力するベースステージとii）p_cを出力する二乗ステージ、ここで
p_C = (p')^2. (2)
Substituting for p_C in equation (1) gives
式（1）のP_Cの代わりになります
p' = p_CL / k.
p '= p_cl / k。
So the slow-moving input to ECN marking in the L queue (the coupled L4S probability) is
したがって、Lキュー内のECNマーキングへのゆっくりと動く入力（結合されたL4S確率）は
p_CL = k*p'. (3)
p_cl = k*p '。（3）
The actual ECN-marking probability p_L that is applied to the L queue needs to track the immediate L queue delay under L-only congestion conditions, as well as track p_CL under coupled congestion conditions. So the L queue uses a 'Native AQM' that calculates a probability p'_L as a function of the instantaneous L queue delay. And given the L queue has conditional priority over the C queue, whenever the L queue grows, the AQM ought to apply marking probability p'_L, but p_L ought to not fall below p_CL. This suggests
Lキューに適用される実際のECNマーキング確率P_Lは、Lのみの混雑条件下で即時のLキュー遅延を追跡する必要があります。したがって、Lキューは、瞬時のLキュー遅延の関数として確率p'_Lを計算する「ネイティブAQM」を使用します。また、lキューがキューよりも条件付き優先度があることを考えると、Lキューが成長するたびに、AQMはマーク確率P'_Lを適用する必要がありますが、P_LはP_CLを下回ってはなりません。これは示唆しています
p_L = max(p'_L, p_CL), (4)
p_l = max（p'_l、p_cl）、（4）
which has also been found to work very well in practice.
また、実際には非常にうまく機能することがわかっています。
The two transformations of p' in equations (2) and (3) implement the required coupling given in equation (1) earlier.
方程式（2）および（3）のp 'の2つの変換は、式（1）に必要な必要な結合を以前に実装します。
The constant of proportionality or coupling factor, k, in equation (1) determines the ratio between the congestion probabilities (loss or marking) experienced by L4S and Classic traffic. Thus, k indirectly determines the ratio between L4S and Classic flow rates, because flows (assuming they are responsive) adjust their rate in response to congestion probability. Appendix C.2 gives guidance on the choice of k and its effect on relative flow rates.
式（1）の比例または結合係数の定数Kは、L4Sが経験する混雑確率（損失またはマーキング）と古典的なトラフィックの比率を決定します。したがって、kは、混雑確率に応答してフロー（応答性が高いと仮定）を調整するため、L4と古典的な流量の比を間接的に決定します。付録C.2は、Kの選択と相対流量に対するその影響に関するガイダンスを示しています。
_________
| | ,------.
L4S (L) queue | |===>| ECN |
,'| _______|_| |marker|\
<' | | `------'\\
//`' v ^ p_L \\
// ,-------. | \\
// |Native |p'_L | \\,.
// | L4S |--->(MAX) < | ___
,----------.// | AQM | ^ p_CL `\|.'Cond-`.
| IP-ECN |/ `-------' | / itional \
==>|Classifier| ,-------. (k*p') [ priority]==>
| |\ | Base | | \scheduler/
`----------'\\ | AQM |---->: ,'|`-.___.-'
\\ | |p' | <' |
\\ `-------' (p'^2) //`'
\\ ^ | //
\\,. | v p_C //
< | _________ .------.//
`\| | | | Drop |/
Classic (C) |queue |===>|/mark |
__|______| `------'
Legend: ===> traffic flow
---> control dependency
Figure 1: DualQ Coupled AQM Schematic
図1：DualQ結合AQM回路図
After the AQMs have applied their dropping or marking, the scheduler forwards their packets to the link. Even though the scheduler gives priority to the L queue, it is not as strong as the coupling from the C queue. This is because, as the C queue grows, the 'Base AQM' applies more congestion signals to L traffic (as well as to C). As L flows reduce their rate in response, they use less than the scheduling share for L traffic. So, because the scheduler is work preserving, it schedules any C traffic in the gaps.
AQMSがドロップまたはマーキングを適用した後、スケジューラはパケットをリンクに転送します。スケジューラはLキューを優先していますが、Cキューからのカップリングほど強くはありません。これは、Cキューが成長するにつれて、「ベースAQM」がLトラフィック（およびC）に対してより多くの混雑信号を適用するためです。Lフローがそれに応じてレートを下げると、Lトラフィックのスケジューリングシェアよりも少ない使用があります。したがって、スケジューラは動作しているため、ギャップ内のCトラフィックをスケジュールします。
Giving priority to the L queue has the benefit of very low L queue delay, because the L queue is kept empty whenever L traffic is controlled by the coupling. Also, there only has to be a coupling in one direction -- from Classic to L4S. Priority has to be conditional in some way to prevent the C queue from being starved in the short term (see Section 4.2.2) to give C traffic a means to push in, as explained next. With normal responsive L traffic, the coupled ECN marking gives C traffic the ability to push back against even strict priority, by congestion marking the L traffic to make it yield some space. However, if there is just a small finite set of C packets (e.g., a DNS request or an initial window of data), some Classic AQMs will not induce enough ECN marking in the L queue, no matter how long the small set of C packets waits. Then, if the L queue happens to remain busy, the C traffic would never get a scheduling opportunity from a strict priority scheduler. Ideally, the Classic AQM would be designed to increase the coupled marking the longer that C packets have been waiting, but this is not always practical -- hence the need for L priority to be conditional. Giving a small weight or limited waiting time for C traffic improves response times for short Classic messages, such as DNS requests, and improves Classic flow startup because immediate capacity is available.
Lキューを優先することは、Lキューがカップリングによって制御されるたびに空に保たれるため、非常に低いLキュー遅延の利点があります。また、クラシックからL4まで、一方向に結合が必要です。次に説明するように、Cキューが短期的に飢えているのを防ぐために、Cキューが短期的に飢えているのを防ぐために、優先順位は何らかの方法で条件付きでなければなりません（セクション4.2.2を参照）。通常の応答性のLトラフィックにより、結合されたECNマーキングにより、Cトラフィックは、Lトラフィックをマークしてスペースを生成することにより、さらに厳格な優先度を押し戻すことができます。ただし、Cパケットのわずかな有限セット（DNSリクエストやデータの初期ウィンドウなど）がある場合、一部の古典的なAQMは、Cの小さなセットがどれだけ長くても、Lキューに十分なECNマークを誘導しません。パケットが待機します。その後、Lキューがたまたま忙しい場合、Cトラフィックは厳格な優先度スケジューラからスケジューリングの機会を得ることはありません。理想的には、Classic AQMは、Cパケットが待っている長いほど結合されたマークを増やすように設計されていますが、これは常に実用的ではありません。したがって、Lの優先順位が条件付きであることが必要です。Cトラフィックにわずかな重量または限られた待機時間を与えると、DNSリクエストなどの短いクラシックメッセージの応答時間が改善され、即時容量が利用できるため、クラシックフローの起動が改善されます。
Example DualQ Coupled AQM algorithms called 'DualPI2' and 'Curvy RED' are given in Appendices A and B. Either example AQM can be used to couple packet marking and dropping across a DualQ:
例「Dualpi2」と「曲線赤」と呼ばれるDualQ結合AQMアルゴリズムは、付録AおよびBに記載されています。どちらの例でも、AQMの例を使用して、パケットのマークとDualQをドロップするために使用できます。
* DualPI2 uses a Proportional Integral (PI) controller as the Base AQM. Indeed, this Base AQM with just the squared output and no L4S queue can be used as a drop-in replacement for PIE [RFC8033], in which case it is just called PI2 [PI2]. PI2 is a principled simplification of PIE that is both more responsive and more stable in the face of dynamically varying load.
* Dualpi2は、ベースAQMとして比例積分（PI）コントローラーを使用します。実際、四角出力とL4Sキューのみを備えたこのベースAQMは、PIE [RFC8033]のドロップイン置換として使用できます。この場合、PI2 [PI2]と呼ばれます。PI2は、動的に変化する負荷に直面して、より応答性が高く、より安定したパイの原則的な単純化です。
* Curvy RED is derived from RED [RED], except its configuration parameters are delay-based to make them insensitive to link rate, and it requires fewer operations per packet than RED. However, DualPI2 is more responsive and stable over a wider range of RTTs than Curvy RED. As a consequence, at the time of writing, DualPI2 has attracted more development and evaluation attention than Curvy RED, leaving the Curvy RED design not so fully evaluated.
* 曲線赤は赤[赤]に由来します。ただし、その構成パラメーターは遅延ベースであり、リンクレートに対して非感受性を高め、パケットあたりの操作が赤よりも少なくなります。ただし、dualpi2は、曲線の赤よりも幅広いRTTよりも応答性が高く安定しています。結果として、執筆時点で、Dualpi2は曲線レッドよりも多くの開発と評価の注目を集めており、曲線の赤いデザインはそれほど完全に評価されていません。
Both AQMs regulate their queue against targets configured in units of time rather than bytes. As already explained, this ensures configuration can be invariant for different drain rates. With AQMs in a DualQ structure this is particularly important because the drain rate of each queue can vary rapidly as flows for the two queues arrive and depart, even if the combined link rate is constant.
どちらのAQMSも、バイトではなく時間単位で構成されたターゲットに対してキューを調節します。すでに説明されているように、これにより、さまざまな排水速度に対して構成が不変になることが保証されます。DualQ構造のAQMSでは、2つのキューが到着して出発するため、各キューのドレインレートが急速に変化する可能性があるため、これは特に重要です。
It would be possible to control the queues with other alternative AQMs, as long as the normative requirements (those expressed in capitals) in Section 2.5 are observed.
セクション2.5の規範的要件（首都で表現されたもの）が観察される限り、他の代替AQMでキューを制御することが可能です。
The two queues could optionally be part of a larger queuing hierarchy, such as the initial example ideas in [L4S-DIFFSERV].
2つのキューは、[L4S-Diffserv]の最初の例のアイデアなど、オプションでより大きなキューイング階層の一部になる可能性があります。
The following requirements are intended to capture only the essential aspects of a DualQ Coupled AQM. They are intended to be independent of the particular AQMs implemented for each queue but to still define the DualQ framework built around those AQMs.
以下の要件は、DualQ結合されたAQMの重要な側面のみをキャプチャすることを目的としています。それらは、各キューに実装された特定のAQMSとは独立していることを意図していますが、それらのAQMを中心に構築されたDualQフレームワークを定義することを目的としています。
A DualQ Coupled AQM implementation MUST comply with the prerequisite L4S behaviours for any L4S network node (not just a DualQ) as specified in Section 5 of [RFC9331]. These primarily concern classification and re-marking as briefly summarized earlier in Section 2.3. But Section 5.5 of [RFC9331] also gives guidance on reducing the burstiness of the link technology underlying any L4S AQM.
DUALQ結合されたAQM実装は、[RFC9331]のセクション5で指定されているように、L4Sネットワークノード（DualQだけでなく）の前提条件L4S動作に準拠する必要があります。これらは、セクション2.3で前述したように、主に分類と再マークに関係しています。しかし、[RFC9331]のセクション5.5は、L4S AQMの根底にあるリンクテクノロジーの破裂を減らすことに関するガイダンスも示しています。
A DualQ Coupled AQM implementation MUST utilize two queues, each with an AQM algorithm.
DUALQ結合されたAQM実装は、それぞれがAQMアルゴリズムを備えた2つのキューを利用する必要があります。
The AQM algorithm for the low-latency (L) queue MUST be able to apply ECN marking to ECN-capable packets.
低遅延（L）キューのAQMアルゴリズムは、ECN対応パケットにECNマーキングを適用できる必要があります。
The scheduler draining the two queues MUST give L4S packets priority over Classic, although priority MUST be bounded in order not to starve Classic traffic (see Section 4.2.2). The scheduler SHOULD be work-conserving, or otherwise close to work-conserving. This is because Classic traffic needs to be able to efficiently fill any space left by L4S traffic even though the scheduler would otherwise allocate it to L4S.
2つのキューを排出するスケジューラは、クラシックよりもL4Sパケットを優先している必要がありますが、クラシックトラフィックを飢えさせないために優先度を制限する必要があります（セクション4.2.2を参照）。スケジューラは、作業済みであるか、またはその他の方法で作業済みに近い必要があります。これは、スケジューラがL4Sに割り当てる場合でも、L4Sトラフィックが残したスペースを効率的に埋めることができる必要があるためです。
[RFC9331] defines the meaning of an ECN marking on L4S traffic, relative to drop of Classic traffic. In order to ensure coexistence of Classic and Scalable L4S traffic, it says, "the likelihood that the AQM drops a Not-ECT Classic packet (p_C) MUST be roughly proportional to the square of the likelihood that it would have marked it if it had been an L4S packet (p_L)." The term 'likelihood' is used to allow for marking and dropping to be either probabilistic or deterministic.
[RFC9331]は、古典的なトラフィックのドロップと比較して、L4SトラフィックのECNマーキングの意味を定義します。クラシックでスケーラブルなL4Sトラフィックの共存を確保するために、「AQMが非extクラシックパケット（P_C）をドロップする可能性は、それがそれがあった場合、それがそれをマークした可能性のある平方にほぼ比例しなければならないに違いありません。L4Sパケット（P_L）です。」「尤度」という用語は、マークとドロップを確率的または決定論的にするために使用されます。
For the current specification, this translates into the following requirement. A DualQ Coupled AQM MUST apply ECN marking to traffic in the L queue that is no lower than that derived from the likelihood of drop (or ECN marking) in the Classic queue using equation (1).
現在の仕様では、これは次の要件に変換されます。dualq結合されたAQMは、方程式（1）を使用して古典的なキューのドロップ（またはECNマーキング）の可能性から導き出されたものよりも低いLキューのトラフィックにECNマーキングを適用する必要があります。
The constant of proportionality, k, in equation (1) determines the relative flow rates of Classic and L4S flows when the AQM concerned is the bottleneck (all other factors being equal). The L4S ECN protocol [RFC9331] says, "The constant of proportionality (k) does not have to be standardised for interoperability, but a value of 2 is RECOMMENDED."
式（1）の比例定数kは、関連するAQMがボトルネック（他のすべての要因が等しい）である場合、クラシックとL4Sの相対流量を決定します。L4S ECNプロトコル[RFC9331]には、「比例定数（k）は相互運用性のために標準化する必要はありませんが、2の値が推奨されます」と述べています。
Assuming Scalable congestion controls for the Internet will be as aggressive as DCTCP, this will ensure their congestion window will be roughly the same as that of a Standards Track TCP Reno congestion control (Reno) [RFC5681] and other Reno-friendly controls, such as TCP CUBIC in its Reno-friendly mode.
インターネットのスケーラブルな輻輳制御がDCTCPと同じくらい攻撃的であると仮定すると、これにより、彼らの混雑ウィンドウがTCP RENO輻輳制御（RENO）[RFC5681]やその他のリノに優しいコントロールの標準トラックのそれとほぼ同じになります。TCP Cubic Renoフレンドリーモード。
The choice of k is a matter of operator policy, and operators MAY choose a different value using the guidelines in Appendix C.2.
Kの選択はオペレーターポリシーの問題であり、オペレーターは付録C.2のガイドラインを使用して異なる値を選択できます。
If multiple customers or users share capacity at a bottleneck (e.g., in the Internet access link of a campus network), the operator's choice of k will determine capacity sharing between the flows of different customers. However, on the public Internet, access network operators typically isolate customers from each other with some form of Layer 2 multiplexing (OFDM(A) in DOCSIS 3.1, CDMA in 3G, and SC-FDMA in LTE) or Layer 3 scheduling (Weighted Round Robin (WRR) for DSL) rather than relying on host congestion controls to share capacity between customers [RFC0970]. In such cases, the choice of k will solely affect relative flow rates within each customer's access capacity, not between customers. Also, k will not affect relative flow rates at any times when all flows are Classic or all flows are L4S, and it will not affect the relative throughput of small flows.
複数の顧客またはユーザーがボトルネックで容量を共有している場合（たとえば、キャンパスネットワークのインターネットアクセスリンク）、オペレーターがKを選択すると、さまざまな顧客のフロー間の容量共有が決定されます。ただし、パブリックインターネットでは、アクセスネットワークオペレーターが通常、顧客を互いに隔離します。レイヤー2マルチプレックス（DOCSIS 3.1のOFDM（A）、3GのCDMA、LTEのSC-FDMA）またはレイヤー3スケジューリング（重み付けラウンド）ホストの混雑コントロールに頼って顧客間で容量を共有するのではなく、ロビン（DSLのWRR）[RFC0970]。そのような場合、Kの選択は、顧客間ではなく、各顧客のアクセス容量内の相対的な流量のみに影響します。また、Kはすべてのフローがクラシックであるか、すべてのフローがL4である場合、相対的な流量に影響を与えません。また、小さなフローの相対的なスループットには影響しません。
The flexibility to allow operator-specific classifiers (Section 2.3) leads to the need to specify what the AQM in each queue ought to do with packets that do not carry the ECN field expected for that queue. It is expected that the AQM in each queue will inspect the ECN field to determine what sort of congestion notification to signal, then it will decide whether to apply congestion notification to this particular packet, as follows:
オペレーター固有の分類器（セクション2.3）を許可する柔軟性は、各キューのAQMがそのキューに予想されるECNフィールドを運ばないパケットで何をすべきかを指定する必要性につながります。各キューのAQMは、ECNフィールドを検査して、どのような輻輳通知を信号するかを判断することが予想されます。次のように、この特定のパケットに混雑通知を適用するかどうかを決定します。
* If a packet that does not carry an ECT(1) or a CE codepoint is classified into the L queue, then:
* ECT（1）またはCEコードポイントを運ばないパケットがLキューに分類される場合、次のとおりです。
- if the packet is ECT(0), the L AQM SHOULD apply CE marking using a probability appropriate to Classic congestion control and appropriate to the target delay in the L queue
- パケットがECT（0）の場合、L AQMは、古典的な混雑制御に適した確率を使用してCEマーキングを適用し、Lキューのターゲット遅延に適しています
- if the packet is Not-ECT, the appropriate action depends on whether some other function is protecting the L queue from misbehaving flows (e.g., per-flow queue protection [DOCSIS-Q-PROT] or latency policing):
- パケットがそれでない場合、適切なアクションは、他の関数がlキューを誤動作フロー（たとえば、フローごとのキュー保護[docsis-q-prot]またはレイテンシポリシング）から保護しているかどうかに依存します。
o if separate queue protection is provided, the L AQM SHOULD ignore the packet and forward it unchanged, meaning it should not calculate whether to apply congestion notification, and it should neither drop nor CE mark the packet (for instance, the operator might classify EF traffic that is unresponsive to drop into the L queue, alongside responsive L4S-ECN traffic)
o 個別のキュー保護が提供されている場合、L AQMはパケットを無視して変更せずに転送する必要があります。つまり、混雑通知を適用するかどうかを計算してはなりません。それは、レスポンシブL4S-ECNトラフィックとともに、Lキューにドロップすることは反応しません）
o if separate queue protection is not provided, the L AQM SHOULD apply drop using a drop probability appropriate to Classic congestion control and to the target delay in the L queue
o 個別のキュー保護が提供されていない場合、L AQMは、古典的なうっ血制御とLキューのターゲット遅延に適したドロップ確率を使用してドロップを適用する必要があります
* If a packet that carries an ECT(1) codepoint is classified into the C queue:
* ECT（1）CodePointを搭載したパケットがCキューに分類されている場合：
- the C AQM SHOULD apply CE marking using the Coupled AQM probability p_CL (= k*p').
- C AQMは、結合されたAQM確率P_CL（= k*P '）を使用してCEマーキングを適用する必要があります。
The above requirements are worded as "SHOULD"s, because operator-specific classifiers are for flexibility, by definition. Therefore, alternative actions might be appropriate in the operator's specific circumstances. An example would be where the operator knows that certain legacy traffic set to one codepoint actually has a congestion response associated with another codepoint.
上記の要件は、「Suff」と表現されています。これは、オペレーター固有の分類器は定義上、柔軟性のためであるためです。したがって、オペレーターの特定の状況では、代替アクションが適切かもしれません。例としては、オペレーターが特定のレガシートラフィックが1つのCodePointに設定されていることが、実際に別のCodePointに関連付けられた渋滞応答があることを知っている場合です。
If the DualQ Coupled AQM has detected overload, it MUST introduce Classic drop to both types of ECN-capable traffic until the overload episode has subsided. Introducing drop if ECN marking is persistently high is recommended in Section 7 of the ECN spec [RFC3168] and in Section 4.2.1 of the AQM Recommendations [RFC7567].
DualQ結合されたAQMが過負荷を検出した場合、過負荷エピソードが沈静化するまで、両方のタイプのECN対応トラフィックに古典的なドロップを導入する必要があります。ECN仕様[RFC3168]のセクション7およびAQM推奨[RFC7567]のセクション4.2.1では、ECNマーキングが持続的に高い場合のドロップの導入が推奨されます。
By default, a DualQ Coupled AQM SHOULD NOT need any configuration for use at a bottleneck on the public Internet [RFC7567]. The following parameters MAY be operator-configurable, e.g., to tune for non-Internet settings:
デフォルトでは、DualQ結合されたAQMは、パブリックインターネットのボトルネックで使用するための構成を必要としません[RFC7567]。以下のパラメーターは、インターネット以外の設定を調整するために、オペレーター構成可能な場合があります。
* Optional packet classifier(s) to use in addition to the ECN field (see Section 2.3).
* ECNフィールドに加えて使用するオプションのパケット分類器（セクション2.3を参照）。
* Expected typical RTT, which can be used to determine the queuing delay of the Classic AQM at its operating point, in order to prevent typical lone flows from underutilizing capacity. For example:
* 典型的な唯一の流れが十分に活用されないようにするために、操作点で古典的なAQMのキューイング遅延を決定するために使用できる典型的なRTTが期待されています。例えば：
- for the PI2 algorithm (Appendix A), the queuing delay target is dependent on the typical RTT.
- PI2アルゴリズム（付録A）の場合、キューイング遅延ターゲットは典型的なRTTに依存します。
- for the Curvy RED algorithm (Appendix B), the queuing delay at the desired operating point of the curvy ramp is configured to encompass a typical RTT.
- 曲線の赤いアルゴリズム（付録B）の場合、曲線ランプの目的の動作点でのキューイング遅延は、典型的なRTTを含むように構成されています。
- if another Classic AQM was used, it would be likely to need an operating point for the queue based on the typical RTT, and if so, it SHOULD be expressed in units of time.
- 別の古典的なAQMが使用された場合、典型的なRTTに基づいてキューの動作点が必要になる可能性があり、もしそうなら、それは時間単位で表現する必要があります。
An operating point that is manually calculated might be directly configurable instead, e.g., for links with large numbers of flows where underutilization by a single flow would be unlikely.
手動で計算される動作点は、単一のフローによる活用不足がありそうにない多数のフローとのリンクの場合、代わりに直接構成可能である可能性があります。
* Expected maximum RTT, which can be used to set the stability parameter(s) of the Classic AQM. For example:
* 予想される最大RTTは、クラシックAQMの安定性パラメーターを設定するために使用できます。例えば：
- for the PI2 algorithm (Appendix A), the gain parameters of the PI algorithm depend on the maximum RTT.
- PI2アルゴリズム（付録A）の場合、PIアルゴリズムのゲインパラメーターは最大RTTに依存します。
- for the Curvy RED algorithm (Appendix B), the smoothing parameter is chosen to filter out transients in the queue within a maximum RTT.
- 曲線の赤いアルゴリズム（付録B）の場合、最大RTT内のキュー内のトランジェントを除外するために平滑化パラメーターが選択されます。
Any stability parameter that is manually calculated assuming a maximum RTT might be directly configurable instead.
最大RTTが代わりに直接構成可能であると仮定して手動で計算される安定性パラメーター。
* Coupling factor, k (see Appendix C.2).
* 結合係数、K（付録C.2を参照）。
* A limit to the conditional priority of L4S. This is scheduler-dependent, but it SHOULD be expressed as a relation between the max delay of a C packet and an L packet. For example:
* L4Sの条件付き優先度の制限。これはスケジューラ依存ですが、Cパケットの最大遅延とLパケットの関係として表現する必要があります。例えば：
- for a WRR scheduler, a weight ratio between L and C of w:1 means that the maximum delay of a C packet is w times that of an L packet.
- WRRスケジューラの場合、W：1のLとCの重量比は、Cパケットの最大遅延がLパケットの最大遅延であることを意味します。
- for a time-shifted FIFO (TS-FIFO) scheduler (see Section 4.2.2), a time-shift of tshift means that the maximum delay to a C packet is tshift greater than that of an L packet. tshift could be expressed as a multiple of the typical RTT rather than as an absolute delay.
- タイムシフトFIFO（TS-FIFO）スケジューラ（セクション4.2.2を参照）の場合、TSHIFTのタイムシフトは、Cパケットの最大遅延がLパケットのそれよりも大きいことを意味します。tshiftは、絶対的な遅延としてではなく、典型的なRTTの倍数として表現できます。
* The maximum Classic ECN-marking probability, p_Cmax, before introducing drop.
* ドロップを導入する前に、最大の古典的なECNマーク確率、P_CMAX。
An experimental DualQ Coupled AQM SHOULD allow the operator to monitor each of the following operational statistics on demand, per queue and per configurable sample interval, for performance monitoring and perhaps also for accounting in some cases:
実験的なDUALQ結合AQMを使用すると、オペレーターは、パフォーマンスモニタリング、場合によっては、場合によっては会計のために、キューごと、および構成可能なサンプル間隔ごとに、次の各運用統計をオンデマンドで監視できるようにする必要があります。
* bits forwarded, from which utilization can be calculated;
* 転送されたビット、そこから使用率を計算できます。
* total packets in the three categories: arrived, presented to the AQM, and forwarded. The difference between the first two will measure any non-AQM tail discard. The difference between the last two will measure proactive AQM discard;
* 3つのカテゴリの合計パケット：到着し、AQMに提示され、転送されます。最初の2つの違いは、aqm以外のテール廃棄物を測定します。最後の2つの違いは、プロアクティブなAQM廃棄を測定します。
* ECN packets marked, non-ECN packets dropped, and ECN packets dropped, which can be combined with the three total packet counts above to calculate marking and dropping probabilities; and
* マークされたECNパケット、非ECNパケットがドロップされ、ECNパケットがドロップされました。これは、上記の3つの合計パケットカウントと組み合わせて、マーキングとドロップの確率を計算できます。と
* queue delay (not including serialization delay of the head packet or medium acquisition delay) -- see further notes below.
* キュー遅延（ヘッドパケットのシリアル化遅延または中程度の取得遅延は含まれません） - 以下の詳細メモを参照してください。
Unlike the other statistics, queue delay cannot be captured in a simple accumulating counter. Therefore, the type of queue delay statistics produced (mean, percentiles, etc.) will depend on implementation constraints. To facilitate comparative evaluation of different implementations and approaches, an implementation SHOULD allow mean and 99th percentile queue delay to be derived (per queue per sample interval). A relatively simple way to do this would be to store a coarse-grained histogram of queue delay. This could be done with a small number of bins with configurable edges that represent contiguous ranges of queue delay. Then, over a sample interval, each bin would accumulate a count of the number of packets that had fallen within each range. The maximum queue delay per queue per interval MAY also be recorded, to aid diagnosis of faults and anomalous events.
他の統計とは異なり、キューの遅延を単純な蓄積カウンターでキャプチャすることはできません。したがって、生成されたキュー遅延統計のタイプ（平均、パーセンタイルなど）は、実装の制約に依存します。さまざまな実装とアプローチの比較評価を容易にするために、実装により、平均と99パーセンタイルのキュー遅延を導き出すことができます（サンプル間隔ごとのキューごと）。これを行うための比較的簡単な方法は、キュー遅延の粗粒のヒストグラムを保存することです。これは、キューの遅延の連続した範囲を表す構成可能なエッジを備えた少数のビンで行うことができます。次に、サンプル間隔で、各ビンは各範囲内に収まるパケットの数のカウントを蓄積します。障害や異常なイベントの診断を支援するために、間隔あたりのキューごとの最大キュー遅延も記録できます。
An experimental DualQ Coupled AQM SHOULD asynchronously report the following data about anomalous conditions:
実験的なDualQ結合AQMは、異常な条件に関する次のデータを非同期的に報告する必要があります。
* Start time and duration of overload state.
* 過負荷状態の開始時間と期間。
A hysteresis mechanism SHOULD be used to prevent flapping in and out of overload causing an event storm. For instance, exiting from overload state could trigger one report but also latch a timer. Then, during that time, if the AQM enters and exits overload state any number of times, the duration in overload state is accumulated, but no new report is generated until the first time the AQM is out of overload once the timer has expired.
ヒステリシスメカニズムを使用して、イベントストームを引き起こす過負荷の羽ばたきを防ぐ必要があります。たとえば、過負荷状態から終了すると、1つのレポートをトリガーできますが、タイマーもラッチする可能性があります。その間、その間、AQMが過負荷状態に入って出力した場合、オーバーロード状態の期間は蓄積されますが、タイマーが失効するとAQMが初めて過負荷が発生するまで新しいレポートは生成されません。
[RFC5706] suggests that deployment, coexistence, and scaling should also be covered as management requirements. The raison d'etre of the DualQ Coupled AQM is to enable deployment and coexistence of Scalable congestion controls (as incremental replacements for today's Reno-friendly controls that do not scale with bandwidth-delay product). Therefore, there is no need to repeat these motivating issues here given they are already explained in the Introduction and detailed in the L4S architecture [RFC9330].
[RFC5706]は、展開、共存、およびスケーリングも管理要件としてカバーする必要があることを示唆しています。dualq結合されたAQMの存在理由は、スケーラブルな輻輳コントロールの展開と共存を可能にすることです（帯域幅デレイ製品でスケーリングしない今日のリノに優しいコントロールの増分置換として）。したがって、これらの動機付けの問題をここで繰り返す必要はありません。それらは紹介ですでに説明されており、L4Sアーキテクチャ[RFC9330]で詳述されています。
The descriptions of specific DualQ Coupled AQM algorithms in the appendices cover scaling of their configuration parameters, e.g., with respect to RTT and sampling frequency.
付録の特定のDualQ結合AQMアルゴリズムの説明は、RTTおよびサンプリング周波数に関して、構成パラメーターのスケーリングをカバーします。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
The L4S architecture [RFC9330] compares the DualQ and FQ approaches to L4S. The privacy considerations section in that document motivates the DualQ on the grounds that users who want to encrypt application flow identifiers, e.g., in IPsec or other encrypted VPN tunnels, don't have to sacrifice low delay ([RFC8404] encourages avoidance of such privacy compromises).
L4Sアーキテクチャ[RFC9330]は、DualQとFQのアプローチをL4Sと比較します。そのドキュメントのプライバシーに関する考慮事項セクションでは、アプリケーションフロー識別子を暗号化したいユーザー、例えばIPSECまたはその他の暗号化されたVPNトンネルで、低遅延を犠牲にする必要はありません（[RFC8404]は、そのようなプライバシーの回避を促進する必要はありません。妥協）。
The security considerations section of the L4S architecture [RFC9330] also includes subsections on policing of relative flow rates (Section 8.1) and on policing of flows that cause excessive queuing delay (Section 8.2). It explains that the interests of users do not collide in the same way for delay as they do for bandwidth. For someone to get more of the bandwidth of a shared link, someone else necessarily gets less (a 'zero-sum game'), whereas queuing delay can be reduced for everyone, without any need for someone else to lose out. It also explains that, on the current Internet, scheduling usually enforces separation of bandwidth between 'sites' (e.g., households, businesses, or mobile users), but it is not common to need to schedule or police the bandwidth used by individual application flows.
L4Sアーキテクチャ[RFC9330]のセキュリティ上の考慮事項セクションには、相対流量のポリシング（セクション8.1）と過度のキューイング遅延（セクション8.2）を引き起こすフローのポリシングに関するサブセクションも含まれています。ユーザーの関心は、帯域幅の場合と同じように遅延のために衝突しないことを説明しています。誰かが共有リンクの帯域幅を増やすためには、他の誰かが必然的に少なくなり（「ゼロサムゲーム」）、他の誰かが負ける必要なく、キューイングの遅延を減らすことができます。また、現在のインターネットでは、スケジューリングは通常、「サイト」（例：世帯、企業、モバイルユーザー）間の帯域幅の分離を強制するが、個々のアプリケーションフローで使用される帯域幅をスケジュールまたは警察する必要があることは一般的ではないことを説明しています。。
By the above arguments, per-flow rate policing might not be necessary, and in trusted environments (e.g., private data centres), it is certainly unlikely to be needed. Therefore, because it is hard to avoid complexity and unintended side effects with per-flow rate policing, it needs to be separable from a basic AQM, as an option, under policy control. On this basis, the DualQ Coupled AQM provides low delay without prejudging the question of per-flow rate policing.
上記の議論では、流量あたりのレートポリシングは必要ない場合があり、信頼できる環境（たとえば、プライベートデータセンター）では、確かに必要とされる可能性は低いです。したがって、流量あたりのレートポリシングで複雑さと意図しない副作用を回避することは困難であるため、ポリシー管理下でオプションとして基本的なAQMから分離可能である必要があります。これに基づいて、DualQ結合されたAQMは、流量あたりのポリシングの問題を不利にすることなく、低遅延を提供します。
Nonetheless, the interests of users or flows might conflict, e.g., in case of accident or malice. Then per-flow rate control could be necessary. If per-flow rate control is needed, it can be provided as a modular addition to a DualQ. And similarly, if protection against excessive queue delay is needed, a per-flow queue protection option can be added to a DualQ (e.g., [DOCSIS-Q-PROT]).
それにもかかわらず、たとえば、事故や悪意の場合、ユーザーやフローの利益は矛盾する可能性があります。その後、流量あたりのレート制御が必要になる場合があります。流量あたりのレート制御が必要な場合は、デュアルクへのモジュラー追加として提供できます。同様に、過度のキュー遅延に対する保護が必要な場合は、フローごとのキュー保護オプションをDualQに追加できます（[docsis-q-prot]）。
In the absence of any per-flow control, it is important that the basic DualQ Coupled AQM gives unresponsive flows no more throughput advantage than a single-queue AQM would, and that it at least handles overload situations. Overload means that incoming load significantly or persistently exceeds output capacity, but it is not intended to be a precise term -- significant and persistent are matters of degree.
流量ごとの制御がない場合、基本的なDualQ結合されたAQMが無反応のフローを提供することが重要であり、単一のAQMよりもスループットの優位性がなく、少なくとも過負荷の状況を処理することが重要です。過負荷とは、着信負荷が出力容量を大幅にまたは持続的に超えることを意味しますが、それは正確な用語であることを意図したものではありません。
A trade-off needs to be made between complexity and the risk of either traffic class harming the other. In overloaded conditions, the higher priority L4S service will have to sacrifice some aspect of its performance. Depending on the degree of overload, alternative solutions may relax a different factor: for example, throughput, delay, or drop. These choices need to be made either by the developer or by operator policy, rather than by the IETF. Subsequent subsections discuss handling different degrees of overload:
複雑さと、他のトラフィッククラスが害を及ぼすリスクとの間にトレードオフを行う必要があります。過負荷状態では、優先度の高いL4Sサービスは、そのパフォーマンスの一部を犠牲にする必要があります。過負荷の程度に応じて、代替ソリューションは異なる要因を緩和する場合があります。たとえば、スループット、遅延、またはドロップなどです。これらの選択は、IETFではなく、開発者またはオペレーターポリシーによって行う必要があります。その後のサブセクションは、さまざまな程度の過負荷の処理について議論します。
* Unresponsive flows (L and/or C) but not overloaded, i.e., the sum of unresponsive load before adding any responsive traffic is below capacity.
* 反応しないフロー（Lおよび/またはC）は過負荷ではありません。つまり、応答性のあるトラフィックを追加する前の反応しない負荷の合計は容量を下回ります。
This case is handled by the regular Coupled DualQ (Section 2.1) but not discussed there. So below, Section 4.2.1 explains the design goal and how it is achieved in practice.
このケースは、通常の結合DUALQ（セクション2.1）によって処理されますが、そこでは議論されていません。以下では、セクション4.2.1では、設計目標と実際にどのように達成されるかについて説明します。
* Unresponsive flows (L and/or C) causing persistent overload, i.e., the sum of unresponsive load even before adding any responsive traffic persistently exceeds capacity.
* 無反応の流れ（Lおよび/またはc）は、持続的な過負荷、つまり、応答性のあるトラフィックを追加する前であっても、無反応の負荷の合計を持続的に容量を超えることを引き起こします。
This case is not covered by the regular Coupled DualQ mechanism (Section 2.1), but the last paragraph in Section 2.5.1.1 sets out a requirement to handle the case where ECN-capable traffic could starve non-ECN-capable traffic. Section 4.2.3 below discusses the general options and gives specific examples.
このケースは、通常の結合DualQメカニズム（セクション2.1）でカバーされていませんが、セクション2.5.1.1の最後の段落では、ECN対応のトラフィックがECN対応のトラフィックを飢えている場合を処理するための要件を示しています。以下のセクション4.2.3では、一般的なオプションについて説明し、特定の例を示します。
* Short-term overload that lies between the 'not overloaded' and 'persistently overloaded' cases.
* 「過負荷ではない」と「持続的に過負荷」ケースの間にある短期過負荷。
For the period before overload is deemed persistent, Section 4.2.2 discusses options for more immediate mechanisms at the scheduler timescale. These prevent short-term starvation of the C queue by making the priority of the L queue conditional, as required in Section 2.5.1.
過負荷が持続的であると見なされる期間については、セクション4.2.2では、スケジューラタイムスケールでのより即時のメカニズムのオプションについて説明します。これらは、セクション2.5.1で要求されるように、Lキューの優先度を条件とすることにより、Cキューの短期飢starを防ぎます。
When one or more L flows and/or C flows are unresponsive, but their total load is within the link capacity so that they do not saturate the coupled marking (below 100%), the goal of a DualQ AQM is to behave no worse than a single-queue AQM.
1つ以上のLフローおよび/またはCフローが反応しないが、それらの総負荷がリンク容量内にあるため、結合マーキングを飽和させない（100％未満）、DualQ AQMの目標はより悪い振る舞いをすることではありませんシングルキューAQM。
Tests have shown that this is indeed the case with no additional mechanism beyond the regular Coupled DualQ of Section 2.1 (see the results of 'overload experiments' in [L4Seval22]). Perhaps counterintuitively, whether the unresponsive flow classifies itself into the L or the C queue, the DualQ system behaves as if it has subtracted from the overall link capacity. Then, the coupling shares out the remaining capacity between any competing responsive flows (in either queue). See also Section 4.2.2, which discusses scheduler-specific details.
テストでは、これは実際に、セクション2.1の通常の結合Dualqを超えて追加のメカニズムがないことが示されています（[L4Seval22]の「過負荷実験」の結果を参照）。おそらく直感に反して、反応しないフローがLまたはCキューに分類されるかどうかにかかわらず、DualQシステムは、全体的なリンク容量から差し引かれたかのように動作します。次に、カップリングは、競合するレスポンシブフローの間の残りの容量を（どちらのキューでも）共有します。スケジューラ固有の詳細について説明するセクション4.2.2も参照してください。
Priority of L4S is required to be conditional (see Sections 2.4 and 2.5.1) to avoid short-term starvation of Classic. Otherwise, as explained in Section 2.4, even a lone responsive L4S flow could temporarily block a small finite set of C packets (e.g., an initial window or DNS request). The blockage would only be brief, but it could be longer for certain AQM implementations that can only increase the congestion signal coupled from the C queue when C packets are actually being dequeued. There is then the question of whether to sacrifice L4S throughput or L4S delay (or some other policy) to make the priority conditional:
L4Sの優先度は、クラシックの短期的な飢starを避けるために、条件付きである必要があります（セクション2.4および2.5.1を参照）。それ以外の場合、セクション2.4で説明したように、唯一の応答性のあるL4Sフローでさえ、Cパケットの小さな有限セット（初期ウィンドウまたはDNSリクエストなど）を一時的にブロックする可能性があります。閉塞は短いですが、Cパケットが実際にデケートされている場合、Cキューから結合された輻輳信号を増加させることができる特定のAQM実装では長くなる可能性があります。次に、優先度を条件とするためにL4SスループットまたはL4Sの遅延（または他のポリシー）を犠牲にするかどうかという問題があります。
Sacrifice L4S throughput: By using WRR as the conditional priority scheduler, the L4S service can sacrifice some throughput during overload. This can be thought of as guaranteeing either a minimum throughput service for Classic traffic or a maximum delay for a packet at the head of the Classic queue.
L4Sスループットを犠牲にする：条件優先スケジューラとしてWRRを使用することにより、L4Sサービスは過負荷中にスループットを犠牲にすることができます。これは、古典的なトラフィックの最小スループットサービスまたはクラシックキューの頭のパケットの最大遅延のいずれかを保証すると考えることができます。
| Cautionary note: a WRR scheduler can only guarantee Classic
| throughput if Classic sources are sending enough to use it
| -- congestion signals can undermine scheduling because they
| determine how much responsive traffic of each class arrives
| for scheduling in the first place. This is why scheduling
| is only relied on to handle short-term starvation, until
| congestion signals build up and the sources react. Even
| during long-term overload (discussed more fully in
| Section 4.2.3), it's pragmatic to discard packets from both
| queues, which again thins the traffic before it reaches the
| scheduler. This is because a scheduler cannot be relied on
| to handle long-term overload since the right scheduler
| weight cannot be known for every scenario.
The scheduling weight of the Classic queue should be small (e.g., 1/16). In most traffic scenarios, the scheduler will not interfere and it will not need to, because the coupling mechanism and the end systems will determine the share of capacity across both queues as if it were a single pool. However, if L4S traffic is over-aggressive or unresponsive, the scheduler weight for Classic traffic will at least be large enough to ensure it does not starve in the short term.
クラシックキューのスケジューリング重量は小さくする必要があります（例：1/16）。ほとんどのトラフィックシナリオでは、カップリングメカニズムと最終システムが両方のキュー全体で単一のプールであるかのように容量のシェアを決定するため、スケジューラは干渉しず、必要ありません。ただし、L4Sトラフィックが過度に攻撃的または反応しない場合、古典的なトラフィックのスケジューラ重量は、少なくとも短期的には飢えないようにするのに十分な大きさになります。
Although WRR scheduling is only expected to address short-term overload, there are (somewhat rare) cases when WRR has an effect on capacity shares over longer timescales. But its effect is minor, and it certainly does no harm. Specifically, in cases where the ratio of L4S to Classic flows (e.g., 19:1) is greater than the ratio of their scheduler weights (e.g., 15:1), the L4S flows will get less than an equal share of the capacity, but only slightly. For instance, with the example numbers given, each L4S flow will get (15/16)/19 = 4.9% when ideally each would get 1/20 = 5%. In the rather specific case of an unresponsive flow taking up just less than the capacity set aside for L4S (e.g., 14/16 in the above example), using WRR could significantly reduce the capacity left for any responsive L4S flows.
WRRスケジューリングは短期的な過負荷にのみ対処することが期待されていますが、WRRがより長いタイムスケールよりも容量シェアに影響を与える場合（ややまれな）ケースがあります。しかし、その効果は軽微であり、確かに害はありません。具体的には、L4と古典的なフロー（例：19：1）の比率がスケジューラの重み（例えば15：1）の比率よりも大きい場合、L4Sフローは容量の等しいシェア未満を獲得します。しかし、ほんの少しだけです。たとえば、例を示す例では、各L4Sフローは（15/16）/19 = 4.9％になり、それぞれが1/20 = 5％になります。L4Sの容量が取られている容量よりも少ない反応のないフローのかなり特定のケース（上記の例では14/16など）では、WRRを使用すると、応答性の高いL4Sフローに残っている容量が大幅に減少する可能性があります。
The scheduling weight of the Classic queue should not be too small, otherwise a C packet at the head of the queue could be excessively delayed by a continually busy L queue. For instance, if the Classic weight is 1/16, the maximum that a Classic packet at the head of the queue can be delayed by L traffic is the serialization delay of 15 MTU-sized packets.
クラシックキューのスケジューリング重量は小さすぎてはなりません。そうしないと、キューの頭のCパケットは、継続的に忙しいLキューによって過度に遅れる可能性があります。たとえば、古典的な重量が1/16の場合、キューの頭のクラシックパケットがLトラフィックによって遅れる可能性がある場合、15 MTUサイズのパケットのシリアル化遅延です。
Sacrifice L4S delay: The operator could choose to control overload of the Classic queue by allowing some delay to 'leak' across to the L4S queue. The scheduler can be made to behave like a single FIFO queue with different service times by implementing a very simple conditional priority scheduler that could be called a "time-shifted FIFO" (TS-FIFO) (see the Modifier Earliest Deadline First (MEDF) scheduler [MEDF]). This scheduler adds tshift to the queue delay of the next L4S packet, before comparing it with the queue delay of the next Classic packet, then it selects the packet with the greater adjusted queue delay.
L4Sの遅延を犠牲にする：オペレーターは、L4Sキューにある程度の遅延を「リーク」することにより、古典的なキューの過負荷を制御することを選択できます。スケジューラは、「タイムシフトFIFO」（TS-FIFO）と呼ばれる非常にシンプルな条件付き優先スケジューラを実装することにより、異なるサービス時間を持つ単一のFIFOキューのように動作するようにすることができます（修飾子初期（MEDF）を参照スケジューラ[MEDF]）。このスケジューラは、次のL4Sパケットのキュー遅延にtshiftを追加し、次のクラシックパケットのキュー遅延と比較する前に、より大きな調整されたキュー遅延でパケットを選択します。
Under regular conditions, the TS-FIFO scheduler behaves just like a strict priority scheduler. But under moderate or high overload, it prevents starvation of the Classic queue, because the time-shift (tshift) defines the maximum extra queuing delay of Classic packets relative to L4S. This would control milder overload of responsive traffic by introducing delay to defer invoking the overload mechanisms in Section 4.2.3, particularly when close to the maximum congestion signal.
通常の条件下では、TS-FIFOスケジューラは厳密な優先度スケジューラのように動作します。しかし、中程度または高い過負荷では、Time-Shift（TShift）がL4と比較してクラシックパケットの最大余分なキューイング遅延を定義するため、古典的なキューの飢vを防ぎます。これにより、特に最大輻輳信号に近い場合、セクション4.2.3の過負荷メカニズムを呼び出す遅延を延期することにより、応答性のあるトラフィックの穏やかな過負荷を制御します。
The example implementations in Appendices A and B could both be implemented with either policy.
付録AとBの実装の例は、どちらもどちらのポリシーでも実装できます。
This section concerns persistent overload caused by unresponsive L and/or C flows. To keep the throughput of both L4S and Classic flows roughly equal over the full load range, a different control strategy needs to be defined above the point where the L4S AQM persistently saturates to an ECN marking probability of 100%, leaving no room to push back the load any harder. L4S ECN marking will saturate first (assuming the coupling factor k>1), even though saturation could be caused by the sum of unresponsive traffic in either or both queues exceeding the link capacity.
このセクションでは、反応のないLおよび/またはCフローによって引き起こされる持続的な過負荷に関するものです。L4Sとクラシックフローの両方のスループットを全負荷範囲でほぼ等しく保つには、L4S AQMが100％のECNマーキング確率に持続的に飽和し、押し戻す余地を残すポイントよりも異なる制御戦略を定義する必要があります。荷重をより強くします。L4S ECNマーキングは、リンク容量を超えるいずれかまたは両方のキューにおける反応しないトラフィックの合計によって飽和が引き起こされる可能性がありますが、L4S ECNマーキングは最初に飽和します（カップリング係数K> 1を仮定します）。
The term 'unresponsive' includes cases where a flow becomes temporarily unresponsive, for instance, a real-time flow that takes a while to adapt its rate in response to congestion, or a standard Reno flow that is normally responsive, but above a certain congestion level it will not be able to reduce its congestion window below the allowed minimum of 2 segments [RFC5681], effectively becoming unresponsive. (Note that L4S traffic ought to remain responsive below a window of 2 segments. See the L4S requirements [RFC9331].)
「無反応」という用語には、フローが一時的に反応しなくなる場合、たとえば、混雑に応じてレートを適応させるのに時間がかかるリアルタイムのフロー、または通常は応答しますが、特定の渋滞を超える標準的なリノフローが含まれます。レベルは、許可された最低2つのセグメント[RFC5681]を下回る混雑ウィンドウを減らすことができず、効果的に反応しなくなります。（L4Sトラフィックは、2つのセグメントのウィンドウの下で応答性を維持する必要があることに注意してください。L4S要件[RFC9331]を参照してください。）
Saturation raises the question of whether to relieve congestion by introducing some drop into the L4S queue or by allowing delay to grow in both queues (which could eventually lead to drop due to buffer exhaustion anyway):
飽和は、L4Sキューに多少のドロップを導入するか、両方のキューで遅延が成長することにより、混雑を緩和するかどうかの問題を提起します（とにかく緩衝液のために最終的に緩衝液のために低下する可能性があります）：
Drop on Saturation: Persistent saturation can be defined by a maximum threshold for coupled L4S ECN marking (assuming k>1) before saturation starts to make the flow rates of the different traffic types diverge. Above that, the drop probability of Classic traffic is applied to all packets of all traffic types. Then experiments have shown that queuing delay can be kept at the target in any overload situation, including with unresponsive traffic, and no further measures are required (Section 4.2.3.1).
飽和時にドロップ：飽和が異なるトラフィックタイプの流量が分岐する前に、結合されたL4S ECNマーキング（K> 1を仮定）の最大しきい値（K> 1を仮定）で永続的な飽和度を定義できます。それ以上に、クラシックトラフィックのドロップ確率は、すべてのトラフィックタイプのすべてのパケットに適用されます。次に、実験により、駆動遅延は、反応のないトラフィックを含む、あらゆる過負荷状況でターゲットに維持できることが示されており、それ以上の措置は必要ありません（セクション4.2.3.1）。
Delay on Saturation: When L4S marking saturates, instead of introducing L4S drop, the drop and marking probabilities of both queues could be capped. Beyond that, delay will grow either solely in the queue with unresponsive traffic (if WRR is used) or in both queues (if TS-FIFO is used). In either case, the higher delay ought to control temporary high congestion. If the overload is more persistent, eventually the combined DualQ will overflow and tail drop will control congestion.
飽和度の遅延：L4Sのマークが飽和すると、L4Sドロップを導入する代わりに、両方のキューのドロップとマークの確率がキャップされる可能性があります。それを超えて、遅延は無反応のトラフィック（WRRが使用されている場合）のキューのみで、または両方のキュー（TS-FIFOが使用されている場合）のいずれかで成長します。どちらの場合でも、より高い遅延は一時的な高い輻輳を制御する必要があります。過負荷がより永続的である場合、最終的に複合デュアルクがオーバーフローし、テールドロップがうっ血を制御します。
The example implementation in Appendix A solely applies the "drop on saturation" policy. The DOCSIS specification of a DualQ Coupled AQM [DOCSIS3.1] also implements the 'drop on saturation' policy with a very shallow L buffer. However, the addition of DOCSIS per-flow Queue Protection [DOCSIS-Q-PROT] turns this into 'delay on saturation' by redirecting some packets of the flow or flows that are most responsible for L queue overload into the C queue, which has a higher delay target. If overload continues, this again becomes 'drop on saturation' as the level of drop in the C queue rises to maintain the target delay of the C queue.
付録Aの実装の例は、「飽和」ポリシーのみを適用します。DUALQ結合AQM [DOCSIS3.1]のDOCSIS仕様は、非常に浅いLバッファーを使用して「飽和のドロップ」ポリシーを実装しています。ただし、docsis per-flowキュー保護[docsis-q-prot]を追加すると、フローのパケットをリダイレクトすることにより、これを「飽和時の遅延」に変えます。より高い遅延ターゲット。過負荷が続くと、Cキューのターゲット遅延を維持するためにCキューの低下のレベルが上昇すると、これが再び「飽和」になります。
Without a specific overload mechanism, unresponsive traffic would have a greater advantage if it were also ECN-capable. The advantage is undetectable at normal low levels of marking. However, it would become significant with the higher levels of marking typical during overload, when it could evade a significant degree of drop. This is an issue whether the ECN-capable traffic is L4S or Classic.
特定の過負荷メカニズムがなければ、反応のないトラフィックは、ECN対応である場合、より大きな利点があります。利点は、通常の低レベルのマーキングでは検出できません。ただし、かなりの程度の低下を回避できる場合、過負荷中に典型的なより高いレベルのマーキングで重要になります。これは、ECN対応トラフィックがL4Sであろうとクラシックであるかどうかの問題です。
This raises the question of whether and when to introduce drop of ECN-capable traffic, as required by both Section 7 of the ECN spec [RFC3168] and Section 4.2.1 of the AQM recommendations [RFC7567].
これにより、ECN仕様[RFC3168]のセクション7とAQM推奨[RFC7567]のセクション4.2.1の両方で要求されるように、ECN対応トラフィックのドロップを導入するかどうか、いつ導入するかという問題が提起されます。
As an example, experiments with the DualPI2 AQM (Appendix A) have shown that introducing 'drop on saturation' at 100% coupled L4S marking addresses this problem with unresponsive ECN, and it also addresses the saturation problem. At saturation, DualPI2 switches into overload mode, where the Base AQM is driven by the max delay of both queues, and it introduces probabilistic drop to both queues equally. It leaves only a small range of congestion levels just below saturation where unresponsive traffic gains any advantage from using the ECN capability (relative to being unresponsive without ECN), and the advantage is hardly detectable (see [DualQ-Test] and section IV-G of [L4Seval22]). Also, overload with an unresponsive ECT(1) flow gets no more bandwidth advantage than with ECT(0).
例として、DualPi2 AQM（付録A）の実験により、100％結合されたL4Sで「飽和」を導入することで、この問題が反応しないECNに対処することが示されており、飽和問題にも対処しています。飽和時に、dualPi2は過負荷モードに切り替わります。ここで、ベースAQMは両方のキューの最大遅延によって駆動され、両方のキューに確率的低下を均等に導入します。飽和レベルのすぐ下にある渋滞レベルのみを残します。これにより、無反応のトラフィックがECN機能（ECNなしでは反応しないことと比較して）を使用することで利点があり、その利点はほとんど検出できません（[dualq-test]およびセクションIV-gを参照してください。[l4seval22]）。また、反応しないECT（1）フローを使用して過負荷は、ECT（0）よりも帯域幅の利点がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、DOI 10.17487/RFC3168、2001年9月、<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>.
[RFC8311] Black、D。、「明示的な混雑通知（ECN）実験に対するリラックス制限」、RFC 8311、DOI 10.17487/RFC8311、2018年1月、<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>.
[RFC9331] De Schepper、K。およびB. Briscoe編、「低潜伏期、低損失、およびスケーラブルなスループット（L4S）のための明示的な混雑通知（ECN）プロトコル」、RFC 9331、DOI 10.17487/RFC9331、202331、<https://www.rfc-editor.org/info/rfc9331>。
[Alizadeh-stability] Alizadeh, M., Javanmard, A., and B. Prabhakar, "Analysis of DCTCP: Stability, Convergence, and Fairness", SIGMETRICS '11: Proceedings of the ACM SIGMETRICS Joint International Conference on Measurement and Modeling of Computer Systems, pp. 73-84, DOI 10.1145/1993744.1993753, June 2011, <https://dl.acm.org/citation.cfm?id=1993753>.
[Alizadeh安定性] Alizadeh、M.、Javanmard、A。、およびB. Prabhakar、「DCTCPの分析：安定性、収束、公平性」、Sigmetrics '11：ACM Sigmetrics共同国際会議の議事録測定とモデリングの測定とモデリングの議事録コンピューターシステム、pp。73-84、DOI 10.1145/1993744.1993753、2011年6月、<https://dl.acm.org/citation.cfm?id=1993753>。
[AQMmetrics] Kwon, M. and S. Fahmy, "A Comparison of Load-based and Queue-based Active Queue Management Algorithms", Proc. Int'l Soc. for Optical Engineering (SPIE), Vol. 4866, pp. 35-46, DOI 10.1117/12.473021, 2002, <https://www.cs.purdue.edu/homes/fahmy/papers/ldc.pdf>.
[Aqmmetrics] Kwon、M。およびS. Fahmy、「ロードベースとキューベースのアクティブキュー管理アルゴリズムの比較」、Proc。int'l soc。光学工学（SPIE）、Vol。4866、pp。35-46、doi 10.1117/12.473021、2002、<https://www.cs.purdue.edu/homes/fahmy/papers/ldc.pdf>。
[ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An Algorithm for Increasing the Robustness of RED's Active Queue Management", ACIRI Technical Report 301, August 2001, <https://www.icsi.berkeley.edu/icsi/node/2032>.
[ARED01] Floyd、S.、Gummadi、R。、およびS. Shenker、「適応レッド：Redのアクティブキュー管理の堅牢性を高めるためのアルゴリズム」、Aciri Technical Report 301、2001年8月、<https：// www。Icsi.berkeley.edu/icsi/node/2032>。
[BBR-CC] Cardwell, N., Cheng, Y., Hassas Yeganeh, S., Swett, I., and V. Jacobson, "BBR Congestion Control", Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion-control-02, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>.
[BBR-CC] Cardwell、N.、Cheng、Y.、Hassas Yeganeh、S.、Swett、I。、およびV. Jacobson、「BBR輻輳制御」、進行中の作業、インターネットドラフト、Draft-Cardwell-Iccrg-bbr-congestion-control-02、2022年3月7日、<https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>。
[BBRv2] "TCP BBR v2 Alpha/Preview Release", commit 17700ca, June 2022, <https://github.com/google/bbr>.
[BBRV2]「TCP BBR V2 ALPHA/プレビューリリース」、Commit 17700CA、2022年6月、<https://github.com/google/bbr>。
[Boru20] Boru Oljira, D., Grinnemo, K-J., Brunstrom, A., and J. Taheri, "Validating the Sharing Behavior and Latency Characteristics of the L4S Architecture", ACM SIGCOMM Computer Communication Review, Vol. 50, Issue 2, pp. 37-44, DOI 10.1145/3402413.3402419, May 2020, <https://dl.acm.org/doi/abs/10.1145/3402413.3402419>.
[Boru20] Boru Oljira、D.、Grinnemo、K-J。、Brunstrom、A。、およびJ. Taheri、「L4Sアーキテクチャの共有行動とレイテンシ特性の検証」、ACM Sigomm Computer Communication Review、Vol。50、第2号、pp。37-44、DOI 10.1145/3402413.3402419、2020年5月<https://dl.acm.org/doi/abs/10.1145/3402413.3402419>。
[CCcensus19] Mishra, A., Sun, X., Jain, A., Pande, S., Joshi, R., and B. Leong, "The Great Internet TCP Congestion Control Census", Proceedings of the ACM on Measurement and Analysis of Computing Systems, Vol. 3, Issue 3, Article No. 45, pp. 1-24, DOI 10.1145/3366693, December 2019, <https://doi.org/10.1145/3366693>.
[Cccensus19] Mishra、A.、Sun、X.、Jain、A.、Pande、S.、Joshi、R.、およびB. Leong、「The Great Internet TCP輻輳制御国勢調査」、測定に関するACMの議事録およびコンピューティングシステムの分析、Vol。3、第3号、第45条、1-24ページ、DOI 10.1145/3366693、2019年12月、<https://doi.org/10.1145/3366693>。
[CoDel] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM Queue, Vol. 10, Issue 5, May 2012, <https://queue.acm.org/issuedetail.cfm?issue=2208917>.
[Codel] Nichols、K。およびV. Jacobson、「Controlling Queue Delay」、ACM Queue、Vol。10、第5号、2012年5月、<https://queue.acm.org/issuedetail.cfm?issue=2208917>。
[CRED_Insights] Briscoe, B. and K. De Schepper, "Insights from Curvy RED (Random Early Detection)", BT Technical Report, TR-TUB8-2015-003, DOI 10.48550/arXiv.1904.07339, August 2015, <https://arxiv.org/abs/1904.07339>.
[Cred_insights] Briscoe、B。and K. de Schepper、「Curvy Redからの洞察（ランダムアーリー検出）」、BTテクニカルレポート、TR-TUB8-2015-003、DOI 10.48550/arxiv.1904.07339、2015年8月、<https：//arxiv.org/abs/1904.07339>。
[DOCSIS-Q-PROT] Briscoe, B., Ed. and G. White, "The DOCSIS Queue Protection to Preserve Low Latency", Work in Progress, Internet-Draft, draft-briscoe-docsis-q-protection-06, 13 May 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection-06>.
[Docsis-Q-Prot] Briscoe、B.、ed。G. White、「低レイテンシを維持するためのDOCSISキュー保護」、進行中の作業、インターネットドラフト、ドラフトブリスコドクシス-Q-Protection-06、2022年5月13日、<https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-potection-06>。
[DOCSIS3.1] CableLabs, "DOCSIS 3.1 MAC and Upper Layer Protocols Interface Specification", CM-SP-MULPIv3.1, Data-Over-Cable Service Interface Specifications DOCSIS 3.1 Version I17 or later, January 2019, <https://specification-search.cablelabs.com/CM-SP-MULPIv3>.
[docsis3.1] cablelabs、 "docsis 3.1 Macおよび上層プロトコルインターフェイス仕様"、cm-sp-mulpiv3.1、data-over cable cable cable cable cable cable cable cable service仕様docsis 3.1バージョンI17以降、2019年1月、<https：//specification-search.cablelabs.com/cm-sp-mulpiv3>。
[DualPI2Linux] Albisser, O., De Schepper, K., Briscoe, B., Tilmans, O., and H. Steen, "DUALPI2 - Low Latency, Low Loss and Scalable (L4S) AQM", Proceedings of Linux Netdev 0x13 , March 2019, <https://www.netdevconf.org/0x13/ session.html?talk-DUALPI2-AQM>.
[dualpi2linux] Albisser、O.、de Schepper、K.、Briscoe、B.、Tilmans、O.、およびH. Steen、 "dualpi2-低遅延、低損失とスケーラブル（L4S）AQM"、Linux NetDev 0x13の議事録、2019年3月、<https://www.netdevconf.org/0x13/ session.html？talk-dualpi2-aqm>。
[DualQ-Test] Steen, H., "Destruction Testing: Ultra-Low Delay using Dual Queue Coupled Active Queue Management", Master's Thesis, Department of Informatics, University of Oslo, May 2017.
[Dualq-Test] Steen、H。、「破壊試験：デュアルキュー結合アクティブキュー管理を使用した超低遅延」、修士論文、情報学部、オスロ大学、2017年5月。
[Dukkipati06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is the Right Metric for Congestion Control", ACM SIGCOMM Computer Communication Review, Vol. 36, Issue 1, pp. 59-62, DOI 10.1145/1111322.1111336, January 2006, <https://dl.acm.org/doi/10.1145/1111322.1111336>.
[Dukkipati06] Dukkipati、N。およびN. McKeown、「なぜフロー完了時間が混雑制御に適したメトリックであるのか」、ACM Sigcomm Computer Communication Review、Vol。36、第1号、59-62ページ、DOI 10.1145/1111322.111111336、2006年1月、<https://dl.acm.org/doi/10.1145/1111322.11111336>。
[Heist21] "L4S Tests", commit e21cd91, August 2021, <https://github.com/heistp/l4s-tests>.
[Heist21] "L4Sテスト"、E21CD91を2021年8月、<https://github.com/heistp/l4s-tests>。
[L4S-DIFFSERV] Briscoe, B., "Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services", Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-diffserv-02, 4 November 2018, <https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>.
[L4S-Diffserv] Briscoe、B。、「低遅延、低損失、スケーラブルスループット（L4S）および差別化サービスの相互作用」、進行中の作業、インターネットドラフト、ドラフトブリスコー-TVWG-L4S-DiffServ-02、42018年11月、<https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>。
[L4Sdemo16] Bondarenko, O., De Schepper, K., Tsang, I., Briscoe, B., Petlund, A., and C. Griwodz, "Ultra-Low Delay for All: Live Experience, Live Analysis", Proceedings of the 7th International Conference on Multimedia Systems, Article No. 33, pp. 1-4, DOI 10.1145/2910017.2910633, May 2016, <https://dl.acm.org/citation.cfm?doid=2910017.2910633>.
[L4SDEMO16] Bondarenko、O.、De Schepper、K.、Tsang、I.、Briscoe、B.、Petlund、A。、およびC. Griwodz、「すべてのための超低遅延：ライブエクスペリエンス、ライブ分析」、手続きマルチメディアシステムに関する第7回国際会議、第33条、1-4ページ、DOI 10.1145/2910017.2910633、2016年5月<https://dl.acm.org/citation.cfm？doid=2910017.2910633>。
[L4Seval22] De Schepper, K., Albisser, O., Tilmans, O., and B. Briscoe, "Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All", Preprint submitted to IEEE/ACM Transactions on Networking, DOI 10.48550/arXiv.2209.01078, September 2022, <https://arxiv.org/abs/2209.01078>.
[L4Seval22] De Schepper、K.、Albisser、O.、Tilmans、O.、およびB. Briscoe、「デュアルキュー結合AQM：すべてのために非常に低いキューイング遅延遅延」、ネットワーキングでIEEE/ACMトランザクションに提出されたプレリント、DOI10.48550/arxiv.2209.01078、2022年9月、<https://arxiv.org/abs/2209.01078>。
[L4S_5G] Willars, P., Wittenmark, E., Ronkainen, H., stberg, C., Johansson, I., Strand, J., Ldl, P., and D. Schnieders, "Enabling time-critical applications over 5G with rate adaptation", Ericsson - Deutsche Telekom White Paper, BNEW-21:025455, May 2021, <https://www.ericsson.com/en/ reports-and-papers/white-papers/enabling-time-critical-applications-over-5g-with-rate-adaptation>.
[L4S_5G] Willars、P.、Wittenmark、E.、Ronkainen、H.、Stberg、C.、Johansson、I.、Strand、J.、Ldl、P。、およびD. Schnieders、「時間批判的なアプリケーションを可能にする」5Gレート適応」、エリクソン - エリクソン - ドイツテレコムホワイトペーパー、BNEW-21：025455、2021年5月、<https://www.ericsson.com/en/ Reports-and-papers/White-Papers/Enabling-Time-Critical-applications-over-with-rate-adaptation>。
[Labovitz10] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J., and F. Jahanian, "Internet Inter-Domain Traffic", ACM SIGCOMM Computer Communication Review, Vol. 40, Issue 4, pp. 75-86, DOI 10.1145/1851275.1851194, August 2010, <https://doi.org/10.1145/1851275.1851194>.
[Labovitz10] Labovitz、C.、Iekel-Johnson、S.、McPherson、D.、Oberheide、J。、およびF. Jahanian、「インターネット間ドメイントラフィック」、ACM Sigcomm Computer Communication Review、Vol。40、第4号、75-86ページ、DOI 10.1145/1851275.1851194、2010年8月、<https://doi.org/10.1145/1851275.1851194>。
[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>.
[LLD] White、G.、Sundaresan、K。、およびB. Briscoe、「Low Latency Docsis：Technology Overview」、CableLabs White Paper、2019年2月、<https://cablela.bs/low-latedency-docsistechnology-2019-February-February>。
[MEDF] Menth, M., Schmid, M., Heiss, H., and T. Reim, "MEDF - A Simple Scheduling Algorithm for Two Real-Time Transport Service Classes with Application in the UTRAN", Proc. IEEE Conference on Computer Communications (INFOCOM'03), Vol. 2, pp. 1116-1122, DOI 10.1109/INFCOM.2003.1208948, March 2003, <https://doi.org/10.1109/INFCOM.2003.1208948>.
[Medf] Menth、M.、Schmid、M.、Heiss、H。、およびT. Reim、「Medf -Utranでの適用を伴う2つのリアルタイム輸送サービスクラスの簡単なスケジューリングアルゴリズム」、Proc。IEEE Conference on Computer Communications（InfoCom'03）、Vol。2、pp。1116-1122、doi 10.1109/infcom.2003.1208948、2003年3月、<https://doi.org/10.1109/infcom.2003.1208948>。
[PI2] De Schepper, K., Bondarenko, O., Briscoe, B., and I. Tsang, "PI2: A Linearized AQM for both Classic and Scalable TCP", ACM CoNEXT'16, DOI 10.1145/2999572.2999578, December 2016, <https://dl.acm.org/doi/10.1145/2999572.2999578>.
[PI2] De Schepper、K.、Bondarenko、O.、Briscoe、B。、およびI. Tsang、「Pi2：ACM Conext'16、DOI 10.1145/2999572.2999578、2016年12月、<https://dl.acm.org/doi/10.1145/299572.2999578>。
[PI2param] Briscoe, B., "PI2 Parameters", Technical Report, TR-BB-2021-001, arXiv:2107.01003 [cs.NI], DOI 10.48550/arXiv.2107.01003, July 2021, <https://arxiv.org/abs/2107.01003>.
[Pi2param] Briscoe、B。、「Pi2パラメーター」、テクニカルレポート、TR-BB-2021-001、Arxiv：2107.01003 [Cs.ni]、doi 10.48550/arxiv.2107.01003、2021年7月、<https：// arxiv。org/abs/2107.01003>。
[PRAGUE-CC] De Schepper, K., Tilmans, O., and B. Briscoe, "Prague Congestion Control", Work in Progress, Internet-Draft, draft-briscoe-iccrg-prague-congestion-control-01, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01>.
[Prague-CC] De Schepper、K.、Tilmans、O.、およびB. Briscoe、「Prague commestion Control」、Work in Progress、Internet-Draft、Draft-Briscoe-ICCRG-Prague-Congestion-Control-01、112022年7月、<https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-congestion-control-01>。
[PragueLinux] Briscoe, B., De Schepper, K., Albisser, O., Misund, J., Tilmans, O., Kuehlewind, M., and A. Ahmed, "Implementing the 'TCP Prague' Requirements for L4S", Proceedings of Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>.
[Praguelinux] Briscoe、B.、De Schepper、K.、Albisser、O.、Misund、J.、Tilmans、O.、Kuehlewind、M.、およびA. Ahmed、「L4の「TCP Prague」要件の実装」、Linux NetDev 0x13の議事録、2019年3月、<https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>。
[RED] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, Volume 1, Issue 4, pp. 397-413, DOI 10.1109/90.251892, August 1993, <https://dl.acm.org/doi/10.1109/90.251892>.
[Red] Floyd、S。およびV. Jacobson、「混雑回避のためのランダムな早期検出ゲートウェイ」、ネットワーキングに関するIEEE/ACMトランザクション、第1巻、第4号、pp。397-413、DOI 10.1109/90.251892、1993年8月、<<<<https://dl.acm.org/doi/10.1109/90.251892>。
[RELENTLESS] Mathis, M., "Relentless Congestion Control", Work in Progress, Internet-Draft, draft-mathis-iccrg-relentless-tcp-00, 4 March 2009, <https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00>.
[容赦ない] Mathis、M。、「容赦ない混雑制御」、進行中の作業、インターネットドラフト、Draft-Mathis-ICCRG-Relentless-TCP-00、2009年3月4日、<https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00>。
[RFC0970] Nagle, J., "On Packet Switches With Infinite Storage", RFC 970, DOI 10.17487/RFC0970, December 1985, <https://www.rfc-editor.org/info/rfc970>.
[RFC0970] Nagle、J。、「無限のストレージ付きパケットスイッチ」、RFC 970、DOI 10.17487/RFC0970、1985年12月、<https://www.rfc-editor.org/info/rfc970>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S。、「混雑制御原則」、BCP 41、RFC 2914、DOI 10.17487/RFC2914、2000年9月、<https://www.rfc-editor.org/info/rfc2914>
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.
[RFC3246] Davie、B.、Charny、A.、Bennet、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」転送PHB（PER-HOP行動） "、RFC 3246、DOI 10.17487/RFC3246、2002年3月、<https://www.rfc-editor.org/info/rfc3246>。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, <https://www.rfc-editor.org/info/rfc3649>.
[RFC3649] Floyd、S。、「大輻輳窓用の高速TCP」、RFC 3649、DOI 10.17487/RFC3649、2003年12月、<https://www.rfc-editor.org/info/rfc3649>。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.
[RFC5033] Floyd、S。およびM. Allman、「新しい混雑制御アルゴリズムの指定」、BCP 133、RFC 5033、DOI 10.17487/RFC5033、2007年8月、<https://www.rfc-editor.org/info/rfc5033333>。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, DOI 10.17487/RFC5348, September 2008, <https://www.rfc-editor.org/info/rfc5348>.
[RFC5348] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：プロトコル仕様」、RFC 5348、DOI 10.17487/RFC5348、2008年9月、<https：//www.rfc-editor.org/info/rfc5348>。
[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>.
[RFC5681] Allman、M.、Paxson、V.、およびE. Blanton、「TCP混雑制御」、RFC 5681、DOI 10.17487/RFC5681、2009年9月、<https://www.rfc-editor.org/info/RFC5681>。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC5706] Harrington、D。、「新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン」、RFC 5706、DOI 10.17487/RFC5706、2009年11月、<https：//www.rfc-editor.org/fo/rfc5706>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.
[RFC7567] Baker、F.、ed。and G. Fairhurst、ed。、「アクティブキュー管理に関するIETF推奨」、BCP 197、RFC 7567、DOI 10.17487/RFC7567、2015年7月、<https://www.rfc-editor.org/info/rfc7567>
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.
[RFC8033] Pan、R.、Natarajan、P.、Baker、F.、およびG. White、「比例積分コントローラー拡張（PIE）：バッファーブロートの問題に対処するための軽量制御スキーム」、RFC 8033、DOI 10.17487/RFC8033333、2017年2月、<https://www.rfc-editor.org/info/rfc8033>。
[RFC8034] White, G. and R. Pan, "Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems", RFC 8034, DOI 10.17487/RFC8034, February 2017, <https://www.rfc-editor.org/info/rfc8034>.
[RFC8034] White、G。およびR. Pan、「データオーバーサービスインターフェイス仕様（DOCSIS）ケーブルモデムの比例積分コントローラー拡張（PIE）に基づくアクティブキュー管理（AQM）」、RFC 8034、DOI 10.17487/RFC8034、2017年2月、<https://www.rfc-editor.org/info/rfc8034>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>.
[RFC8257] Bensley、S.、Thaler、D.、Balasubramanian、P.、Eggert、L。、およびG. Judd、「データセンターTCP（DCTCP）：データセンターのTCP混雑制御」、RFC 8257、DOI 10.17487/RFC8257、2017年10月、<https://www.rfc-editor.org/info/rfc8257>。
[RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm", RFC 8290, DOI 10.17487/RFC8290, January 2018, <https://www.rfc-editor.org/info/rfc8290>.
[RFC8290] Hoeiland-Joergensen、T.、McKenney、P.、Taht、D.、Gettys、J。、およびE. Dumazet、「The Flow Queue Codel Packet Schedul and Active Keue Management Algorithm」、RFC 8290、DOI 10.17487/RFC8290、2018年1月、<https://www.rfc-editor.org/info/rfc8290>。
[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>.
[RFC8298] Johansson、I。およびZ. Sarker、「マルチメディアのセルフクロックレート適応」、RFC 8298、DOI 10.17487/RFC8298、2017年12月、<https://www.rfc-editor.org/info/rfc8298>。
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.
[RFC8312] Rhee、I.、Xu、L.、Ha、S.、Zimmermann、A.、Eggert、L。、およびR. Scheffenegger、「高速距離ネットワークのためのキュービック」、RFC 8312、DOI 10.17487/RFC83122、2018年2月、<https://www.rfc-editor.org/info/rfc8312>。
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.
[RFC8404] Moriarty、K。、ed。and A. Morton、ed。、「オペレーターに対する広範な暗号化の影響」、RFC 8404、DOI 10.17487/RFC8404、2018年7月、<https://www.rfc-editor.org/info/rfc8404>。
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[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>.
[RFC9330] Briscoe、B.、Ed。、De Schepper、K.、Bagnulo、M.、およびG. White、「低遅延、低損失、スケーラブルなスループット（L4S）インターネットサービス：アーキテクチャ」、RFC 9330、DOI10.17487/rfc9330、2023年1月、<https://www.rfc-editor.org/info/rfc9330>。
[SCReAM-L4S] "SCReAM", commit fda6c53, June 2022, <https://github.com/EricssonResearch/scream>.
[Scream-l4s] "Scream"、commit fda6c53、2022年6月、<https://github.com/ericssonresearch/scream>。
[SigQ-Dyn] Briscoe, B., "Rapid Signalling of Queue Dynamics", Technical Report, TR-BB-2017-001, DOI 10.48550/arXiv.1904.07044, September 2017, <https://arxiv.org/abs/1904.07044>.
[Sigq-Dyn] Briscoe、B。、「キューダイナミクスの迅速なシグナル伝達」、テクニカルレポート、TR-BB-2017-001、DOI 10.48550/arxiv.1904.07044、2017年9月、<https://arxiv.org/abs/1904.07044>。
As a first concrete example, the pseudocode below gives the DualPI2 algorithm. DualPI2 follows the structure of the DualQ Coupled AQM framework in Figure 1. A simple ramp function (configured in units of queuing time) with unsmoothed ECN marking is used for the Native L4S AQM. The ramp can also be configured as a step function. The PI2 algorithm [PI2] is used for the Classic AQM. PI2 is an improved variant of the PIE AQM [RFC8033].
最初の具体的な例として、以下の擬似コードはdualpi2アルゴリズムを示します。DUALPI2は、図1のDualQ結合されたAQMフレームワークの構造に従います。単純なランプ関数（キューイング時間の単位で構成）を使用して、滑らかなECNマークを使用して、ネイティブL4S AQMに使用されます。ランプは、ステップ関数として構成することもできます。PI2アルゴリズム[PI2]は、古典的なAQMに使用されます。PI2は、PIE AQM [RFC8033]の改善されたバリアントです。
The pseudocode will be introduced in two passes. The first pass explains the core concepts, deferring handling of edge-cases like overload to the second pass. To aid comparison, line numbers are kept in step between the two passes by using letter suffixes where the longer code needs extra lines.
Pseudocodeは2回のパスで導入されます。最初のパスでは、コアの概念を説明し、2番目のパスへのオーバーロードなどのエッジケースの処理を延期します。比較を支援するために、より長いコードに追加の行が必要な文字接尾辞を使用して、2つのパスの間にライン番号が維持されます。
All variables are assumed to be floating point in their basic units (size in bytes, time in seconds, rates in bytes/second, alpha and beta in Hz, and probabilities from 0 to 1). Constants expressed in k (kilo), M (mega), G (giga), u (micro), m (milli), %, and so forth, are assumed to be converted to their appropriate multiple or fraction to represent the basic units. A real implementation that wants to use integer values needs to handle appropriate scaling factors and allow appropriate resolution of its integer types (including temporary internal values during calculations).
すべての変数は、基本単位の浮動ポイント（バイトのサイズ、秒単位の時間、バイト/秒のレート、Hzのアルファとベータ版、および0〜1の確率）の浮動ポイントであると想定されます。K（kilo）、m（mega）、g（giga）、u（micro）、m（milli）、％などで発現する定数は、基本単位を表すために適切な複数または分数に変換されると想定されています。整数値を使用したい実際の実装では、適切なスケーリング係数を処理し、整数タイプ（計算中の一時的な内部値を含む）の適切な解像度を可能にする必要があります。
A full open source implementation for Linux is available at <https://github.com/L4STeam/sch_dualpi2_upstream> and explained in [DualPI2Linux]. The specification of the DualQ Coupled AQM for DOCSIS cable modems and cable modem termination systems (CMTSs) is available in [DOCSIS3.1] and explained in [LLD].
Linuxの完全なオープンソースの実装は、<https://github.com/l4steam/sch_dualpi2_upstream>で入手でき、[dualpi2linux]で説明されています。DOCSISケーブルモデムとケーブルモデム終端システム（CMTSS）のDualQ結合AQMの仕様は[docsis3.1]で利用可能であり、[LLD]で説明されています。
The pseudocode manipulates three main structures of variables: the packet (pkt), the L4S queue (lq), and the Classic queue (cq). The pseudocode consists of the following six functions:
擬似コードは、変数の3つの主要な構造を操作します：パケット（PKT）、L4Sキュー（LQ）、およびクラシックキュー（CQ）。擬似コードは、次の6つの関数で構成されています。
* The initialization function dualpi2_params_init(...) (Figure 2) that sets parameter defaults (the API for setting non-default values is omitted for brevity).
* パラメーターのデフォルトを設定する初期化関数dualpi2_params_init（...）（図2）
* The enqueue function dualpi2_enqueue(lq, cq, pkt) (Figure 3).
* Enqueue関数dualpi2_enqueue（LQ、CQ、PKT）（図3）。
* The dequeue function dualpi2_dequeue(lq, cq, pkt) (Figure 4).
* Dequeue関数Dualpi2_Dequeue（LQ、CQ、PKT）（図4）。
* The recurrence function recur(q, likelihood) for de-randomized ECN marking (shown at the end of Figure 4).
* 再発性ECNマーキングの再発関数が再発します（q、尤度）（図4の最後に示す）。
* The L4S AQM function laqm(qdelay) (Figure 5) used to calculate the ECN-marking probability for the L4S queue.
* L4S ACM関数LAQM（QDELAY）（図5）は、L4SキューのECNマーク確率を計算するために使用されました。
* The Base AQM function that implements the PI algorithm dualpi2_update(lq, cq) (Figure 6) used to regularly update the base probability (p'), which is squared for the Classic AQM as well as being coupled across to the L4S queue.
* PIアルゴリズムdualpi2_update（LQ、CQ）（図6）を実装するベースAQM関数（図6）は、ベース確率（P '）を定期的に更新するために使用されます。
It also uses the following functions that are not shown in full here:
また、ここでは完全には表示されない次の機能も使用しています。
* scheduler(), which selects between the head packets of the two queues. The choice of scheduler technology is discussed later.
* 2つのキューのヘッドパケット間で選択するスケジューラ（）。スケジューラテクノロジーの選択については後で説明します。
* cq.byt() or lq.byt() returns the current length (a.k.a. backlog) of the relevant queue in bytes.
* cq.byt（）またはlq.byt（）は、関連するキューの現在の長さ（a.k.a.バックログ）をバイトで返します。
* cq.len() or lq.len() returns the current length of the relevant queue in packets.
* cq.len（）またはlq.len（）は、関連するキューの現在の長さをパケットに返します。
* cq.time() or lq.time() returns the current queuing delay of the relevant queue in units of time (see Note a below).
* cq.time（）またはlq.time（）は、時間単位の関連するキューの現在のキューイング遅延を返します（以下の注意を参照）。
* mark(pkt) and drop(pkt) for ECN marking and dropping a packet.
* ECNマークとドロップのマーク（PKT）およびドロップ（PKT）。
In experiments so far (building on experiments with PIE) on broadband access links ranging from 4 Mb/s to 200 Mb/s with base RTTs from 5 ms to 100 ms, DualPI2 achieves good results with the default parameters in Figure 2. The parameters are categorised by whether they relate to the PI2 AQM, the L4S AQM, or the framework coupling them together. Constants and variables derived from these parameters are also included at the end of each category. Each parameter is explained as it is encountered in the walk-through of the pseudocode below, and the rationale for the chosen defaults are given so that sensible values can be used in scenarios other than the regular public Internet.
これまでの実験では（PIEを使用した実験に基づいて構築）、4 MB/sから200 MB/sの範囲のブロードバンドアクセスリンクで、ベースRTTSが5 msから100 msの範囲で、Dualpi2は図2のデフォルトパラメーターで良い結果を達成します。それらがPI2 AQM、L4S AQM、またはそれらを結合するフレームワークに関連するかどうかによって分類されます。これらのパラメーターから派生した定数と変数は、各カテゴリの最後にも含まれています。各パラメーターは、以下の擬似コードのウォークスルーで遭遇するときに説明され、選択したデフォルトの理論的根拠が与えられるように、通常のパブリックインターネット以外のシナリオで賢明な値を使用できるようにします。
1: dualpi2_params_init(...) { % Set input parameter defaults
2: % DualQ Coupled framework parameters
5: limit = MAX_LINK_RATE * 250 ms % Dual buffer size
3: k = 2 % Coupling factor
4: % NOT SHOWN % scheduler-dependent weight or equival't parameter
6:
7: % PI2 Classic AQM parameters
8: target = 15 ms % Queue delay target
9: RTT_max = 100 ms % Worst case RTT expected
10: % PI2 constants derived from above PI2 parameters
11: p_Cmax = min(1/k^2, 1) % Max Classic drop/mark prob
12: Tupdate = min(target, RTT_max/3) % PI sampling interval
13: alpha = 0.1 * Tupdate / RTT_max^2 % PI integral gain in Hz
14: beta = 0.3 / RTT_max % PI proportional gain in Hz
15:
16: % L4S ramp AQM parameters
17: minTh = 800 us % L4S min marking threshold in time units
18: range = 400 us % Range of L4S ramp in time units
19: Th_len = 1 pkt % Min L4S marking threshold in packets
20: % L4S constants
21: p_Lmax = 1 % Max L4S marking prob
22: }
Figure 2: Example Header Pseudocode for DualQ Coupled PI2 AQM
図2：デュアルク結合PI2 AQMのヘッダー擬似コードの例
The overall goal of the code is to apply the marking and dropping probabilities for L4S and Classic traffic (p_L and p_C). These are derived from the underlying base probabilities p'_L and p' driven, respectively, by the traffic in the L and C queues. The marking probability for the L queue (p_L) depends on both the base probability in its own queue (p'_L) and a probability called p_CL, which is coupled across from p' in the C queue (see Section 2.4 for the derivation of the specific equations and dependencies).
コードの全体的な目標は、L4とクラシックトラフィック（P_LおよびP_C）にマークとドロップの確率を適用することです。これらは、LおよびCキューのトラフィックによって、それぞれ基礎となるベース確率p'_LおよびP '駆動型から導き出されます。Lキュー（P_L）のマーキング確率は、独自のキュー（P'_L）の基本確率とP_CLと呼ばれる確率の両方に依存します。特定の方程式と依存関係）。
The probabilities p_CL and p_C are derived in lines 4 and 5 of the dualpi2_update() function (Figure 6) then used in the dualpi2_dequeue() function where p_L is also derived from p_CL at line 6 (Figure 4). The code walk-through below builds up to explaining that part of the code eventually, but it starts from packet arrival.
確率P_CLとP_Cは、DualPi2_Update（）関数（図6）の4行目と5で導出され、DualPi2_Dequeue（）関数で使用されます。ここで、P_Lは6行目のP_CLからも導出されます（図4）。以下のコードウォークスルーは、最終的にコードの一部を説明するために構築されますが、パケットの到着から始まります。
1: dualpi2_enqueue(lq, cq, pkt) { % Test limit and classify lq or cq
2: if ( lq.byt() + cq.byt() + MTU > limit)
3: drop(pkt) % drop packet if buffer is full
4: timestamp(pkt) % only needed if using the sojourn technique
5: % Packet classifier
6: if ( ecn(pkt) modulo 2 == 1 ) % ECN bits = ECT(1) or CE
7: lq.enqueue(pkt)
8: else % ECN bits = not-ECT or ECT(0)
9: cq.enqueue(pkt)
10: }
Figure 3: Example Enqueue Pseudocode for DualQ Coupled PI2 AQM
図3：デュアルク結合PI2 AQMのEnqueue Pseudocodeの例
1: dualpi2_dequeue(lq, cq, pkt) { % Couples L4S & Classic queues
2: while ( lq.byt() + cq.byt() > 0 ) {
3: if ( scheduler() == lq ) {
4: lq.dequeue(pkt) % Scheduler chooses lq
5: p'_L = laqm(lq.time()) % Native LAQM
6: p_L = max(p'_L, p_CL) % Combining function
7: if ( recur(lq, p_L) ) % Linear marking
8: mark(pkt)
9: } else {
10: cq.dequeue(pkt) % Scheduler chooses cq
11: if ( recur(cq, p_C) ) { % probability p_C = p'^2
12: if ( ecn(pkt) == 0 ) { % if ECN field = not-ECT
13: drop(pkt) % squared drop
14: continue % continue to the top of the while loop
15: }
16: mark(pkt) % squared mark
17: }
18: }
19: return(pkt) % return the packet and stop
20: }
21: return(NULL) % no packet to dequeue
22: }
23: recur(q, likelihood) { % Returns TRUE with a certain likelihood
24: q.count += likelihood
25: if (q.count > 1) {
26: q.count -= 1
27: return TRUE
28: }
29: return FALSE
30: }
Figure 4: Example Dequeue Pseudocode for DualQ Coupled PI2 AQM
図4：DualQ結合PI2 AQMのDequeue Pseudocodeの例
When packets arrive, a common queue limit is checked first as shown in line 2 of the enqueuing pseudocode in Figure 3. This assumes a shared buffer for the two queues (Note b discusses the merits of separate buffers). In order to avoid any bias against larger packets, 1 MTU of space is always allowed, and the limit is deliberately tested before enqueue.
パケットが到着すると、図3のエンキュー擬似コードの2行目に示されているように、共通のキュー制限が最初にチェックされます。大きなパケットに対するバイアスを回避するために、1 MTUのスペースが常に許可され、制限はEnqueueの前に意図的にテストされます。
If limit is not exceeded, the packet is timestamped in line 4 (only if the sojourn time technique is being used to measure queue delay; see Note a below for alternatives).
制限を超えない場合、パケットは4行目でタイムスタンプされます（キューの遅延を測定するために滞在時間手法が使用されている場合のみ。代替案については以下のメモを参照してください）。
At lines 5-9, the packet is classified and enqueued to the Classic or L4S queue dependent on the least significant bit (LSB) of the ECN field in the IP header (line 6). Packets with a codepoint having an LSB of 0 (Not-ECT and ECT(0)) will be enqueued in the Classic queue. Otherwise, ECT(1) and CE packets will be enqueued in the L4S queue. Optional additional packet classification flexibility is omitted for brevity (see the L4S ECN protocol [RFC9331]).
5〜9行目では、パケットは分類され、IPヘッダーのECNフィールドの最小有意ビット（LSB）に依存するクラシックまたはL4Sキューに囲まれています（6行目）。LSBが0（not-ectおよびect（0））を持つコードポイントを備えたパケットは、クラシックキューに囲まれています。それ以外の場合、ECT（1）とCEパケットはL4Sキューに囲まれます。オプションの追加パケット分類の柔軟性は、簡潔にするために省略されています（L4S ECNプロトコル[RFC9331]を参照）。
The dequeue pseudocode (Figure 4) is repeatedly called whenever the lower layer is ready to forward a packet. It schedules one packet for dequeuing (or zero if the queue is empty) then returns control to the caller so that it does not block while that packet is being forwarded. While making this dequeue decision, it also makes the necessary AQM decisions on dropping or marking. The alternative of applying the AQMs at enqueue would shift some processing from the critical time when each packet is dequeued. However, it would also add a whole queue of delay to the control signals, making the control loop sloppier (for a typical RTT, it would double the Classic queue's feedback delay).
Dequeue Pseudocode（図4）は、下層がパケットを転送する準備ができている場合はいつでも繰り返し呼び出されます。Dequeuing（またはキューが空の場合はゼロ）のパケットが1つスケジュールされ、そのパケットが転送されている間にブロックされないようにコントロールを呼び出し元に返します。このDequeueの決定を下しながら、ドロップまたはマーキングに必要なAQMの決定も行います。EnqueueでAQMSを適用する代替手段は、各パケットがデケートされている場合の重要な時期から何らかの処理をシフトします。ただし、コントロール信号に遅延のキュー全体を追加して、コントロールループをスロップパイアーにします（典型的なRTTの場合、古典的なキューのフィードバック遅延を2倍にします）。
All the dequeue code is contained within a large while loop so that if it decides to drop a packet, it will continue until it selects a packet to schedule. Line 3 of the dequeue pseudocode is where the scheduler chooses between the L4S queue (lq) and the Classic queue (cq). Detailed implementation of the scheduler is not shown (see discussion later).
すべてのdequeueコードは大きなwhileループ内に含まれているため、パケットをドロップすることを決定した場合、スケジュールするパケットを選択するまで続きます。Dequeue Pseudocodeの3行目は、スケジューラがL4Sキュー（LQ）とクラシックキュー（CQ）の間で選択する場所です。スケジューラの詳細な実装は表示されません（後で説明を参照）。
* If an L4S packet is scheduled, in lines 7 and 8 the packet is ECN-marked with likelihood p_L. The recur() function at the end of Figure 4 is used, which is preferred over random marking because it avoids delay due to randomization when interpreting congestion signals, but it still desynchronizes the sawteeth of the flows. Line 6 calculates p_L as the maximum of the coupled L4S probability p_CL and the probability from the Native L4S AQM p'_L. This implements the max() function shown in Figure 1 to couple the outputs of the two AQMs together. Of the two probabilities input to p_L in line 6:
* L4Sパケットがスケジュールされている場合、7行目と8行目でパケットは、尤度P_LでeCNマークされています。図4の最後のrecur（）関数が使用されます。これは、渋滞信号を解釈するときにランダム化による遅延を回避するため、ランダムマーキングよりも好まれますが、流れの鋸を非同期化します。行6は、P_Lを結合したL4S確率P_CLの最大値と、ネイティブL4S AQM P'_Lからの確率として計算します。これにより、図1に示すmax（）関数が実装され、2つのAQMの出力を結合します。6行目のP_Lに入力される2つの確率のうち：
- p'_L is calculated per packet in line 5 by the laqm() function (see Figure 5), whereas
- P'_Lは5行目のパケットごとにLAQM（）関数によって計算されます（図5を参照）が、
- p_CL is maintained by the dualpi2_update() function, which runs every Tupdate (Tupdate is set in line 12 of Figure 2).
- P_CLは、すべてのtupdateを実行するDualpi2_update（）関数によって維持されます（Tupdateは図2の12行目に設定されています）。
* If a Classic packet is scheduled, lines 10 to 17 drop or mark the packet with probability p_C.
* クラシックパケットがスケジュールされている場合、10〜17行目は確率P_Cでパケットをドロップまたはマークします。
The Native L4S AQM algorithm (Figure 5) is a ramp function, similar to the RED algorithm, but simplified as follows:
ネイティブL4S AQMアルゴリズム（図5）は、赤いアルゴリズムと同様のランプ関数ですが、次のように簡素化されています。
* The extent of the ramp is defined in units of queuing delay, not bytes, so that configuration remains invariant as the queue departure rate varies.
* ランプの範囲は、バイトではなくキューイング遅延の単位で定義されるため、キューの出発率が変化するにつれて構成が不変のままです。
* It uses instantaneous queuing delay, which avoids the complexity of smoothing, but also avoids embedding a worst-case RTT of smoothing delay in the network (see Section 2.1).
* 瞬間的なキューイング遅延を使用して、スムージングの複雑さを回避しますが、ネットワークに最悪のRTTのスムージング遅延の埋め込みも回避します（セクション2.1を参照）。
* The ramp rises linearly directly from 0 to 1, not to an intermediate value of p'_L as RED would, because there is no need to keep ECN-marking probability low.
* RAMPは、ECNマーク確率を低く保つ必要がないため、赤のようにP'_Lの中間値ではなく、0から1に直接直接上昇します。
* Marking does not have to be randomized. Determinism is used instead of randomness to reduce the delay necessary to smooth out the noise of randomness from the signal.
* マーキングをランダム化する必要はありません。信号からのランダム性のノイズを滑らかにするために必要な遅延を減らすために、ランダム性の代わりに決定論が使用されます。
The ramp function requires two configuration parameters, the minimum threshold (minTh) and the width of the ramp (range), both in units of queuing time, as shown in lines 17 and 18 of the initialization function in Figure 2. The ramp function can be configured as a step (see Note c).
ランプ関数には、図2の初期化関数の17行目と18行に示すように、キューイング時間の単位単位単位で、最小しきい値（MINTH）とランプの幅（範囲）の2つの構成パラメーターが必要です。ステップとして構成されます（注Cを参照）。
Although the DCTCP paper [Alizadeh-stability] recommends an ECN-marking threshold of 0.17*RTT_typ, it also shows that the threshold can be much shallower with hardly any worse underutilization of the link (because the amplitude of DCTCP's sawteeth is so small). Based on extensive experiments, for the public Internet the default minimum ECN-marking threshold (target) in Figure 2 is considered a good compromise, even though it is a significantly smaller fraction of RTT_typ.
DCTCPペーパー[Alizadeh安定性]は、ECNマークのしきい値0.17*RTT_Typを推奨していますが、閾値ははるかに浅く、リンクの風振幅は非常に小さいため）。広範な実験に基づいて、パブリックインターネットの場合、図2のデフォルトの最小ECNマークしきい値（ターゲット）は、RTT_TYPの割合が大幅に少ないにもかかわらず、良い妥協と見なされます。
1: laqm(qdelay) { % Returns Native L4S AQM probability
2: if (qdelay >= maxTh)
3: return 1
4: else if (qdelay > minTh)
5: return (qdelay - minTh)/range % Divide could use a bit-shift
6: else
7: return 0
8: }
Figure 5: Example Pseudocode for the Native L4S AQM
図5：ネイティブL4S AQMのPseudocodeの例
1: dualpi2_update(lq, cq) { % Update p' every Tupdate
2: curq = cq.time() % use queuing time of first-in Classic packet
3: p' = p' + alpha * (curq - target) + beta * (curq - prevq)
4: p_CL = k * p' % Coupled L4S prob = base prob * coupling factor
5: p_C = p'^2 % Classic prob = (base prob)^2
6: prevq = curq
7: }
Figure 6: Example PI-update Pseudocode for DualQ Coupled PI2 AQM
図6：デュアルク結合PI2 AQMのPI-Up-update Pseudocodeの例
(Note: Clamping p' within the range [0,1] omitted for clarity -- see below.)
（注：範囲内のクランプP '[0,1]明確さのために省略 - 以下を参照してください。）
The coupled marking probability p_CL depends on the base probability (p'), which is kept up to date by executing the core PI algorithm in Figure 6 every Tupdate.
結合マーキング確率p_clは、基本確率（p '）に依存します。これは、図6のコアPiアルゴリズムをすべてのツイップで実行することで最新の状態に保たれます。
Note that p' solely depends on the queuing time in the Classic queue. In line 2, the current queuing delay (curq) is evaluated from how long the head packet was in the Classic queue (cq). The function cq.time() (not shown) subtracts the time stamped at enqueue from the current time (see Note a below) and implicitly takes the current queuing delay as 0 if the queue is empty.
P 'は、古典的なキューのキューイング時間のみに依存することに注意してください。2行目では、現在のキューイング遅延（CURQ）が、ヘッドパケットがクラシックキュー（CQ）にある期間から評価されます。関数cq.time（）（図示せず）は、現在の時刻からenqueueでスタンプされた時間を減算し（以下の注意を参照）、キューが空である場合、現在のキューイング遅延を0として暗黙的に取得します。
The algorithm centres on line 3, which is a classical PI controller that alters p' dependent on: a) the error between the current queuing delay (curq) and the target queuing delay (target) and b) the change in queuing delay since the last sample. The name 'PI' represents the fact that the second factor (how fast the queue is growing) is Proportional to load while the first is the Integral of the load (so it removes any standing queue in excess of the target).
アルゴリズムは3行目に集中します。これは、a）現在のキューイング遅延（CURQ）とターゲットキューイング遅延（ターゲット）とb）との間の誤差に依存するPIコントローラーである古典的なPIコントローラーです。最後のサンプル。「PI」という名前は、2番目の要因（キューが成長している速さ）が負荷に比例するという事実を表していますが、最初の要素は負荷の積分です（したがって、ターゲットを超えるスタンディングキューを削除します）。
The target parameter can be set based on local knowledge, but the aim is for the default to be a good compromise for anywhere in the intended deployment environment -- the public Internet. According to [PI2param], the target queuing delay on line 8 of Figure 2 is related to the typical base RTT worldwide, RTT_typ, by two factors: target = RTT_typ * g * f. Below, we summarize the rationale behind these factors and introduce a further adjustment. The two factors ensure that, in a large proportion of cases (say 90%), the sawtooth variations in RTT of a single flow will fit within the buffer without underutilizing the link. Frankly, these factors are educated guesses, but with the emphasis closer to 'educated' than to 'guess' (see [PI2param] for the full background):
ターゲットパラメーターは、ローカルの知識に基づいて設定できますが、目的は、意図した展開環境のどこでもパブリックインターネットの妥協点であることを目的としています。[PI2PARAM]によると、図2の行8のターゲットキューイング遅延は、ターゲット= RTT_TYP * g * fの2つの要因によって、世界中の典型的なベースRTT rtt_typに関連しています。以下に、これらの要因の背後にある理論的根拠を要約し、さらなる調整を導入します。2つの要因により、大部分のケース（たとえば90％）では、単一のフローのRTTの鋸歯状のバリエーションが、リンクを十分に活用せずにバッファー内に収まることが保証されます。率直に言って、これらの要因は教育を受けた推測ですが、「推測」よりも「教育を受けた」に近いことがあります（完全な背景については[pi2param]を参照）：
* RTT_typ is taken as 25 ms. This is based on an average CDN latency measured in each country weighted by the number of Internet users in that country to produce an overall weighted average for the Internet [PI2param]. Countries were ranked by number of Internet users, and once 90% of Internet users were covered, smaller countries were excluded to avoid small sample sizes that would be less representative. Also, importantly, the data for the average CDN latency in China (with the largest number of Internet users) has been removed, because the CDN latency was a significant outlier and, on reflection, the experimental technique seemed inappropriate to the CDN market in China.
* RTT_TYPは25ミリ秒と見なされます。これは、インターネットの全体的な加重平均を生成するために、その国のインターネットユーザーの数によって重み付けされた各国で測定された平均CDNレイテンシに基づいています[PI2PARAM]。国はインターネットユーザーの数によってランク付けされ、インターネットユーザーの90％がカバーされると、少数のサンプルサイズが少なくなることを避けるために小国が除外されました。また、重要なことに、CDNレイテンシは重要な外れ値であり、反映されているため、中国のCDN市場には実験的手法が不適切であると思われるため、中国の平均CDNレイテンシのデータが削除されました。。
* g is taken as 0.38. The factor g is a geometry factor that characterizes the shape of the sawteeth of prevalent Classic congestion controllers. The geometry factor is the fraction of the amplitude of the sawtooth variability in queue delay that lies below the AQM's target. For instance, at low bitrates, the geometry factor of standard Reno is 0.5, but at higher rates, it tends towards just under 1. According to the census of congestion controllers conducted by Mishra et al. in Jul-Oct 2019 [CCcensus19], most Classic TCP traffic uses CUBIC. And, according to the analysis in [PI2param], if running over a PI2 AQM, a large proportion of this CUBIC traffic would be in its Reno-friendly mode, which has a geometry factor of ~0.39 (for all known implementations). The rest of the CUBIC traffic would be in true CUBIC mode, which has a geometry factor of ~0.36. Without modelling the sawtooth profiles from all the other less prevalent congestion controllers, we estimate a 7:3 weighted average of these two, resulting in an average geometry factor of 0.38.
* Gは0.38と見なされます。因子Gは、一般的な古典的な混雑コントローラーの鋸の形を特徴付ける形状因子です。ジオメトリ係数は、AQMのターゲットを下回るキュー遅延の鋸歯状の変動性の振幅の割合です。たとえば、低ビットレートでは、標準RENOのジオメトリ係数は0.5ですが、より高いレートでは、Mishra et al。2019年7月とオクトで[Cccensus19]では、ほとんどの古典的なTCPトラフィックではCubicを使用しています。また、[Pi2param]の分析によると、PI2 AQMを走ると、この立方体トラフィックの大部分がリノにやさしいモードで、ジオメトリ係数が0.39の（すべての既知の実装に対して）になります。残りの立方体トラフィックは、〜0.36のジオメトリ係数を持つ真の立方モードになります。他のすべての一般的でない混雑コントローラーからのこぎりプロファイルをモデル化することなく、これら2つの7：3の加重平均を推定し、平均ジオメトリ係数は0.38になります。
* f is taken as 2. The factor f is a safety factor that increases the target queue to allow for the distribution of RTT_typ around its mean. Otherwise, the target queue would only avoid underutilization for those users below the mean. It also provides a safety margin for the proportion of paths in use that span beyond the distance between a user and their local CDN. Currently, no data is available on the variance of queue delay around the mean in each region, so there is plenty of room for this guess to become more educated.
* fは2と見なされます。f因子Fは、ターゲットキューを増加させて、その平均を中心にRTT_Typの分布を可能にする安全係数です。それ以外の場合、ターゲットキューは、平均以下のユーザーの十分な活用のみを回避します。また、ユーザーとローカルCDNの間の距離を超えて使用される使用中のパスの割合の安全マージンも提供します。現在、各地域の平均周辺のキュー遅延の分散に関するデータは利用できないため、この推測がより教育を受ける余地は十分にあります。
* [PI2param] recommends target = RTT_typ * g * f = 25 ms * 0.38 * 2 = 19 ms. However, a further adjustment is warranted, because target is moving year-on-year. The paper is based on data collected in 2019, and it mentions evidence from the Speedtest Global Index that suggests RTT_typ reduced by 17% (fixed) or 12% (mobile) between 2020 and 2021. Therefore, we recommend a default of target = 15 ms at the time of writing (2021).
* [Pi2Param]ターゲット= rtt_typ * g * f = 25 ms * 0.38 * 2 = 19 msを推奨します。ただし、ターゲットは前年比で動いているため、さらなる調整が必要です。この論文は2019年に収集されたデータに基づいており、2020年から2021年の間にRTT_Typが17％（固定）または12％（モバイル）減少したことを示唆するSpeedTestグローバルインデックスからの証拠に言及しています。したがって、ターゲットのデフォルト= 15を推奨します執筆時点でのMS（2021）。
Operators can always use the data and discussion in [PI2param] to configure a more appropriate target for their environment. For instance, an operator might wish to question the assumptions called out in that paper, such as the goal of no underutilization for a large majority of single flow transfers (given many large transfers use multiple flows to avoid the scaling limitations of Classic flows).
オペレーターは、[Pi2Param]のデータとディスカッションを常に使用して、環境に適したターゲットを構成できます。たとえば、オペレーターは、その論文で呼び出された仮定に疑問を投げかけたいと思うかもしれません。たとえば、大部分の単一フロー転送のために過小評価されていないという目標（多くの大規模な転送が複数のフローを使用して、古典的なフローのスケーリング制限を回避するため）。
The two 'gain factors' in line 3 of Figure 6, alpha and beta, respectively weight how strongly each of the two elements (Integral and Proportional) alters p'. They are in units of 'per second of delay' or Hz, because they transform differences in queuing delay into changes in probability (assuming probability has a value from 0 to 1).
図6の3行目の2つの「ゲイン因子」、アルファとベータは、それぞれ2つの要素（積分および比例）のそれぞれがP 'をどれだけ強く変化させるかを重み付けしています。それらは、「遅延の1秒あたり」またはHzの単位にあります。これは、キューイング遅延の差を確率の変化に変換するためです（確率が0から1までの値があると仮定します）。
Alpha and beta determine how much p' ought to change after each update interval (Tupdate). For a smaller Tupdate, p' should change by the same amount per second but in finer more frequent steps. So alpha depends on Tupdate (see line 13 of the initialization function in Figure 2). It is best to update p' as frequently as possible, but Tupdate will probably be constrained by hardware performance. As shown in line 12, the update interval should be frequent enough to update at least once in the time taken for the target queue to drain ('target') as long as it updates at least three times per maximum RTT. Tupdate defaults to 16 ms in the reference Linux implementation because it has to be rounded to a multiple of 4 ms. For link rates from 4 to 200 Mb/s and a maximum RTT of 100 ms, it has been verified through extensive testing that Tupdate = 16 ms (as also recommended in the PIE spec [RFC8033]) is sufficient.
アルファとベータは、各更新間隔（tupdate）の後にP 'がどれだけ変化するべきかを決定します。小さいtupdateの場合、p 'は1秒あたり同じ量だけでなく、より頻繁なステップで変更する必要があります。したがって、アルファはTupdateに依存します（図2の初期化関数の13行目を参照）。P 'をできるだけ頻繁に更新することをお勧めしますが、Tupdateはおそらくハードウェアのパフォーマンスによって制約されます。12行目に示すように、更新間隔は、最大RTTごとに少なくとも3回更新する限り、ターゲットキュー（「ターゲット」）を排出するためにかかった時間に少なくとも1回更新するのに十分な頻度である必要があります。Tupdateは、4ミリ倍の倍数に丸められる必要があるため、参照Linux実装で16ミリ秒のデフォルトです。4〜200 MB/sおよび最大RTT 100 msのリンクレートの場合、Tupdate = 16 ms（PIE仕様[RFC8033]でも推奨されているように）が十分であることを広範なテストで検証しています。
The choice of alpha and beta also determines the AQM's stable operating range. The AQM ought to change p' as fast as possible in response to changes in load without overcompensating and therefore causing oscillations in the queue. Therefore, the values of alpha and beta also depend on the RTT of the expected worst-case flow (RTT_max).
アルファとベータの選択は、AQMの安定した動作範囲も決定します。AQMは、過補償なしで負荷の変化に応じてP 'をできるだけ早く変更する必要があり、したがって、キューに振動を引き起こす必要があります。したがって、アルファとベータの値は、予想される最悪の流れ（RTT_MAX）のRTTにも依存します。
The maximum RTT of a PI controller (RTT_max in line 9 of Figure 2) is not an absolute maximum, but more instability (more queue variability) sets in for long-running flows with an RTT above this value. The propagation delay halfway round the planet and back in glass fibre is 200 ms. However, hardly any traffic traverses such extreme paths and, since the significant consolidation of Internet traffic between 2007 and 2009 [Labovitz10], a high and growing proportion of all Internet traffic (roughly two-thirds at the time of writing) has been served from CDNs or 'cloud' services distributed close to end users. The Internet might change again, but for now, designing for a maximum RTT of 100 ms is a good compromise between faster queue control at low RTT and some instability on the occasions when a longer path is necessary.
PIコントローラーの最大RTT（図2の行9のRTT_MAX）は絶対的な最大値ではありませんが、この値を上回るRTTを使用して、長期にわたるフローの不安定性（より多くのキューの変動性）が設定されます。伝播遅延は、惑星の途中でガラス繊維の途中で遅れます。ただし、トラフィックがこのような極端な経路を移動することはほとんどなく、2007年から2009年の間にインターネットトラフィックが大幅に統合されて以来[Labovitz10]、すべてのインターネットトラフィックの割合が高く（執筆時点で約3分の2）提供されています。エンドユーザーの近くで配布されたCDNまたは「クラウド」サービス。インターネットは再び変化する可能性がありますが、今のところ、100ミリ秒の最大RTTを設計することは、低いRTTでのより速いキュー制御と、より長いパスが必要な場合に何らかの不安定性との間の良い妥協点です。
Recommended derivations of the gain constants alpha and beta can be approximated for Reno over a PI2 AQM as: alpha = 0.1 * Tupdate / RTT_max^2; beta = 0.3 / RTT_max, as shown in lines 13 and 14 of Figure 2. These are derived from the stability analysis in [PI2]. For the default values of Tupdate = 16 ms and RTT_max = 100 ms, they result in alpha = 0.16; beta = 3.2 (discrepancies are due to rounding). These defaults have been verified with a wide range of link rates, target delays, and traffic models with mixed and similar RTTs, short and long flows, etc.
ゲイン定数の推奨派生由来アルファおよびベータは、alpha = 0.1 * tupdate / rtt_max^2;図2の13行目と14に示すように、ベータ= 0.3 / RTT_MAXは、[PI2]の安定性分析に由来します。tupdateのデフォルト値= 16 msおよびrtt_max = 100 msの場合、alpha = 0.16になります。ベータ= 3.2（矛盾は丸めによるものです）。これらのデフォルトは、さまざまなリンクレート、ターゲット遅延、および混合および類似のRTT、短いフローと長いフローなどのトラフィックモデルで検証されています。
In corner cases, p' can overflow the range [0,1] so the resulting value of p' has to be bounded (omitted from the pseudocode). Then, as already explained, the coupled and Classic probabilities are derived from the new p' in lines 4 and 5 of Figure 6 as p_CL = k*p' and p_C = p'^2.
コーナーの場合、p 'は範囲[0,1]にオーバーフローする可能性があるため、結果の値の値を境界線にする必要があります（擬似コードから省略）。次に、すでに説明したように、結合された確率と古典的な確率は、図6の新しいp 'からp_cl = k*p'およびp_c = p '^2として導き出されます。
Because the coupled L4S marking probability (p_CL) is factored up by k, the dynamic gain parameters alpha and beta are also inherently factored up by k for the L4S queue. So, the effective gain factor for the L4S queue is k*alpha (with defaults alpha = 0.16 Hz and k = 2, effective L4S alpha = 0.32 Hz).
結合されたL4Sマーキング確率（P_CL）はKによって因数分解されるため、動的ゲインパラメーターアルファとベータも、L4SキューのKによって本質的に因数分解されます。したがって、L4Sキューの有効ゲイン係数はK*アルファです（デフォルトのアルファ= 0.16 Hzおよびk = 2、有効L4Sアルファ= 0.32 Hz）。
Unlike in PIE [RFC8033], alpha and beta do not need to be tuned every Tupdate dependent on p'. Instead, in PI2, alpha and beta are independent of p' because the squaring applied to Classic traffic tunes them inherently. This is explained in [PI2], which also explains why this more principled approach removes the need for most of the heuristics that had to be added to PIE.
PIE [RFC8033]とは異なり、アルファとベータは、p 'に依存するすべてのtupdateを調整する必要はありません。代わりに、PI2では、AlphaとBetaはP 'とは無関係です。これは[PI2]で説明されています。これは、この原則的なアプローチが、PIEに追加する必要があるヒューリスティックのほとんどの必要性を削除する理由も説明しています。
Nonetheless, an implementer might wish to add selected details to either AQM. For instance, the Linux reference DualPI2 implementation includes the following (not shown in the pseudocode above):
それにもかかわらず、実装者は、選択した詳細をAQMに追加することをお勧めします。たとえば、Linux参照Dualpi2実装には、以下が含まれます（上記のPseudocodeには示されていません）：
* Classic and coupled marking or dropping (i.e., based on p_C and p_CL from the PI controller) is not applied to a packet if the aggregate queue length in bytes is < 2 MTU (prior to enqueuing the packet or dequeuing it, depending on whether the AQM is configured to be applied at enqueue or dequeue); and
* クラシックで結合したマーキングまたはドロップ（つまり、PIコントローラーからのP_CおよびP_CLに基づいて）は、バイトの凝集キュー長が2 MTU未満の場合、パケットに適用されません（パケットをエンキューする前、またはそれを除去する前に、AQMは、enqueueまたはdequeueで適用されるように構成されています）;と
* in the WRR scheduler, the 'credit' indicating which queue should transmit is only changed if there are packets in both queues (i.e., if there is actual resource contention). This means that a properly paced L flow might never be delayed by the WRR. The WRR credit is reset in favour of the L queue when the link is idle.
* WRRスケジューラでは、両方のキューにパケットがある場合にのみ、どのキューが送信されるべきかを示す「クレジット」が変更されます（つまり、実際のリソース競合がある場合）。これは、適切にペースのLフローがWRRによって遅れることがない可能性があることを意味します。WRRクレジットは、リンクがアイドル状態にあるときにLキューを支持してリセットされます。
An implementer might also wish to add other heuristics, e.g., burst protection [RFC8033] or enhanced burst protection [RFC8034].
実装者は、他のヒューリスティック、例えばバースト保護[RFC8033]またはバースト保護の強化[RFC8034]を追加することも望む場合があります。
Notes:
ノート：
a. The drain rate of the queue can vary if it is scheduled relative to other queues or if it accommodates fluctuations in a wireless medium. To auto-adjust to changes in drain rate, the queue needs to be measured in time, not bytes or packets [AQMmetrics] [CoDel]. Queuing delay could be measured directly as the sojourn time (a.k.a. service time) of the queue by storing a per-packet timestamp as each packet is enqueued and subtracting it from the system time when the packet is dequeued. If timestamping is not easy to introduce with certain hardware, queuing delay could be predicted indirectly by dividing the size of the queue by the predicted departure rate, which might be known precisely for some link technologies (see, for example, DOCSIS PIE [RFC8034]).
a. キューの排水率は、他のキューと比較してスケジュールされている場合、またはワイヤレス媒体の変動に対応する場合に異なります。排水速度の変化を自動調整するには、キューを時間内に測定する必要があり、バイトまたはパケット[aqmmetrics] [Codel]ではなく測定する必要があります。キューイングの遅延は、各パケットが囲まれているため、パケットごとのタイムスタンプを保存し、パケットがデケートされたときにシステム時間からそれを減算するため、キューの滞在時間（別名サービス時間）として直接測定できます。タイムスタンプを特定のハードウェアで導入するのは簡単ではない場合、キューのサイズを予測される出発率で割ることにより、キューイングの遅延を間接的に予測できます。）。
However, sojourn time is slow to detect bursts. For instance, if a burst arrives at an empty queue, the sojourn time only fully measures the burst's delay when its last packet is dequeued, even though the queue has known the size of the burst since its last packet was enqueued -- so it could have signalled congestion earlier. To remedy this, each head packet can be marked when it is dequeued based on the expected delay of the tail packet behind it, as explained below, rather than based on the head packet's own delay due to the packets in front of it. "Underutilization with Bursty Traffic" in [Heist21] identifies a specific scenario where bursty traffic significantly hits utilization of the L queue. If this effect proves to be more widely applicable, using the delay behind the head could improve performance.
ただし、バーストを検出するには滞在時間が遅くなります。たとえば、バーストが空のキューに到着した場合、最後のパケットがエンケートされてからのバーストのサイズを知っているにもかかわらず、滞在時間は最後のパケットがデケートされている場合にバーストの遅延を完全に測定するだけです。以前に混雑を合図しました。これを改善するために、各ヘッドパケットは、その前のパケットによるヘッドパケット自身の遅延に基づいているのではなく、以下のテールパケットの予想される遅延に基づいてデキューされている場合にマークできます。[Heist21]の「Bursty Trafficの不足」は、爆発的なトラフィックがLキューの利用に大幅にヒットする特定のシナリオを特定します。この効果がより広く適用可能であることが判明した場合、頭の後ろの遅延を使用するとパフォーマンスが向上する可能性があります。
The delay behind the head can be implemented by dividing the backlog at dequeue by the link rate or equivalently multiplying the backlog by the delay per unit of backlog. The implementation details will depend on whether the link rate is known; if it is not, a moving average of the delay per unit backlog can be maintained. This delay consists of serialization as well as media acquisition for shared media. So the details will depend strongly on the specific link technology. This approach should be less sensitive to timing errors and cost less in operations and memory than the otherwise equivalent 'scaled sojourn time' metric, which is the sojourn time of a packet scaled by the ratio of the queue sizes when the packet departed and arrived [SigQ-Dyn].
ヘッドの後ろの遅延は、Dequeueのバックログをリンクレートで除算するか、バックログの単位あたりの遅延をバックログに同等に掛けることで実装できます。実装の詳細は、リンクレートがわかっているかどうかによって異なります。そうでない場合、ユニットバックログあたりの遅延の移動平均を維持できます。この遅延は、シリアル化と共有メディアのメディアの獲得で構成されています。そのため、詳細は特定のリンクテクノロジーに強く依存します。このアプローチは、タイミングエラーに対する敏感ではなく、操作とメモリのコストが低く、それ以外の場合は同等の「スケーリングされた滞在時間」メトリックよりも、パケットが出発して到着したときのキューサイズの比率によってスケーリングされたパケットの滞在時間です[sigq-dyn]。
b. Line 2 of the dualpi2_enqueue() function (Figure 3) assumes an implementation where lq and cq share common buffer memory. An alternative implementation could use separate buffers for each queue, in which case the arriving packet would have to be classified first to determine which buffer to check for available space. The choice is a trade-off; a shared buffer can use less memory whereas separate buffers isolate the L4S queue from tail drop due to large bursts of Classic traffic (e.g., a Classic Reno TCP during slow-start over a long RTT).
b. dualpi2_enqueue（）関数（図3）の行2は、LQとCQが共通バッファメモリを共有する実装を想定しています。代替の実装では、各キューに個別のバッファーを使用できます。この場合、到着するパケットを最初に分類して、利用可能なスペースをチェックするバッファーを決定する必要があります。選択はトレードオフです。共有バッファーはより少ないメモリを使用できますが、個別のバッファーは、古典的なトラフィックの大きなバースト（例えば、長いRTTでのスロースタート中の古典的なリノTCPなど）のためにテールドロップからL4Sキューを分離します。
c. There has been some concern that using the step function of DCTCP for the Native L4S AQM requires end systems to smooth the signal for an unnecessarily large number of round trips to ensure sufficient fidelity. A ramp is no worse than a step in initial experiments with existing DCTCP. Therefore, it is recommended that a ramp is configured in place of a step, which will allow congestion control algorithms to investigate faster smoothing algorithms.
c. ネイティブL4S AQMにDCTCPのステップ関数を使用するには、十分な忠実度を確保するために不必要に多数の往復の信号を滑らかにするためにエンドシステムが必要であるという懸念がありました。ランプは、既存のDCTCPを使用した最初の実験のステップよりも悪くありません。したがって、ランプをステップの代わりに構成することをお勧めします。これにより、うっ血制御アルゴリズムがより高速なスムージングアルゴリズムを調査できるようになります。
A ramp is more general than a step, because an operator can effectively turn the ramp into a step function, as used by DCTCP, by setting the range to zero. There will not be a divide by zero problem at line 5 of Figure 5 because, if minTh is equal to maxTh, the condition for this ramp calculation cannot arise.
ランプはステップよりも一般的です。これは、オペレーターが範囲をゼロに設定することにより、DCTCPが使用するように、ランプを効果的にステップ関数に変えることができるためです。MinthがMaxthに等しい場合、このランプの計算の条件が発生しないため、図5の5行目でゼロ問題による分割はありません。
This section takes a second pass through the pseudocode to add details of two edge-cases: low link rate and overload. Figure 7 repeats the dequeue function of Figure 4, but with details of both edge-cases added. Similarly, Figure 8 repeats the core PI algorithm of Figure 6, but with overload details added. The initialization, enqueue, L4S AQM, and recur functions are unchanged.
このセクションでは、Pseudocodeを通過する2回目のパスを使用して、2つのエッジケースの詳細を追加します。リンクレートと過負荷が低くなります。図7は、図4のdequeue関数を繰り返しますが、両方のエッジケースの詳細が追加されています。同様に、図8は図6のコアPIアルゴリズムを繰り返しますが、過負荷の詳細が追加されています。初期化、Enqueue、L4S AQM、およびRecur関数は変更されていません。
The link rate can be so low that it takes a single packet queue longer to serialize than the threshold delay at which ECN marking starts to be applied in the L queue. Therefore, a minimum marking threshold parameter in units of packets rather than time is necessary (Th_len, default 1 packet in line 19 of Figure 2) to ensure that the ramp does not trigger excessive marking on slow links. Where an implementation knows the link rate, it can set up this minimum at the time it is configured. For instance, it would divide 1 MTU by the link rate to convert it into a serialization time, then if the lower threshold of the Native L AQM ramp was lower than this serialization time, it could increase the thresholds to shift the bottom of the ramp to 2 MTU. This is the approach used in DOCSIS [DOCSIS3.1], because the configured link rate is dedicated to the DualQ.
リンクレートは非常に低い可能性があるため、単一のパケットキューは、lキューでECNマーキングが適用され始めたしきい値遅延よりもシリアル化に時間がかかります。したがって、ランプが遅いリンクで過度のマーキングをトリガーしないようにするために、時間ではなくパケット単位の単位単位の最小マーキングしきい値パラメーターが必要です（図2の19行目のデフォルト1パケット）。実装がリンクレートを知っている場合、構成されている時点でこの最小限を設定できます。たとえば、1 MTUをリンクレートで除算してシリアル化時間に変換し、ネイティブL AQMランプの低いしきい値がこのシリアル化時間よりも低い場合、しきい値を増加させてランプの底をシフトする可能性があります。2 mtuに。これは、構成されたリンクレートがデュアルク専用であるため、docsis [docsis3.1]で使用されるアプローチです。
The pseudocode given here applies where the link rate is unknown, which is more common for software implementations that might be deployed in scenarios where the link is shared with other queues. In lines 5a to 5d in Figure 7, the native L4S marking probability, p'_L, is zeroed if the queue is only 1 packet (in the default configuration).
ここで示されている擬似コードは、リンクレートが不明な場合に適用されます。これは、リンクが他のキューと共有されるシナリオに展開される可能性のあるソフトウェアの実装でより一般的です。図7の行5Aから5Dでは、キューが1つのパケット（デフォルト構成）のみである場合、ネイティブL4Sマーキング確率P'_Lがゼロになります。
Linux implementation note: In Linux, the check that the queue exceeds Th_len before marking with the Native L4S AQM is actually at enqueue, not dequeue; otherwise, it would exempt the last packet of a burst from being marked. The result of the check is conveyed from enqueue to the dequeue function via a boolean in the packet metadata.
Linuxの実装注：Linuxでは、キューがTh_lenを超えることを確認してから、ネイティブL4S AQMとマークする前に、実際にはDequeueではなくEnqueueにあります。それ以外の場合、バーストの最後のパケットがマークされないように免除されます。チェックの結果は、パケットメタデータのブール値を介してエンキューからデキュー関数に伝えられます。
Persistent overload is deemed to have occurred when Classic drop/ marking probability reaches p_Cmax. Above this point, the Classic drop probability is applied to both the L and C queues, irrespective of whether any packet is ECN-capable. ECT packets that are not dropped can still be ECN-marked.
永続的な過負荷は、古典的なドロップ/マーキング確率がP_CMAXに達すると発生したとみなされます。この点を超えると、パケットがECN対応かどうかに関係なく、古典的なドロップ確率がLとCキューの両方に適用されます。ドロップされていないECTパケットは、eCNマーク化できます。
In line 11 of the initialization function (Figure 2), the maximum Classic drop probability p_Cmax = min(1/k^2, 1) or 1/4 for the default coupling factor k = 2. In practice, 25% has been found to be a good threshold to preserve fairness between ECN-capable and non-ECN-capable traffic. This protects the queues against both temporary overload from responsive flows and more persistent overload from any unresponsive traffic that falsely claims to be responsive to ECN.
初期化関数の11行目（図2）では、デフォルトの結合係数k = 2の最大クラシックドロップ確率p_cmax = min（1/k^2、1）または1/4で、25％が見つかりました。ECN対応と非ECN対応トラフィックの間の公平性を維持するための優れたしきい値になること。これにより、応答性のあるフローからの一時的な過負荷と、ECNに反応すると誤って主張する無反応のトラフィックからのより永続的な過負荷の両方からキューが保護されます。
When the Classic ECN-marking probability reaches the p_Cmax threshold (1/k^2), the marking probability that is coupled to the L4S queue, p_CL, will always be 100% for any k (by equation (1) in Section 2.1). So, for readability, the constant p_Lmax is defined as 1 in line 21 of the initialization function (Figure 2). This is intended to ensure that the L4S queue starts to introduce dropping once ECN marking saturates at 100% and can rise no further. The 'Prague L4S requirements' [RFC9331] state that when an L4S congestion control detects a drop, it falls back to a response that coexists with 'Classic' Reno congestion control. So, it is correct that when the L4S queue drops packets, it drops them proportional to p'^2, as if they are Classic packets.
古典的なECNマーク確率がP_CMAXしきい値（1/k^2）に達すると、L4Sキューに結合されるマーキング確率P_CLは、常にKの場合は100％になります（セクション2.1の方程式（1）により）。したがって、読みやすさのために、定数p_lmaxは初期化関数の21行の1として定義されます（図2）。これは、ECNマークが100％で飽和し、それ以上上昇することができなくなると、L4Sキューがドロップの導入を開始するようにすることを目的としています。「プラハL4S要件」[RFC9331]は、L4S輻輳制御がドロップを検出すると、「クラシック」リノ輻輳制御と共存する応答に戻ると述べています。したがって、L4Sキューがパケットをドロップすると、まるでそれらが古典的なパケットであるかのようにP '^2に比例してドロップするのは正しいことです。
The two queues each test for overload in lines 4b and 12b of the dequeue function (Figure 7). Lines 8c to 8g drop L4S packets with probability p'^2. Lines 8h to 8i mark the remaining packets with probability p_CL. Given p_Lmax = 1, all remaining packets will be marked because, to have reached the else block at line 8b, p_CL >= 1.
Dequeue関数の4Bと12Bの過負荷の各テストの2つのキュー（図7）。ライン8c〜8gは、確率p '^2でL4Sパケットをドロップします。行8から8iは、残りのパケットを確率p_clでマークします。p_lmax = 1を考えると、残りのすべてのパケットがマークされます。
Line 2a in the core PI algorithm (Figure 8) deals with overload of the L4S queue when there is little or no Classic traffic. This is necessary, because the core PI algorithm maintains the appropriate drop probability to regulate overload, but it depends on the length of the Classic queue. If there is little or no Classic queue, the naive PI-update function (Figure 6) would drop nothing, even if the L4S queue were overloaded -- so tail drop would have to take over (lines 2 and 3 of Figure 3).
コアPIアルゴリズム（図8）の行2Aは、古典的なトラフィックがほとんどまたはまったくない場合にL4Sキューの過負荷を扱います。これは、コアPIアルゴリズムが過負荷を調節するための適切なドロップ確率を維持するため、必要ですが、クラシックキューの長さに依存します。古典的なキューがほとんどまたはまったくない場合、L4Sキューが過負荷になっていても、素朴なPI-Update関数（図6）は何もドロップしません。
Instead, line 2a of the full PI-update function (Figure 8) ensures that the Base PI AQM in line 3 is driven by whichever of the two queue delays is greater, but line 3 still always uses the same Classic target (default 15 ms). If L queue delay is greater just because there is little or no Classic traffic, normally it will still be well below the Base AQM target. This is because L4S traffic is also governed by the shallow threshold of its own Native AQM (lines 5a to 6 of the dequeue algorithm in Figure 7). So the Base AQM will be driven to zero and not contribute. However, if the L queue is overloaded by traffic that is unresponsive to its marking, the max() in line 2a of Figure 8 enables the L queue to smoothly take over driving the Base AQM into overload mode even if there is little or no Classic traffic. Then the Base AQM will keep the L queue to the Classic target (default 15 ms) by shedding L packets.
代わりに、完全なPi-Update関数（図8）の行2aは、3行目のベースPI AQMが2つのキューの遅延のどれが大きくなるかによって駆動されることを保証しますが、行3は常に同じ古典的なターゲットを使用します（デフォルト15ミリ秒を使用します）。Lキューの遅延が古典的なトラフィックがほとんどまたはまったくないという理由だけで大きい場合、通常はベースAQMターゲットをはるかに下回ります。これは、L4Sトラフィックが独自のネイティブAQMの浅いしきい値によっても支配されているためです（図7のDequeueアルゴリズムの5A〜6行目）。したがって、ベースAQMはゼロに駆動され、貢献しません。ただし、Lキューがマーキングに反応しないトラフィックによって過負荷になっている場合、図8の行2Aのmax（）は、クラシックがほとんどまたはまったくない場合でも、lキューがベースAQMを過負荷モードに走らせることができます。トラフィック。次に、ベースAQMは、Lパケットを削減することにより、Lキューをクラシックターゲット（デフォルト15ミリ秒）に保ちます。
1: dualpi2_dequeue(lq, cq, pkt) { % Couples L4S & Classic queues
2: while ( lq.byt() + cq.byt() > 0 ) {
3: if ( scheduler() == lq ) {
4a: lq.dequeue(pkt) % L4S scheduled
4b: if ( p_CL < p_Lmax ) { % Check for overload saturation
5a: if (lq.len()>Th_len) % >1 packet queued
5b: p'_L = laqm(lq.time()) % Native LAQM
5c: else
5d: p'_L = 0 % Suppress marking 1 pkt queue
6: p_L = max(p'_L, p_CL) % Combining function
7: if ( recur(lq, p_L) %Linear marking
8a: mark(pkt)
8b: } else { % overload saturation
8c: if ( recur(lq, p_C) ) { % probability p_C = p'^2
8e: drop(pkt) % revert to Classic drop due to overload
8f: continue % continue to the top of the while loop
8g: }
8h: if ( recur(lq, p_CL) ) % probability p_CL = k * p'
8i: mark(pkt) % linear marking of remaining packets
8j: }
9: } else {
10: cq.dequeue(pkt) % Classic scheduled
11: if ( recur(cq, p_C) ) { % probability p_C = p'^2
12a: if ( (ecn(pkt) == 0) % ECN field = not-ECT
12b: OR (p_C >= p_Cmax) ) { % Overload disables ECN
13: drop(pkt) % squared drop, redo loop
14: continue % continue to the top of the while loop
15: }
16: mark(pkt) % squared mark
17: }
18: }
19: return(pkt) % return the packet and stop
20: }
21: return(NULL) % no packet to dequeue
22: }
Figure 7: Example Dequeue Pseudocode for DualQ Coupled PI2 AQM (Including Code for Edge-Cases)
図7：DualQ結合PI2 AQMのDequeue Pseudocodeの例（エッジケースのコードを含む）
1: dualpi2_update(lq, cq) { % Update p' every Tupdate
2a: curq = max(cq.time(), lq.time()) % use greatest queuing time
3: p' = p' + alpha * (curq - target) + beta * (curq - prevq)
4: p_CL = p' * k % Coupled L4S prob = base prob * coupling factor
5: p_C = p'^2 % Classic prob = (base prob)^2
6: prevq = curq
7: }
Figure 8: Example PI-update Pseudocode for DualQ Coupled PI2 AQM (Including Overload Code)
図8：DualQ結合PI2 AQMのPi-Up-update Pseudocodeの例（過負荷コードを含む）
The choice of scheduler technology is critical to overload protection (see Section 4.2.2).
スケジューラテクノロジーの選択は、保護を過負荷にするために重要です（セクション4.2.2を参照）。
* A well-understood weighted scheduler such as WRR is recommended. As long as the scheduler weight for Classic is small (e.g., 1/16), its exact value is unimportant, because it does not normally determine capacity shares. The weight is only important to prevent unresponsive L4S traffic starving Classic traffic in the short term (see Section 4.2.2). This is because capacity sharing between the queues is normally determined by the coupled congestion signal, which overrides the scheduler, by making L4S sources leave roughly equal per-flow capacity available for Classic flows.
* WRRなどのよく理解されている加重スケジューラをお勧めします。クラシックのスケジューラ重量が小さい限り（例：1/16）、通常は容量株を決定しないため、その正確な値は重要ではありません。重量は、短期的には無反応のL4Sトラフィックに飢えた古典的なトラフィックを防ぐためにのみ重要です（セクション4.2.2を参照）。これは、キュー間の容量の共有が通常、スケジューラをオーバーライドする結合輻輳信号によって決定されるためです。L4Sソースがクラシックフローで利用可能なフローごとの容量をほぼ等しく残すことにより。
* Alternatively, a time-shifted FIFO (TS-FIFO) could be used. It works by selecting the head packet that has waited the longest, biased against the Classic traffic by a time-shift of tshift. To implement TS-FIFO, the scheduler() function in line 3 of the dequeue code would simply be implemented as the scheduler() function at the bottom of Figure 10 in Appendix B. For the public Internet, a good value for tshift is 50 ms. For private networks with smaller diameter, about 4*target would be reasonable. TS-FIFO is a very simple scheduler, but complexity might need to be added to address some deficiencies (which is why it is not recommended over WRR):
* あるいは、タイムシフトFIFO（TS-FIFO）を使用できます。これは、Tshiftのタイムシフトによって古典的なトラフィックに偏っている、最も長く待っていたヘッドパケットを選択することで機能します。TS-FIFOを実装するには、Dequeueコードの3行目のスケジューラ（）関数は、付録Bの図10の下部にあるスケジューラ（）関数として単純に実装されます。MS。直径が小さいプライベートネットワークの場合、約4*ターゲットが妥当です。TS-FIFOは非常にシンプルなスケジューラですが、いくつかの欠陥に対処するために複雑さを追加する必要がある場合があります（そのため、WRRよりも推奨されません）：
- TS-FIFO does not fully isolate latency in the L4S queue from uncontrolled bursts in the Classic queue;
- TS-FIFOは、古典的なキューの制御されていないバーストからのL4Sキューのレイテンシを完全に分離しません。
- using sojourn time for TS-FIFO is only appropriate if timestamping of packets is feasible; and
- TS-FIFOに滞在時間を使用することは、パケットのタイムスタンプが実行可能である場合にのみ適切です。と
- even if timestamping is supported, the sojourn time of the head packet is always stale, so a more instantaneous measure of queue delay could be used (see Note a in Appendix A.1).
- タイムスタンプがサポートされていても、ヘッドパケットの滞在時間は常に古くなっているため、キュー遅延のより瞬時の測定値を使用できます（付録A.1の注Aを参照）。
* A strict priority scheduler would be inappropriate as discussed in Section 4.2.2.
* セクション4.2.2で説明したように、厳格な優先度スケジューラは不適切です。
As another example of a DualQ Coupled AQM algorithm, the pseudocode below gives the Curvy-RED-based algorithm. Although the AQM was designed to be efficient in integer arithmetic, to aid understanding it is first given using floating point arithmetic (Figure 10). Then, one possible optimization for integer arithmetic is given, also in pseudocode (Figure 11). To aid comparison, the line numbers are kept in step between the two by using letter suffixes where the longer code needs extra lines.
DualQ結合AQMアルゴリズムの別の例として、以下の擬似コードは曲線赤ベースのアルゴリズムを示します。AQMは整数算術に効率的になるように設計されていますが、それを理解するのを助けるために、最初に浮動小数点算術を使用して与えられます（図10）。次に、擬似コードでも、整数算術の可能な最適化が1つ与えられます（図11）。比較を支援するために、より長いコードに追加の行が必要な文字接尾辞を使用することにより、2つの間のライン番号がステップに保たれます。
The pseudocode manipulates three main structures of variables: the packet (pkt), the L4S queue (lq), and the Classic queue (cq). It is defined and described below in the following three functions:
擬似コードは、変数の3つの主要な構造を操作します：パケット（PKT）、L4Sキュー（LQ）、およびクラシックキュー（CQ）。次の3つの関数で以下に定義および説明されています。
* the initialization function cred_params_init(...) (Figure 2) that sets parameter defaults (the API for setting non-default values is omitted for brevity);
* パラメーターのデフォルトを設定する初期化関数CRED_PARAMS_INIT（...）（図2）（非デフォルト値の設定のAPIは、簡潔にするために省略されています）。
* the dequeue function cred_dequeue(lq, cq, pkt) (Figure 4); and
* dequeue関数chred_dequeue（lq、cq、pkt）（図4）;と
* the scheduling function scheduler(), which selects between the head packets of the two queues.
* 2つのキューのヘッドパケット間で選択するスケジューリング関数スケジューラ（）。
It also uses the following functions that are either shown elsewhere or not shown in full here:
また、他の場所に表示されるか、ここに完全に表示されない以下の機能も使用します。
* the enqueue function, which is identical to that used for DualPI2, dualpi2_enqueue(lq, cq, pkt) in Figure 3;
* 図3のdualpi2、dualpi2_enqueue（lq、cq、pkt）に使用されるエンキュー関数。
* mark(pkt) and drop(pkt) for ECN marking and dropping a packet;
* ECNマークとドロップのマーク（PKT）およびドロップ（PKT）。
* cq.byt() or lq.byt() returns the current length (a.k.a. backlog) of the relevant queue in bytes; and
* cq.byt（）またはlq.byt（）は、関連するキューの現在の長さ（a.k.a.バックログ）をバイトで返します。と
* cq.time() or lq.time() returns the current queuing delay of the relevant queue in units of time (see Note a in Appendix A.1).
* CQ.Time（）またはLQ.Time（）は、時間単位の関連するキューの現在のキューイング遅延を返します（付録A.1の注Aを参照）。
Because Curvy RED was evaluated before DualPI2, certain improvements introduced for DualPI2 were not evaluated for Curvy RED. In the pseudocode below, the straightforward improvements have been added on the assumption they will provide similar benefits, but that has not been proven experimentally. They are: i) a conditional priority scheduler instead of strict priority; ii) a time-based threshold for the Native L4S AQM; and iii) ECN support for the Classic AQM. A recent evaluation has proved that a minimum ECN-marking threshold (minTh) greatly improves performance, so this is also included in the pseudocode.
Dualpi2の前に曲線赤が評価されたため、Dualpi2に導入された特定の改善は曲線レッドについて評価されませんでした。以下の擬似コードでは、同様の利点が提供されると仮定して、簡単な改善が追加されていますが、実験的に証明されていません。それらは次のとおりです。i）厳格な優先度ではなく条件付き優先スケジューラ。ii）ネイティブL4S AQMの時間ベースのしきい値。およびiii）古典的なAQMのECNサポート。最近の評価により、最小ECNマークのしきい値（MINTH）がパフォーマンスを大幅に改善することが証明されているため、これは擬似コードにも含まれています。
Overload protection has not been added to the Curvy RED pseudocode below so as not to detract from the main features. It would be added in exactly the same way as in Appendix A.2 for the DualPI2 pseudocode. The Native L4S AQM uses a step threshold, but a ramp like that described for DualPI2 could be used instead. The scheduler uses the simple TS-FIFO algorithm, but it could be replaced with WRR.
主要な機能を損なわないように、以下の曲線の赤い擬似コードに過負荷保護が追加されていません。Dualpi2 Pseudocodeの付録A.2とまったく同じ方法で追加されます。ネイティブL4S AQMはステップしきい値を使用しますが、代わりにDualPi2について説明したようなランプを使用できます。スケジューラは単純なTS-FIFOアルゴリズムを使用しますが、WRRに置き換えることができます。
The Curvy RED algorithm has not been maintained or evaluated to the same degree as the DualPI2 algorithm. In initial experiments on broadband access links ranging from 4 Mb/s to 200 Mb/s with base RTTs from 5 ms to 100 ms, Curvy RED achieved good results with the default parameters in Figure 9.
曲線の赤いアルゴリズムは、dualpi2アルゴリズムと同じ程度まで維持または評価されていません。4 MB/sから200 MB/sの範囲のブロードバンドアクセスリンクに関する最初の実験では、5ミリ秒から100ミリ秒のベースRTTを含む、曲線レッドは図9のデフォルトパラメーターで良い結果を達成しました。
The parameters are categorized by whether they relate to the Classic AQM, the L4S AQM, or the framework coupling them together. Constants and variables derived from these parameters are also included at the end of each category. These are the raw input parameters for the algorithm. A configuration front-end could accept more meaningful parameters (e.g., RTT_max and RTT_typ) and convert them into these raw parameters, as has been done for DualPI2 in Appendix A. Where necessary, parameters are explained further in the walk-through of the pseudocode below.
パラメーターは、クラシックAQM、L4S AQM、またはそれらを結合するフレームワークに関連するかどうかによって分類されます。これらのパラメーターから派生した定数と変数は、各カテゴリの最後にも含まれています。これらは、アルゴリズムの生の入力パラメーターです。構成フロントエンドは、より意味のあるパラメーター（rtt_maxやrtt_typなど）を受け入れ、付録Aのdualpi2について行われたように、これらの生のパラメーターに変換できます。下。
1: cred_params_init(...) { % Set input parameter defaults
2: % DualQ Coupled framework parameters
3: limit = MAX_LINK_RATE * 250 ms % Dual buffer size
4: k' = 1 % Coupling factor as a power of 2
5: tshift = 50 ms % Time-shift of TS-FIFO scheduler
6: % Constants derived from Classic AQM parameters
7: k = 2^k' % Coupling factor from equation (1)
6:
7: % Classic AQM parameters
8: g_C = 5 % EWMA smoothing parameter as a power of 1/2
9: S_C = -1 % Classic ramp scaling factor as a power of 2
10: minTh = 500 ms % No Classic drop/mark below this queue delay
11: % Constants derived from Classic AQM parameters
12: gamma = 2^(-g_C) % EWMA smoothing parameter
13: range_C = 2^S_C % Range of Classic ramp
14:
15: % L4S AQM parameters
16: T = 1 ms % Queue delay threshold for Native L4S AQM
17: % Constants derived from above parameters
18: S_L = S_C - k' % L4S ramp scaling factor as a power of 2
19: range_L = 2^S_L % Range of L4S ramp
20: }
Figure 9: Example Header Pseudocode for DualQ Coupled Curvy RED AQM
図9：デュアルクカップルの曲線レッドAQMのヘッダー擬似コードの例
1: cred_dequeue(lq, cq, pkt) { % Couples L4S & Classic queues
2: while ( lq.byt() + cq.byt() > 0 ) {
3: if ( scheduler() == lq ) {
4: lq.dequeue(pkt) % L4S scheduled
5a: p_CL = (Q_C - minTh) / range_L
5b: if ( ( lq.time() > T )
5c: OR ( p_CL > maxrand(U) ) )
6: mark(pkt)
7: } else {
8: cq.dequeue(pkt) % Classic scheduled
9a: Q_C = gamma * cq.time() + (1-gamma) * Q_C % Classic Q EWMA
10a: sqrt_p_C = (Q_C - minTh) / range_C
10b: if ( sqrt_p_C > maxrand(2*U) ) {
11: if ( (ecn(pkt) == 0) { % ECN field = not-ECT
12: drop(pkt) % Squared drop, redo loop
13: continue % continue to the top of the while loop
14: }
15: mark(pkt)
16: }
17: }
18: return(pkt) % return the packet and stop here
19: }
20: return(NULL) % no packet to dequeue
21: }
22: maxrand(u) { % return the max of u random numbers
23: maxr=0
24: while (u-- > 0)
25: maxr = max(maxr, rand()) % 0 <= rand() < 1
26: return(maxr)
27: }
28: scheduler() {
29: if ( lq.time() + tshift >= cq.time() )
30: return lq;
31: else
32: return cq;
33: }
Figure 10: Example Dequeue Pseudocode for DualQ Coupled Curvy RED AQM
図10：DualQカップルされた曲線レッドAQMのDequeue Pseudocodeの例
The dequeue pseudocode (Figure 10) is repeatedly called whenever the lower layer is ready to forward a packet. It schedules one packet for dequeuing (or zero if the queue is empty) then returns control to the caller so that it does not block while that packet is being forwarded. While making this dequeue decision, it also makes the necessary AQM decisions on dropping or marking. The alternative of applying the AQMs at enqueue would shift some processing from the critical time when each packet is dequeued. However, it would also add a whole queue of delay to the control signals, making the control loop very sloppy.
Dequeue Pseudocode（図10）は、下層がパケットを転送する準備ができている場合はいつでも繰り返し呼び出されます。Dequeuing（またはキューが空の場合はゼロ）のパケットが1つスケジュールされ、そのパケットが転送されている間にブロックされないようにコントロールを呼び出し元に返します。このDequeueの決定を下しながら、ドロップまたはマーキングに必要なAQMの決定も行います。EnqueueでAQMSを適用する代替手段は、各パケットがデケートされている場合の重要な時期から何らかの処理をシフトします。ただし、コントロール信号に遅延のキュー全体を追加し、コントロールループを非常にずさんにします。
The code is written assuming the AQMs are applied on dequeue (Note 1). All the dequeue code is contained within a large while loop so that if it decides to drop a packet, it will continue until it selects a packet to schedule. If both queues are empty, the routine returns NULL at line 20. Line 3 of the dequeue pseudocode is where the conditional priority scheduler chooses between the L4S queue (lq) and the Classic queue (cq). The TS-FIFO scheduler is shown at lines 28-33, which would be suitable if simplicity is paramount (see Note 2).
このコードは、AQMSがDequeueに適用されていると仮定して記述されます（注1）。すべてのdequeueコードは大きなwhileループ内に含まれているため、パケットをドロップすることを決定した場合、スケジュールするパケットを選択するまで続きます。両方のキューが空の場合、ルーチンは20行目でnullを返します。dequeue擬似コードの3行目は、条件付き優先スケジューラがL4Sキュー（LQ）とクラシックキュー（CQ）の間で選択する場所です。TS-FIFOスケジューラは28〜33行目に表示されます。これは、単純さが最重要である場合に適しています（注2を参照）。
Within each queue, the decision whether to forward, drop, or mark is taken as follows (to simplify the explanation, it is assumed that U = 1):
各キュー内で、転送、ドロップ、またはマークのかどうかの決定は次のように取得されます（説明を簡素化するために、u = 1と想定されています）：
L4S: If the test at line 3 determines there is an L4S packet to dequeue, the tests at lines 5b and 5c determine whether to mark it. The first is a simple test of whether the L4S queue delay (lq.time()) is greater than a step threshold T (Note 3). The second test is similar to the random ECN marking in RED but with the following differences: i) marking depends on queuing time, not bytes, in order to scale for any link rate without being reconfigured; ii) marking of the L4S queue depends on a logical OR of two tests: one against its own queuing time and one against the queuing time of the _other_ (Classic) queue; iii) the tests are against the instantaneous queuing time of the L4S queue but against a smoothed average of the other (Classic) queue; and iv) the queue is compared with the maximum of U random numbers (but if U = 1, this is the same as the single random number used in RED).
L4S：3行目のテストでDequeueへのL4Sパケットがあると判断した場合、5Bおよび5Cのテストはマークするかどうかを決定します。1つ目は、L4Sキュー遅延（LQ.Time（））がステップしきい値Tよりも大きいかどうかの簡単なテストです（注3）。2番目のテストは、赤のランダムECNマーキングに似ていますが、次の違いがあります。i）マーキングは、再構成せずにリンクレートをスケーリングするために、バイトではなくキューイング時間に依存します。ii）L4Sキューのマーキングは、論理または2つのテストに依存します。1つは独自のキューイング時間に対して、もう1つは_Other_（クラシック）キューのキューイング時間に対して依存します。iii）テストは、L4Sキューの瞬間的なキューイング時間に対するものですが、他の（クラシック）キューの平均平均に反対します。iv）キューはU乱数の最大値と比較されます（ただし、U = 1の場合、これは赤で使用される単一の乱数と同じです）。
Specifically, in line 5a, the coupled marking probability p_CL is set to the amount by which the averaged Classic queuing delay Q_C exceeds the minimum queuing delay threshold (minTh), all divided by the L4S scaling parameter range_L. range_L represents the queuing delay (in seconds) added to minTh at which marking probability would hit 100%. Then, in line 5c (if U = 1), the result is compared with a uniformly distributed random number between 0 and 1, which ensures that, over range_L, marking probability will linearly increase with queuing time.
具体的には、5A行5Aでは、結合マーキング確率P_CLは、平均化されたクラシックキューイング遅延Q_Cが最小キューイング遅延しきい値（MINTH）を超える量に設定され、すべてL4Sスケーリングパラメーター範囲_Lで割られます。range_lは、マーキング確率が100％に達するMinthに追加されたキューイング遅延（秒単位）を表します。次に、5C行（u = 1の場合）では、結果は0〜1の間の均一に分布した乱数と比較され、range_lを超えるとマーク確率がキューイング時間とともに直線的に増加するようになります。
Classic: If the scheduler at line 3 chooses to dequeue a Classic packet and jumps to line 7, the test at line 10b determines whether to drop or mark it. But before that, line 9a updates Q_C, which is an exponentially weighted moving average (Note 4) of the queuing time of the Classic queue, where cq.time() is the current instantaneous queuing time of the packet at the head of the Classic queue (zero if empty), and gamma is the exponentially weighted moving average (EWMA) constant (default 1/32; see line 12 of the initialization function).
クラシック：3行目のスケジューラがクラシックパケットをDequeueして7行目にジャンプすることを選択した場合、10bのテストはドロップするかマークするかを決定します。しかし、その前に、行9AはQ_Cを更新します。これは、クラシックキューのキューイング時間の指数関数的に加重移動平均（注4）です。ここで、CQ.Time（）はクラシックの頭のパケットの現在の瞬間キューイング時間です。キュー（空の場合はゼロ）、およびガンマは指数関数的に重み付けされた移動平均（EWMA）定数です（デフォルト1/32;初期化関数の12行目を参照）。
Lines 10a and 10b implement the Classic AQM. In line 10a, the averaged queuing time Q_C is divided by the Classic scaling parameter range_C, in the same way that queuing time was scaled for L4S marking. This scaled queuing time will be squared to compute Classic drop probability. So, before it is squared, it is effectively the square root of the drop probability; hence, it is given the variable name sqrt_p_C. The squaring is done by comparing it with the maximum out of two random numbers (assuming U = 1). Comparing it with the maximum out of two is the same as the logical 'AND' of two tests, which ensures drop probability rises with the square of queuing time.
行10Aおよび10Bは、クラシックAQMを実装します。行10Aでは、平均キューイング時間Q_Cは、L4Sマーキングでキューイング時間がスケーリングされたのと同じように、クラシックスケーリングパラメーター範囲_Cで除算されます。このスケーリングされたキューイング時間は、古典的なドロップ確率を計算するために四角化されます。したがって、それが二乗される前に、それは事実上ドロップ確率の平方根です。したがって、変数名sqrt_p_cが与えられます。二乗は、2つの乱数の最大値と比較することによって行われます（U = 1を仮定）。それを2つの最大値と比較することは、論理と 'と同じ2つのテストと同じです。
The AQM functions in each queue (lines 5c and 10b) are two cases of a new generalization of RED called 'Curvy RED', motivated as follows. When the performance of this AQM was compared with FQ-CoDel and PIE, their goal of holding queuing delay to a fixed target seemed misguided [CRED_Insights]. As the number of flows increases, if the AQM does not allow host congestion controllers to increase queuing delay, it has to introduce abnormally high levels of loss. Then loss rather than queuing becomes the dominant cause of delay for short flows, due to timeouts and tail losses.
各キュー（行5cおよび10b）のAQM機能は、次のように動機付けられた「曲線赤」と呼ばれる赤の新しい一般化の2つのケースです。このAQMのパフォーマンスをFQコデルとパイと比較したとき、固定ターゲットにキューイング遅延を保持するという目標は見当違いのように思われました[CRED_INSIGHTS]。フローの数が増加すると、AQMがホストの混雑コントローラーがキューイングの遅延を増加させない場合、異常に高いレベルの損失を導入する必要があります。その後、タイムアウトとテール損失のために、キューイングではなく、短いフローの遅延の支配的な原因になります。
Curvy RED constrains delay with a softened target that allows some increase in delay as load increases. This is achieved by increasing drop probability on a convex curve relative to queue growth (the square curve in the Classic queue, if U = 1). Like RED, the curve hugs the zero axis while the queue is shallow. Then, as load increases, it introduces a growing barrier to higher delay. But, unlike RED, it requires only two parameters, not three. The disadvantage of Curvy RED (compared to a PI controller, for example) is that it is not adapted to a wide range of RTTs. Curvy RED can be used as is when the RTT range to be supported is limited; otherwise, an adaptation mechanism is needed.
曲線の赤は、柔らかいターゲットで遅延を制限し、負荷が増加するにつれて遅延がいくらか増加します。これは、キューの成長と比較して凸曲線上の低下確率を増加させることによって達成されます（u = 1の場合、古典的なキューの正方形曲線）。赤のように、曲線はゼロ軸を抱きしめ、キューは浅いです。次に、負荷が増加すると、より高い遅延への障壁が増加します。ただし、赤とは異なり、3つではなく、2つのパラメーターのみが必要です。Curvy Redの欠点（たとえば、PIコントローラーと比較）は、広範囲のRTTに適応していないことです。曲線赤の赤は、サポートされるRTT範囲が制限されている場合に使用できます。それ以外の場合、適応メカニズムが必要です。
From our limited experiments with Curvy RED so far, recommended values of these parameters are: S_C = -1; g_C = 5; T = 5 * MTU at the link rate (about 1 ms at 60 Mb/s) for the range of base RTTs typical on the public Internet. [CRED_Insights] explains why these parameters are applicable whatever rate link this AQM implementation is deployed on and how the parameters would need to be adjusted for a scenario with a different range of RTTs (e.g., a data centre). The setting of k depends on policy (see Section 2.5 and Appendix C.2, respectively, for its recommended setting and guidance on alternatives).
これまでの曲線赤の限られた実験から、これらのパラメーターの推奨値は次のとおりです。S_C= -1;G_C = 5;パブリックインターネット上で典型的なベースRTTの範囲について、T = 5 * MTU（60 MB/sで約1ミリ秒）。[CRED_INSIGHTS]これらのパラメーターが適用される理由を説明します。このAQM実装が展開されているレートリンクと、異なる範囲のRTT（データセンターなど）でシナリオのパラメーターを調整する必要があります。Kの設定はポリシーに依存します（代替案に関する推奨設定とガイダンスについては、それぞれセクション2.5と付録C.2を参照してください）。
There is also a cUrviness parameter, U, which is a small positive integer. It is likely to take the same hard-coded value for all implementations, once experiments have determined a good value. Only U = 1 has been used in experiments so far, but results might be even better with U = 2 or higher.
また、小さな正の整数である曲線パラメーターuもあります。実験が良い値を決定すると、すべての実装で同じハードコーディング値を取る可能性があります。これまでの実験ではU = 1のみが使用されてきましたが、U = 2以上の場合、結果はさらに良くなる可能性があります。
Notes:
ノート：
1. The alternative of applying the AQMs at enqueue would shift some processing from the critical time when each packet is dequeued. However, it would also add a whole queue of delay to the control signals, making the control loop sloppier (for a typical RTT, it would double the Classic queue's feedback delay). On a platform where packet timestamping is feasible, e.g., Linux, it is also easiest to apply the AQMs at dequeue, because that is where queuing time is also measured.
1. EnqueueでAQMSを適用する代替手段は、各パケットがデケートされている場合の重要な時期から何らかの処理をシフトします。ただし、コントロール信号に遅延のキュー全体を追加して、コントロールループをスロップパイアーにします（典型的なRTTの場合、古典的なキューのフィードバック遅延を2倍にします）。パケットのタイムスタンプが実行可能なプラットフォーム、例えばLinux、DequeueでAQMSを適用することも最も簡単です。これは、キューイング時間も測定されるためです。
2. WRR better isolates the L4S queue from large delay bursts in the Classic queue, but it is slightly less simple than TS-FIFO. If WRR were used, a low default Classic weight (e.g., 1/16) would need to be configured in place of the time-shift in line 5 of the initialization function (Figure 9).
2. WRRは、クラシックキューの大きな遅延バーストからL4Sキューをより適切に分離しますが、TS-FIFOよりもわずかに単純ではありません。WRRを使用した場合、初期化関数の5行目のタイムシフトの代わりに、低デフォルトのクラシック重量（1/16など）を構成する必要があります（図9）。
3. A step function is shown for simplicity. A ramp function (see Figure 5 and the discussion around it in Appendix A.1) is recommended, because it is more general than a step and has the potential to enable L4S congestion controls to converge more rapidly.
3. 簡単にするためのステップ関数が表示されます。ランプ関数（図5と付録A.1の説明を参照）が推奨されます。これは、ステップよりも一般的であり、L4Sの混雑コントロールがより迅速に収束できるようにする可能性があるためです。
4. An EWMA is only one possible way to filter bursts; other more adaptive smoothing methods could be valid, and it might be appropriate to decrease the EWMA faster than it increases, e.g., by using the minimum of the smoothed and instantaneous queue delays, min(Q_C, qc.time()).
4. EWMAは、バーストをフィルタリングする1つの可能な方法にすぎません。他のより適応性のあるスムージング方法は有効である可能性があり、たとえば、EWMAを増加させるよりも速く減らすことが適切かもしれません。
Although code optimization depends on the platform, the following notes explain where the design of Curvy RED was particularly motivated by efficient implementation.
コードの最適化はプラットフォームに依存していますが、次のメモは、Curvy Redの設計が効率的な実装によって特に動機付けられた場所を説明しています。
The Classic AQM at line 10b in Figure 10 calls maxrand(2*U), which gives twice as much curviness as the call to maxrand(U) in the marking function at line 5c. This is the trick that implements the square rule in equation (1) (Section 2.1). This is based on the fact that, given a number X from 1 to 6, the probability that two dice throws will both be less than X is the square of the probability that one throw will be less than X. So, when U = 1, the L4S marking function is linear and the Classic dropping function is squared. If U = 2, L4S would be a square function and Classic would be quartic. And so on.
図10のライン10BのクラシックAQMは、Maxrand（2*u）を呼び出します。これは、5c行のマーキング関数でMaxrand（U）への呼び出しの2倍の曲線を与えます。これは、方程式（1）（セクション2.1）の正方形のルールを実装するトリックです。これは、1から6の数値xを考えると、2つのサイコロがスローする確率が両方ともx未満であるという事実に基づいています。1つのスローがx未満になる確率の正方形です。したがって、u = 1の場合、L4Sマーキング関数は線形であり、古典的なドロップ関数は四角です。U = 2の場合、L4Sは正方形の関数であり、クラシックは四分位になります。等々。
The maxrand(u) function in lines 22-27 simply generates u random numbers and returns the maximum. Typically, maxrand(u) could be run in parallel out of band. For instance, if U = 1, the Classic queue would require the maximum of two random numbers. So, instead of calling maxrand(2*U) in-band, the maximum of every pair of values from a pseudorandom number generator could be generated out of band and held in a buffer ready for the Classic queue to consume.
22〜27行目のMaxrand（U）関数は、u乱数を生成し、最大値を返します。通常、Maxrand（U）はバンドから並行して実行できます。たとえば、u = 1の場合、古典的なキューには最大2つの乱数が必要になります。したがって、マックスランド（2*u）を帯域に呼び出す代わりに、擬似ランダム数ジェネレーターからのすべてのペアの値の最大値をバンドから生成し、クラシックキューを消費できるバッファーに保持できます。
1: cred_dequeue(lq, cq, pkt) { % Couples L4S & Classic queues
2: while ( lq.byt() + cq.byt() > 0 ) {
3: if ( scheduler() == lq ) {
4: lq.dequeue(pkt) % L4S scheduled
5: if ((lq.time() > T) OR (Q_C >> (S_L-2) > maxrand(U)))
6: mark(pkt)
7: } else {
8: cq.dequeue(pkt) % Classic scheduled
9: Q_C += (qc.ns() - Q_C) >> g_C % Classic Q EWMA
10: if ( (Q_C >> (S_C-2) ) > maxrand(2*U) ) {
11: if ( (ecn(pkt) == 0) { % ECN field = not-ECT
12: drop(pkt) % Squared drop, redo loop
13: continue % continue to the top of the while loop
14: }
15: mark(pkt)
16: }
17: }
18: return(pkt) % return the packet and stop here
19: }
20: return(NULL) % no packet to dequeue
21: }
Figure 11: Optimised Example Dequeue Pseudocode for DualQ Coupled AQM using Integer Arithmetic
図11：整数算術を使用して、dualq結合されたAQMの最適化されたDequeue pseudocode
The two ranges, range_L and range_C, are expressed as powers of 2 so that division can be implemented as a right bit-shift (>>) in lines 5 and 10 of the integer variant of the pseudocode (Figure 11).
2つの範囲、range_lとrange_cは2のパワーとして表されるため、擬似コードの整数バリアントの5行目と10行で右ビットシフト（>>）として分割を実装できます（図11）。
For the integer variant of the pseudocode, an integer version of the rand() function used at line 25 of the maxrand() function in Figure 10 would be arranged to return an integer in the range 0 <= maxrand() < 2^32 (not shown). This would scale up all the floating point probabilities in the range [0,1] by 2^32.
Pseudocodeの整数バリアントの場合、図10のmaxrand（）関数の行25で使用されるrand（）関数の整数バージョンは、範囲0 <= maxrand（）<2^32の範囲に整数を返すように配置されます。（示されていない）。これにより、範囲[0,1] x 2^32のすべてのフローティングポイント確率をスケールアップします。
Queuing delays are also scaled up by 2^32, but in two stages: i) in line 9, queuing time qc.ns() is returned in integer nanoseconds, making the value about 2^30 times larger than when the units were seconds, and then ii) in lines 5 and 10, an adjustment of -2 to the right bit-shift multiplies the result by 2^2, to complete the scaling by 2^32.
キューイングの遅延も2^32でスケーリングされますが、2段階で次の2段階で、9行目では、QC.NS（）が整数ナノ秒で返され、単位が数秒である場合よりも約2^30倍大きくなります。、その後ii）行5および10で、右ビットシフトへの-2の調整により、結果に2^2を掛けて、スケーリングを2^32に完了します。
In line 8 of the initialization function, the EWMA constant gamma is represented as an integer power of 2, g_C, so that in line 9 of the integer code (Figure 11), the division needed to weight the moving average can be implemented by a right bit-shift (>> g_C).
初期化関数の8行目では、EWMA定数ガンマは整数2、G_Cとして表されているため、整数コードの9行目（図11）では、移動平均を重み付けするために必要な分割は、右ビットシフト（>> g_c）。
Appendix C. Choice of Coupling Factor, k
付録C. 結合係数の選択、k
Where Classic flows compete for the same capacity, their relative flow rates depend not only on the congestion probability but also on their end-to-end RTT (= base RTT + queue delay). The rates of Reno [RFC5681] flows competing over an AQM are roughly inversely proportional to their RTTs. CUBIC exhibits similar RTT-dependence when in Reno-friendly mode, but it is less RTT-dependent otherwise.
古典的なフローが同じ容量を競う場合、それらの相対的なフロー率は輻輳確率だけでなく、エンドツーエンドのRTT（=ベースRTTキュー遅延）にも依存します。AQMを介して競合するRENO [RFC5681]フローのレートは、RTTにほぼ反比例します。キュービックは、リノフレンドリーモードの場合、同様のRTT依存性を示しますが、それ以外の場合はRTT依存性が低くなります。
Until the early experiments with the DualQ Coupled AQM, the importance of the reasonably large Classic queue in mitigating RTT-dependence when the base RTT is low had not been appreciated. Appendix A.1.6 of the L4S ECN Protocol [RFC9331] uses numerical examples to explain why bloated buffers had concealed the RTT-dependence of Classic congestion controls before that time. Then, it explains why, the more that queuing delays have reduced, the more that RTT-dependence has surfaced as a potential starvation problem for long RTT flows, when competing against very short RTT flows.
DualQ結合AQMを使用した初期の実験まで、ベースRTTが低い場合のRTT依存を緩和する上で合理的に大きな古典的なキューの重要性は評価されていませんでした。L4S ECNプロトコル[RFC9331]の付録A.1.6は、数値例を使用して、肥大化したバッファーがそれ以前に古典的な輻輳コントロールのRTT依存性を隠した理由を説明しています。それから、非常に短いRTTフローと競合するときに、キューイングの遅延が減少したほど、RTT依存が長いRTTフローの潜在的な飢starの問題として浮上した理由を説明します。
Given that congestion control on end systems is voluntary, there is no reason why it has to be voluntarily RTT-dependent. The RTT-dependence of existing Classic traffic cannot be 'undeployed'. Therefore, [RFC9331] requires L4S congestion controls to be significantly less RTT-dependent than the standard Reno congestion control [RFC5681], at least at low RTT. Then RTT-dependence ought to be no worse than it is with appropriately sized Classic buffers. Following this approach means there is no need for network devices to address RTT-dependence, although there would be no harm if they did, which per-flow queuing inherently does.
エンドシステムの混雑制御が自発的であることを考えると、それが自発的にRTT依存性でなければならない理由はありません。既存の古典的なトラフィックのRTT依存性を「非公開」することはできません。したがって、[RFC9331]では、少なくとも低いRTTでは、L4Sの混雑コントロールが標準のRENO輻輳制御[RFC5681]よりもRTT依存性が大幅に少ないことが必要です。その後、RTT依存は、適切なサイズのクラシックバッファーを使用するよりも悪くないはずです。このアプローチに従うことは、ネットワークデバイスがRTT依存に対処する必要がないことを意味しますが、彼らがそうしていれば害はありませんが、それが本質的に行うとは害はありません。
The coupling factor, k, determines the balance between L4S and Classic flow rates (see Section 2.5.2.1 and equation (1) in Section 2.1).
結合係数Kは、L4と古典的な流量のバランスを決定します（セクション2.5.2.1およびセクション2.1の式（1）を参照）。
For the public Internet, a coupling factor of k = 2 is recommended and justified below. For scenarios other than the public Internet, a good coupling factor can be derived by plugging the appropriate numbers into the same working.
パブリックインターネットの場合、K = 2の結合係数が推奨され、以下に正当化されます。パブリックインターネット以外のシナリオの場合、適切な数字を同じ動作にプラグインすることで、優れた結合係数を導き出すことができます。
To summarize the maths below, from equation (7) it can be seen that choosing k = 1.64 would theoretically make L4S throughput roughly the same as Classic, _if their actual end-to-end RTTs were the same_. However, even if the base RTTs are the same, the actual RTTs are unlikely to be the same, because Classic traffic needs a fairly large queue to avoid underutilization and excess drop, whereas L4S does not.
以下の数学を要約するために、式（7）から、k = 1.64を選択することは、理論的にL4Sスループットをクラシックとほぼ同じにすることがわかります。ただし、ベースRTTが同じであっても、実際のRTTは同じである可能性は低いです。これは、古典的なトラフィックには、十分に活用されないと過剰な低下を避けるためにかなり大きなキューが必要であるため、L4Sはそうではありません。
Therefore, to determine the appropriate coupling factor policy, the operator needs to decide at what base RTT it wants L4S and Classic flows to have roughly equal throughput, once the effect of the additional Classic queue on Classic throughput has been taken into account. With this approach, a network operator can determine a good coupling factor without knowing the precise L4S algorithm for reducing RTT-dependence -- or even in the absence of any algorithm.
したがって、適切なカップリング因子ポリシーを決定するために、オペレーターは、L4とクラシックフローがほぼ等しいスループットを持つことを望んでいるベースRTTで決定する必要があります。このアプローチを使用すると、ネットワークオペレーターは、RTT依存性を減らすための正確なL4Sアルゴリズムを知らずに、またはアルゴリズムがない場合でも、優れた結合係数を決定できます。
The following additional terminology will be used, with appropriate subscripts:
適切なサブスクリプトを使用して、次の追加の用語が使用されます。
r: Packet rate [pkt/s]
R：パケットレート[pkt/s]
R: RTT [s/round]
R：RTT [S/ROUND]
p: ECN-marking probability []
P：ECNマーキング確率[]
On the Classic side, we consider Reno as the most sensitive and therefore worst-case Classic congestion control. We will also consider CUBIC in its Reno-friendly mode ('CReno') as the most prevalent congestion control, according to the references and analysis in [PI2param]. In either case, the Classic packet rate in steady state is given by the well-known square root formula for Reno congestion control:
古典的な側面では、リノは最も敏感であり、したがって最悪の古典的な混雑制御と考えています。また、[Pi2Param]の参照と分析によれば、Cubicのリノフレンドリーモード（「Creno」）の最も一般的な混雑制御と見なします。どちらの場合でも、定常状態の古典的なパケットレートは、リノ輻輳制御のためのよく知られている平方根式によって与えられます。
r_C = 1.22 / (R_C * p_C^0.5) (5)
On the L4S side, we consider the Prague congestion control [PRAGUE-CC] as the reference for steady-state dependence on congestion. Prague conforms to the same equation as DCTCP, but we do not use the equation derived in the DCTCP paper, which is only appropriate for step marking. The coupled marking, p_CL, is the appropriate one when considering throughput equivalence with Classic flows. Unlike step marking, coupled markings are inherently spaced out, so we use the formula for DCTCP packet rate with probabilistic marking derived in Appendix A of [PI2]. We use the equation without RTT-independence enabled, which will be explained later.
L4S側では、プラハの混雑制御[プラハ-CC]は、渋滞への定常状態依存の参照と考えています。PragueはDCTCPと同じ方程式に準拠していますが、DCTCPペーパーで導出された方程式は使用しません。これはステップマークにのみ適しています。結合したマーキングであるP_CLは、クラシックフローとスループットの等価性を考慮するときに適切なマーキングです。ステップマーキングとは異なり、結合マーキングは本質的に間隔を空けているため、[PI2]の付録Aに導き出された確率的マーキングを使用して、DCTCPパケットレートの式を使用します。RTT独立性が有効になっていない方程式を使用します。これについては、後で説明します。
r_L = 2 / (R_L * p_CL) (6)
For packet rate equivalence, we equate the two packet rates and rearrange the equation into the same form as equation (1) (copied from Section 2.1) so the two can be equated and simplified to produce a formula for a theoretical coupling factor, which we shall call k*:
パケットレートの等価性については、2つのパケットレートを等しくし、方程式を方程式（1）と同じ形式に再配置します（セクション2.1からコピー）。K*に電話します。
r_c = r_L
=> p_C = (p_CL/1.64 * R_L/R_C)^2.
p_C = ( p_CL / k )^2. (1)
k* = 1.64 * (R_C / R_L). (7)
We say that this coupling factor is theoretical, because it is in terms of two RTTs, which raises two practical questions: i) for multiple flows with different RTTs, the RTT for each traffic class would have to be derived from the RTTs of all the flows in that class (actually the harmonic mean would be needed) and ii) a network node cannot easily know the RTT of the flows anyway.
この結合因子は理論的であると言います。これは2つのRTTの観点からであり、2つの実際的な質問を提起するため、i）異なるRTTを使用した複数のフローについて、各トラフィッククラスのRTTはすべてのRTTから導き出されなければなりません。そのクラスの流れ（実際には高調波平均が必要です）、ii）ネットワークノードは、とにかくフローのRTTを簡単に知ることができません。
RTT-dependence is caused by window-based congestion control, so it ought to be reversed there, not in the network. Therefore, we use a fixed coupling factor in the network and reduce RTT-dependence in L4S senders. We cannot expect Classic senders to all be updated to reduce their RTT-dependence. But solely addressing the problem in L4S senders at least makes RTT-dependence no worse -- not just between L4S senders, but also between L4S and Classic senders.
RTT依存は、ウィンドウベースの混雑制御によって引き起こされるため、ネットワークではなく、そこで逆にする必要があります。したがって、ネットワークで固定結合係数を使用し、L4S送信者のRTT依存性を削減します。古典的な送信者がRTT依存を減らすために更新されることを期待することはできません。しかし、L4S送信者の問題に対処するだけで、少なくともRTT依存性は悪化しません - L4S送信者だけでなく、L4Sと古典的な送信者の間でも。
Throughput equivalence is defined for flows under comparable conditions, including with the same base RTT [RFC2914]. So if we assume the same base RTT, R_b, for comparable flows, we can put both R_C and R_L in terms of R_b.
スループットの等価性は、同じベースRTT [RFC2914]を含む同等の条件下でのフローの場合に定義されます。したがって、同等のフローの場合、同じベースRTT、R_Bを想定した場合、R_CとR_Lの両方をR_Bの観点から配置できます。
We can approximate the L4S RTT to be hardly greater than the base RTT, i.e., R_L ~= R_b. And we can replace R_C with (R_b + q_C), where the Classic queue, q_C, depends on the target queue delay that the operator has configured for the Classic AQM.
L4S RTTは、ベースRTT、つまりR_L〜 = R_Bよりもほとんど大きくないと近似できます。また、R_Cを（R_B Q_C）に置き換えることができます。この場合、クラシックキューQ_Cは、オペレーターがクラシックAQMに設定したターゲットキュー遅延に依存します。
Taking PI2 as an example Classic AQM, it seems that we could just take R_C = R_b + target (recommended 15 ms by default in Appendix A.1). However, target is roughly the queue depth reached by the tips of the sawteeth of a congestion control, not the average [PI2param]. That is R_max = R_b + target.
PI2を古典的なAQMの例として使用すると、R_C = R_Bターゲットを取得できるようです（付録A.1でデフォルトで推奨される15ミリ秒）。ただし、ターゲットは、ほぼ平均[PI2PARAM]ではなく、うっ血制御の鋸の先端によって到達するキューの深さです。それはR_MAX = R_Bターゲットです。
The position of the average in relation to the max depends on the amplitude and geometry of the sawteeth. We consider two examples: Reno [RFC5681], as the most sensitive worst case, and CUBIC [RFC8312] in its Reno-friendly mode ('CReno') as the most prevalent congestion control algorithm on the Internet according to the references in [PI2param]. Both are Additive Increase Multiplicative Decrease (AIMD), so we will generalize using b as the multiplicative decrease factor (b_r = 0.5 for Reno, b_c = 0.7 for CReno). Then
最大値に関連する平均の位置は、鋸の振幅とジオメトリに依存します。2つの例を検討します：リノ[RFC5681]、最も敏感な最悪のケースとして、および[PI2PARAMAMATIONコントロールコントロールアルゴリズムとして、RENOに優しいモード（ 'Creno'）の2つのキュービック[RFC8312）]。どちらも加法増加乗数増加（AIMD）であるため、乗法減少係数としてBを使用することを一般化します（RenoではB_R = 0.5、Crenoの場合はB_C = 0.7）。それで
R_C = (R_max + b*R_max) / 2
= R_max * (1+b)/2.
R_reno = 0.75 * (R_b + target); R_creno = 0.85 * (R_b + target).
(8)
Plugging all this into equation (7), at any particular base RTT, R_b, we get a fixed coupling factor for each:
これらすべてを式（7）にプラグインし、特定のベースRTT、R_Bで、それぞれの固定結合係数を取得します。
k_reno = 1.64*0.75*(R_b+target)/R_b = 1.23*(1 + target/R_b); k_creno = 1.39 * (1 + target/R_b).
k_reno = 1.64*0.75*（r_bターゲット）/r_b = 1.23*（1ターゲット/r_b）;k_creno = 1.39 *（1ターゲット/r_b）。
An operator can then choose the base RTT at which it wants throughput to be equivalent. For instance, if we recommend that the operator chooses R_b = 25 ms, as a typical base RTT between Internet users and CDNs [PI2param], then these coupling factors become:
オペレーターは、スループットを同等にしたいベースRTTを選択できます。たとえば、オペレーターがインターネットユーザーとCDN [PI2PARAM]の間の典型的なベースRTTとしてR_B = 25ミリ秒を選択することをお勧めする場合、これらの結合因子は次のようになります。
k_reno = 1.23 * (1 + 15/25) k_creno = 1.39 * (1 + 15/25)
= 1.97 = 2.22
~= 2. ~= 2. (9)
The approximation is relevant to any of the above example DualQ Coupled algorithms, which use a coupling factor that is an integer power of 2 to aid efficient implementation. It also fits best for the worst case (Reno).
近似は、効率的な実装を支援するために2の整数パワーであるカップリング係数を使用する上記のDualQ結合アルゴリズムのいずれかに関連しています。また、最悪のケース（RENO）に最適です。
To check the outcome of this coupling factor, we can express the ratio of L4S to Classic throughput by substituting from their rate equations (5) and (6), then also substituting for p_C in terms of p_CL using equation (1) with k = 2 as just determined for the Internet:
このカップリング係数の結果を確認するために、速度方程式（5）と（6）から置換することにより、L4の比率を古典的なスループットと表現し、k = k =と式（1）を使用してp_clの観点からP_Cを置き換えることもできます。2インターネットのために決定されたばかりのように：
r_L / r_C = 2 (R_C * p_C^0.5) / 1.22 (R_L * p_CL)
= (R_C * p_CL) / (1.22 * R_L * p_CL)
= R_C / (1.22 * R_L). (10)
As an example, we can then consider single competing CReno and Prague flows, by expressing both their RTTs in (10) in terms of their base RTTs, R_bC and R_bL. So R_C is replaced by equation (8) for CReno. And R_L is replaced by the max() function below, which represents the effective RTT of the current Prague congestion control [PRAGUE-CC] in its (default) RTT-independent mode, because it sets a floor to the effective RTT that it uses for additive increase:
例として、ベースRTT、R_BC、R_BLの観点から（10）の両方のRTTを表現することにより、単一の競合するクレノとプラハの流れを考慮することができます。したがって、R_CはCrenoの式（8）に置き換えられます。R_Lは以下のmax（）関数に置き換えられます。これは、（デフォルト）RTT非依存モードで現在のプラハ輻輳制御[Prague-CC]の有効なRTTを表します。アディティブ増加のため：
r_L / r_C ~= 0.85 * (R_bC + target) / (1.22 * max(R_bL, R_typ))
~= (R_bC + target) / (1.4 * max(R_bL, R_typ)).
It can be seen that, for base RTTs below target (15 ms), both the numerator and the denominator plateau, which has the desired effect of limiting RTT-dependence.
ターゲット（15ミリ秒）未満のベースRTTの場合、分子と分母プラトーの両方が、RTT依存性を制限するという望ましい効果を持つことがわかります。
At the start of the above derivations, an explanation was promised for why the L4S throughput equation in equation (6) did not need to model RTT-independence. This is because we only use one point -- at the typical base RTT where the operator chooses to calculate the coupling factor. Then throughput equivalence will at least hold at that chosen point. Nonetheless, assuming Prague senders implement RTT-independence over a range of RTTs below this, the throughput equivalence will then extend over that range as well.
上記の派生の開始時に、式（6）のL4Sスループット方程式がRTT独立性をモデル化する必要がなかった理由について説明が約束されました。これは、オペレーターがカップリング係数の計算を選択する典型的なベースRTTで、1つのポイントのみを使用するためです。スループットの等価性は、少なくともその選択されたポイントで保持されます。それにもかかわらず、プラハの送信者がこれより下のさまざまなRTTにRTT独立性を実装すると仮定すると、スループットの等価性もその範囲に及びます。
Congestion control designers can choose different ways to reduce RTT-dependence. And each operator can make a policy choice to decide on a different base RTT, and therefore a different k, at which it wants throughput equivalence. Nonetheless, for the Internet, it makes sense to choose what is believed to be the typical RTT most users experience, because a Classic AQM's target queuing delay is also derived from a typical RTT for the Internet.
混雑制御設計者は、RTT依存を減らすためのさまざまな方法を選択できます。また、各オペレーターは、異なるベースRTTを決定するためのポリシーを選択できます。したがって、スループットの等価性が必要な別のKを決定できます。それにもかかわらず、インターネットの場合、ほとんどのユーザーが経験する典型的なRTTであると考えられているものを選択することは理にかなっています。
As a non-Internet example, for localized traffic from a particular ISP's data centre, using the measured RTTs, it was calculated that a value of k = 8 would achieve throughput equivalence, and experiments verified the formula very closely.
非インターネットの例として、特定のISPのデータセンターからのローカライズされたトラフィックの測定されたRTTを使用して、k = 8の値がスループットの等価性を達成し、実験により式が非常に密接に検証されたと計算されました。
But, for a typical mix of RTTs across the general Internet, a value of k = 2 is recommended as a good workable compromise.
ただし、一般的なインターネット全体のRTTの典型的な組み合わせの場合、優れた実行可能な妥協としてk = 2の値が推奨されます。
Acknowledgements
謝辞
Thanks to Anil Agarwal, Sowmini Varadhan, Gabi Bracha, Nicolas Kuhn, Greg Skinner, Tom Henderson, David Pullen, Mirja Khlewind, Gorry Fairhurst, Pete Heist, Ermin Sakic, and Martin Duke for detailed review comments, particularly of the appendices, and suggestions on how to make the explanations clearer. Thanks also to Tom Henderson for insight on the choice of schedulers and queue delay measurement techniques. And thanks to the area reviewers Christer Holmberg, Lars Eggert, and Roman Danyliw.
Anil Agarwal、Sowmini Varadhan、Gabi Bracha、Nicolas Kuhn、Greg Skinner、Tom Henderson、David Pullen、Mirja Khlewind、Gorry Fairhurst、Pete Heist、Ermin Sakic、Martin Dukeの詳細なレビューコメント、特に付録、提案のおかげで説明をより明確にする方法について。また、スケジューラとキュー遅延測定技術の選択に関する洞察について、Tom Hendersonにも感謝します。そして、地域のレビュアーChrister Holmberg、Lars Eggert、およびRoman Danyliwに感謝します。
The early contributions of Koen De Schepper, Bob Briscoe, Olga Bondarenko, and Inton Tsang were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). Contributions of Koen De Schepper and Olivier Tilmans were also partly funded by the 5Growth and DAEMON EU H2020 projects. Bob Briscoe's contribution was also partly funded by the Comcast Innovation Fund and the Research Council of Norway through the TimeIn project. The views expressed here are solely those of the authors.
Koen de Schepper、Bob Briscoe、Olga Bondarenko、およびInton Tsangの初期の貢献は、削減されたインターネット輸送Latency（Rite）プロジェクト（ICT-317700）を通じて、7番目のフレームワークプログラムの下で欧州共同体によって部分的に資金提供されました。Koen de SchepperとOlivier Tilmansの貢献も、5成長とDaemon Eu H2020プロジェクトによって部分的に資金提供されていました。ボブ・ブリスコの貢献は、Comcast Innovation FundとTimein Projectを通じてノルウェーの研究評議会によっても部分的に資金提供されていました。ここで表明された見解は、著者の見解だけです。
Contributors
貢献者
The following contributed implementations and evaluations that validated and helped to improve this specification:
次の貢献した実装と評価は、この仕様の改善に役立ったものです。
Olga Albisser <olga@albisser.org> of Simula Research Lab, Norway (Olga Bondarenko during early draft versions) implemented the prototype DualPI2 AQM for Linux with Koen De Schepper and conducted extensive evaluations as well as implementing the live performance visualization GUI [L4Sdemo16].
ノルウェーのSimula Research Lab（初期ドラフトバージョン中のOlga Bondarenko）のSimula Research LabのOlga Albisser <olga@albisser.org>は、Koen de Schepperを使用してLinux用のプロトタイプDualpi2 AQMを実装し、ライブパフォーマンスの視覚化GUI [L4Semo16]を実装するだけでなく、広範な評価を実施しました。。
Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> of Nokia Bell Labs, Belgium prepared and maintains the Linux implementation of DualPI2 for upstreaming.
Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com> Nokia Bell Labsの>ベルギーのLinux実装を準備し、維持しています。
Shravya K.S. wrote a model for the ns-3 simulator based on draft-ietf-tsvwg-aqm-dualq-coupled-01 (a draft version of this document). Based on this initial work, Tom Henderson <tomh@tomh.org> updated that earlier model and created a model for the DualQ variant specified as part of the Low Latency DOCSIS specification, as well as conducting extensive evaluations.
Shravya K.S.ドラフト-ITEF-TSVWG-AQM-DUALQ-COUPLED-01（このドキュメントのドラフトバージョン）に基づいて、NS-3シミュレーターのモデルを作成しました。この最初の作業に基づいて、Tom Henderson <tomh@tomh.org>は、その以前のモデルを更新し、低レイテンシDOCSIS仕様の一部として指定されたDualQバリアントのモデルを作成し、広範な評価を実施しました。
Ing Jyh (Inton) Tsang of Nokia, Belgium built the End-to-End Data Centre to the Home broadband testbed on which DualQ Coupled AQM implementations were tested.
ベルギーのNokiaのJyh（Inton）Tsangは、dualq結合されたAQM実装がテストされたホームブロードバンドテストベッドにエンドツーエンドのデータセンターを構築しました。
Authors' Addresses
著者のアドレス
Koen De Schepper Nokia Bell Labs Antwerp Belgium Email: koen.de_schepper@nokia.com URI: https://www.bell-labs.com/about/researcher-profiles/ koende_schepper/
Koen de Schepper Nokia Bell Labs Antwerp Belgiumメール：koen.de_schepper@nokia.com Uri：https：//www.bell-labs.com/about/researcher-profiles/ koende_schepper/
Bob Briscoe (editor) Independent United Kingdom Email: ietf@bobbriscoe.net URI: https://bobbriscoe.net/
Bob Briscoe（編集者）独立した英国電子メール：ietf@bobbriscoe.net uri：https：//bobbriscoe.net/
Greg White CableLabs Louisville, CO United States of America Email: G.White@CableLabs.com
グレッグホワイトケーブルラブルイビル、コロラド州アメリカ合衆国電子メール：g.white@cablelabs.com