[要約] RFC 9330は、L4Sアーキテクチャを通じて、インターネットアプリケーションが低遅延、低損失、およびスケーラブルなスループット制御を実現することを可能にします。このアーキテクチャは、送信者の容量を求める輻輳制御が遅延の原因であるという考えに基づいており、新しい輻輳制御を採用することで低遅延と高スループットを両立させることを目的としています。
Internet Engineering Task Force (IETF) B. Briscoe, Ed.
Request for Comments: 9330 Independent
Category: Informational K. De Schepper
ISSN: 2070-1721 Nokia Bell Labs
M. Bagnulo
Universidad Carlos III de Madrid
G. White
CableLabs
January 2023
Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture
低レイテンシ、低損失、スケーラブルスループット（L4S）インターネットサービス：アーキテクチャ
Abstract
概要
This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.
このドキュメントでは、L4Sアーキテクチャについて説明します。これにより、インターネットアプリケーションは、キューイングの遅延、低い混雑損失、スケーラブルなスループット制御を実現できます。L4Sは、キューイング遅延の根本原因は、キュー自体ではなく、送信者の容量を求める混雑コントローラーにあるという洞察に基づいています。L4Sアーキテクチャを使用すると、すべてのインターネットアプリケーションは、かなりのキューイング遅延を引き起こす輻輳制御アルゴリズムから遠ざけ、代わりに、キューイングがほとんどなく容量を求めることができる新しいクラスの混雑コントロールを採用する可能性があります。これらは、ネットワークからの明示的な混雑通知（ECN）の修正形式によって支援されます。この新しいアーキテクチャを使用すると、アプリケーションは遅延が低く、スループットが高くなる可能性があります。
The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance.
アーキテクチャは、主に増分展開に関するものです。L4Sの新しいクラスの混雑コントロールが共有ネットワーク内の「クラシック」混雑コントロールと共存できるようにするメカニズムを定義します。目的は、L4Sのレイテンシとスループットが通常はるかに優れている（そしてめったに悪いことではない）が、通常は古典的なパフォーマンスに影響を与えないことです。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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/rfc9330.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9330で取得できます。
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. Document Roadmap
2. L4S Architecture Overview
3. Terminology
4. L4S Architecture Components
4.1. Protocol Mechanisms
4.2. Network Components
4.3. Host Mechanisms
5. Rationale
5.1. Why These Primary Components?
5.2. What L4S Adds to Existing Approaches
6. Applicability
6.1. Applications
6.2. Use Cases
6.3. Applicability with Specific Link Technologies
6.4. Deployment Considerations
6.4.1. Deployment Topology
6.4.2. Deployment Sequences
6.4.3. L4S Flow but Non-ECN Bottleneck
6.4.4. L4S Flow but Classic ECN Bottleneck
6.4.5. L4S AQM Deployment within Tunnels
7. IANA Considerations
8. Security Considerations
8.1. Traffic Rate (Non-)Policing
8.1.1. (Non-)Policing Rate per Flow
8.1.2. (Non-)Policing L4S Service Rate
8.2. 'Latency Friendliness'
8.3. Interaction between Rate Policing and L4S
8.4. ECN Integrity
8.5. Privacy Considerations
9. Informative References
Acknowledgements
Authors' Addresses
At any one time, it is increasingly common for all of the traffic in a bottleneck link (e.g., a household's Internet access or Wi-Fi) to come from applications that prefer low delay: interactive web, web services, voice, conversational video, interactive video, interactive remote presence, instant messaging, online and cloud-rendered gaming, remote desktop, cloud-based applications, cloud-rendered virtual reality or augmented reality, and video-assisted remote control of machinery and industrial processes. In the last decade or so, much has been done to reduce propagation delay by placing caches or servers closer to users. However, queuing remains a major, albeit intermittent, component of latency. For instance, spikes of hundreds of milliseconds are not uncommon, even with state-of-the-art Active Queue Management (AQM) [COBALT] [DOCSIS3AQM]. A Classic AQM in an access network bottleneck is typically configured to buffer the sawteeth of lone flows, which can cause peak overall network delay to roughly double during a long-running flow, relative to expected base (unloaded) path delay [BufferSize]. Low loss is also important because, for interactive applications, losses translate into even longer retransmission delays.
いつでも、ボトルネックリンクのすべてのトラフィック（たとえば、家庭のインターネットアクセスやWi-Fi）が低い遅延を好むアプリケーションから来ることがますます一般的になっています：インタラクティブWeb、Webサービス、音声、会話ビデオ、インタラクティブなビデオ、インタラクティブなリモートプレゼンス、インスタントメッセージング、オンラインおよびクラウドレンダリングゲーム、リモートデスクトップ、クラウドベースのアプリケーション、クラウドレンダリングの仮想現実または拡張現実、および機械および産業プロセスのビデオ支援リモートコントロール。過去10年ほどで、キャッシュやサーバーをユーザーの近くに配置することにより、伝播遅延を減らすために多くのことが行われました。ただし、キューイングは、断続的ではあるが、レイテンシのコンポーネントである大規模なものであり続けています。たとえば、最先端のアクティブキュー管理（AQM）[Cobalt] [docsis3aqm]であっても、数百ミリ秒の急増は珍しくありません。アクセスネットワークボトルネックのクラシックAQMは、通常、孤独なフローの鋸をバッファーするように構成されています。インタラクティブなアプリケーションの場合、損失はさらに長い再送信の遅延につながるため、低損失も重要です。
It has been demonstrated that, once access network bit rates reach levels now common in the developed world, increasing link capacity offers diminishing returns if latency (delay) is not addressed [Dukkipati06] [Rajiullah15]. Therefore, the goal is an Internet service with very low queuing latency, very low loss, and scalable throughput. Very low queuing latency means less than 1 millisecond (ms) on average and less than about 2 ms at the 99th percentile. End-to-end delay above 50 ms [Raaen14], or even above 20 ms [NASA04], starts to feel unnatural for more demanding interactive applications. Therefore, removing unnecessary delay variability increases the reach of these applications (the distance over which they are comfortable to use) and/or provides additional latency budget that can be used for enhanced processing. This document describes the L4S architecture for achieving these goals.
先進国で一般的なネットワークビットレートにアクセスすると、リンク容量を増やすと、遅延（遅延）が対処されない場合、リンク容量が減少することが実証されています[dukkipati06] [rajiullah15]。したがって、目標は、キューイングレイテンシが非常に低く、損失が非常に低く、スケーラブルなスループットを備えたインターネットサービスです。非常に低いキューイングレイテンシは、平均して1ミリ秒（MS）未満で、99パーセンタイルで約2ミリ秒未満です。エンドツーエンドの遅延は、50ミリ秒以上[RAAEN14]、または20 ms [NASA04]を超えると、より要求の厳しいインタラクティブなアプリケーションに対して不自然に感じ始めます。したがって、不必要な遅延変動性を削除すると、これらのアプリケーションの範囲（使用が快適な距離）が増加し、および/または強化された処理に使用できる追加のレイテンシー予算を提供します。このドキュメントでは、これらの目標を達成するためのL4Sアーキテクチャについて説明しています。
Differentiated services (Diffserv) offers Expedited Forwarding (EF) [RFC3246] for some packets at the expense of others, but this makes no difference when all (or most) of the traffic at a bottleneck at any one time requires low latency. In contrast, L4S still works well when all traffic is L4S -- a service that gives without taking needs none of the configuration or management baggage (traffic policing or traffic contracts) associated with favouring some traffic flows over others.
差別化されたサービス（diffserv）は、他のパケットを犠牲にして一部のパケットに対して迅速な転送（EF）[RFC3246]を提供しますが、これは、ボトルネックでのすべてのトラフィックがいつでも低下する必要がある場合に違いはありません。対照的に、すべてのトラフィックがL4Sである場合、L4は依然としてうまく機能します。これは、他のトラフィックフローを支持することに関連する構成または管理荷物（交通警察または交通契約）を必要とせずに提供するサービスです。
Queuing delay degrades performance intermittently [Hohlfeld14]. It occurs i) when a large enough capacity-seeking (e.g., TCP) flow is running alongside the user's traffic in the bottleneck link, which is typically in the access network, or ii) when the low latency application is itself a large capacity-seeking or adaptive rate flow (e.g., interactive video). At these times, the performance improvement from L4S must be sufficient for network operators to be motivated to deploy it.
キューイング遅延は、パフォーマンスを断続的に分解します[hohlfeld14]。i）ボトルネックリンクのユーザーのトラフィック（通常はアクセスネットワーク、またはii）が低レイテンシアプリケーション自体が大容量である場合、十分な容量を求める（例えば、TCP）フローが実行されている場合、それは発生します。シークまたは適応レートフロー（たとえば、インタラクティブビデオ）。これらの時点では、ネットワークオペレーターがそれを展開する動機を与えるには、L4からのパフォーマンスの改善で十分でなければなりません。
Active Queue Management (AQM) is part of the solution to queuing under load. AQM improves performance for all traffic, but there is a limit to how much queuing delay can be reduced by solely changing the network without addressing the root of the problem.
アクティブキュー管理（AQM）は、荷重下のキューイングのソリューションの一部です。AQMはすべてのトラフィックのパフォーマンスを向上させますが、問題のルートに対処せずにネットワークを変更するだけで、キューイングの遅延を減らすことができる量には制限があります。
The root of the problem is the presence of standard congestion control (Reno [RFC5681]) or compatible variants (e.g., CUBIC [RFC8312]) that are used in TCP and in other transports, such as QUIC [RFC9000]. We shall use the term 'Classic' for these Reno-friendly congestion controls. Classic congestion controls induce relatively large sawtooth-shaped excursions of queue occupancy. So if a network operator naively attempts to reduce queuing delay by configuring an AQM to operate at a shallower queue, a Classic congestion control will significantly underutilize the link at the bottom of every sawtooth. These sawteeth have also been growing in duration as flow rate scales (see Section 5.1 and [RFC3649]).
問題の根源は、TCPやQUIC [RFC9000]などの他の輸送で使用される標準的な混雑制御（RENO [RFC5681]）または互換性のあるバリアント（例：Cubic [RFC8312]）の存在です。これらのリノにやさしい混雑コントロールには、「クラシック」という用語を使用します。古典的な混雑コントロールは、キューの占有率の比較的大きな鋸歯状の遠足を誘導します。したがって、ネットワークオペレーターがAQMを浅いキューで動作させるように構成することによりキューイングの遅延を削減しようとする場合、古典的な輻輳制御は、すべての鋸歯の下部にあるリンクを大幅に十分に活用していません。これらの鋸も流量スケールとして期間内に増加しています（セクション5.1および[RFC3649]を参照）。
It has been demonstrated that, if the sending host replaces a Classic congestion control with a 'Scalable' alternative, the performance under load of all the above interactive applications can be significantly improved once a suitable AQM is deployed in the network. Taking the example solution cited below that uses Data Center TCP (DCTCP) [RFC8257] and a Dual-Queue Coupled AQM [RFC9332] on a DSL or Ethernet link, queuing delay under heavy load is roughly 1-2 ms at the 99th percentile without losing link utilization [L4Seval22] [DualPI2Linux] (for other link types, see Section 6.3). This compares with 5-20 ms on _average_ with a Classic congestion control and current state-of-the-art AQMs, such as Flow Queue CoDel [RFC8290], Proportional Integral controller Enhanced (PIE) [RFC8033], or DOCSIS PIE [RFC8034] and about 20-30 ms at the 99th percentile [DualPI2Linux].
送信ホストが古典的な輻輳制御を「スケーラブルな」代替品に置き換えると、上記のすべてのインタラクティブアプリケーションの負荷の下でのパフォーマンスをネットワークに適切なAQMが展開すると大幅に改善できることが実証されています。データセンターTCP（DCTCP）[RFC8257]を使用している以下で引用された例を挙げて、DSLまたはイーサネットリンクでデュアルキュー結合AQM [RFC9332]を使用して、重荷の下でのキューイング遅延は、99パーセンタイルで約1〜2ミリ秒で約1〜2ミリ秒で、リンクの使用率を失う[l4seval22] [dualpi2linux]（他のリンクタイプについては、セクション6.3を参照）。これは、クラシックな輻輳制御とフローキューコードセル[RFC8290]、比例積分コントローラーの強化（PIE）[RFC8033]、またはDocsis PIE [RFC803444444などの最新のAQMを備えた_Average_の5-20ミリ秒と比較されます。] 99パーセンタイルで約20〜30ミリ秒[dualpi2linux]。
L4S is designed for incremental deployment. It is possible to deploy the L4S service at a bottleneck link alongside the existing best efforts service [DualPI2Linux] so that unmodified applications can start using it as soon as the sender's stack is updated. Access networks are typically designed with one link as the bottleneck for each site (which might be a home, small enterprise, or mobile device), so deployment at either or both ends of this link should give nearly all the benefit in the respective direction. With some transport protocols, namely TCP [ACCECN], the sender has to check that the receiver has been suitably updated to give more accurate feedback, whereas with more recent transport protocols, such as QUIC [RFC9000] and Datagram Congestion Control Protocol (DCCP) [RFC4340], all receivers have always been suitable.
L4Sは、増分展開用に設計されています。既存のBest Effects Service [dualpi2linux]とともに、L4SサービスをBottleneckリンクに展開することができます。これにより、変更されていないアプリケーションが更新されるとすぐに使用を開始できます。通常、アクセスネットワークは、各サイトのボトルネックとして1つのリンクで設計されています（ホーム、小さなエンタープライズ、またはモバイルデバイスである可能性があります）ため、このリンクのいずれかまたは両端で展開すると、それぞれの方向にほぼすべての利益が得られます。いくつかの輸送プロトコル、すなわちTCP [accecn]を使用すると、送信者は、より正確なフィードバックを提供するために受信機が適切に更新されていることを確認する必要がありますが、QUIC [RFC9000]やDatagramの混雑制御プロトコル（DCCP）などの最近のトランスポートプロトコルでは[RFC4340]、すべてのレシーバーは常に適しています。
This document presents the L4S architecture. It consists of three components: network support to isolate L4S traffic from Classic traffic; protocol features that allow network elements to identify L4S traffic; and host support for L4S congestion controls. The protocol is defined separately in [RFC9331] as an experimental change to Explicit Congestion Notification (ECN). This document describes and justifies the component parts and how they interact to provide the low latency, low loss, and scalable Internet service. It also details the approach to incremental deployment, as briefly summarized above.
このドキュメントでは、L4Sアーキテクチャを紹介します。これは、3つのコンポーネントで構成されています。L4Sトラフィックをクラシックトラフィックから分離するネットワークサポート。ネットワーク要素がL4Sトラフィックを識別できるようにするプロトコル機能。L4S混雑コントロールのホストサポート。このプロトコルは、明示的なうっ血通知（ECN）への実験的変化として[RFC9331]で個別に定義されています。このドキュメントでは、コンポーネントの部分と、それらがどのように相互作用して、低下、低損失、スケーラブルなインターネットサービスを提供するかについて説明および正当化します。また、上記で簡単に要約されているように、増分展開へのアプローチについても詳しく説明しています。
This document describes the L4S architecture in three passes. First, the brief overview in Section 2 gives the very high-level idea and states the main components with minimal rationale. This is only intended to give some context for the terminology definitions that follow in Section 3 and to explain the structure of the rest of the document. Then, Section 4 goes into more detail on each component with some rationale but still mostly stating what the architecture is, rather than why. Finally, Section 5 justifies why each element of the solution was chosen (Section 5.1) and why these choices were different from other solutions (Section 5.2).
このドキュメントでは、3回のパスでのL4Sアーキテクチャについて説明しています。まず、セクション2の簡単な概要では、非常に高いレベルのアイデアを示し、最小限の根拠を持つ主要コンポーネントを述べています。これは、セクション3で続く用語の定義のコンテキストを提供し、ドキュメントの残りの部分の構造を説明することのみを目的としています。次に、セクション4は、理由ではなく、アーキテクチャが何であるかを主に述べています。最後に、セクション5では、ソリューションの各要素が選択された理由（セクション5.1）と、これらの選択が他のソリューションと異なる理由（セクション5.2）を正当化します。
After the architecture has been described, Section 6 clarifies its applicability by describing the applications and use cases that motivated the design, the challenges applying the architecture to various link technologies, and various incremental deployment models (including the two main deployment topologies, different sequences for incremental deployment, and various interactions with preexisting approaches). The document ends with the usual tailpieces, including extensive discussion of traffic policing and other security considerations in Section 8.
アーキテクチャが説明された後、セクション6は、設計の動機付け、さまざまなリンクテクノロジーにアーキテクチャを適用する課題、およびさまざまな増分展開モデル（2つの主要な展開トポロジを含むさまざまな展開モデルを含む、さまざまな展開モデルを含む、さまざまな展開モデルを説明することにより、その適用性を明確にします。増分展開、および既存のアプローチとのさまざまな相互作用）。ドキュメントは、セクション8のトラフィックポリシングやその他のセキュリティに関する考慮事項に関する広範な議論など、通常のテールピースで終わります。
Below, we outline the three main components to the L4S architecture: 1) the Scalable congestion control on the sending host; 2) the AQM at the network bottleneck; and 3) the protocol between them.
以下では、3つの主要なコンポーネントの概要をL4Sアーキテクチャに概説します。1）送信ホストのスケーラブルな輻輳制御。2）ネットワークボトルネックのAQM。3）それらの間のプロトコル。
But first, the main point to grasp is that low latency is not provided by the network; low latency results from the careful behaviour of the Scalable congestion controllers used by L4S senders. The network does have a role, primarily to isolate the low latency of the carefully behaving L4S traffic from the higher queuing delay needed by traffic with preexisting Classic behaviour. The network also alters the way it signals queue growth to the transport. It uses the Explicit Congestion Notification (ECN) protocol, but it signals the very start of queue growth immediately, without the smoothing delay typical of Classic AQMs. Because ECN support is essential for L4S, senders use the ECN field as the protocol that allows the network to identify which packets are L4S and which are Classic.
しかし、最初に、把握する主なポイントは、ネットワークによって低いレイテンシが提供されないことです。L4S送信者が使用するスケーラブルな混雑コントローラーの慎重な動作によると、低遅延が生じます。ネットワークには、主に、既存の古典的な動作を伴うトラフィックが必要とするより高いキューイング遅延からの慎重に動作するL4Sトラフィックの低下を隔離するための役割があります。ネットワークは、輸送へのキューの成長を示す方法も変えます。明示的な混雑通知（ECN）プロトコルを使用しますが、古典的なAQMSに典型的なスムージング遅延なしに、キューの成長のまさに始まりをすぐに示します。ECNサポートはL4に不可欠であるため、送信者はECNフィールドをプロトコルとして使用して、ネットワークがどのパケットであるかを識別でき、どのパケットがクラシックであるかを使用します。
1) Host:
1) ホスト：
Scalable congestion controls already exist. They solve the scaling problem with Classic congestion controls, such as Reno or CUBIC. Because flow rate has scaled since TCP congestion control was first designed in 1988, assuming the flow lasts long enough, 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 and [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.
スケーラブルなうっ血コントロールがすでに存在します。彼らは、リノやキュービックなどの古典的な混雑コントロールでスケーリングの問題を解決します。TCPの混雑制御が1988年に最初に設計されて以来、流量はスケーリングされているため、流れが十分に長く続くと仮定して、輻輳信号（損失またはECNマークのいずれであっても）の後に回復するには何百もの丸い旅行（および成長）が必要です。セクション5.1および[RFC3649]の例に示されています。したがって、キューイングと使用率の制御は非常に緩くなり、わずかな乱れ（例えば、新しいフローからの開始から）が達成されないようにします。
With a Scalable congestion control, 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 more robust to disturbances. The Scalable control used most widely (in controlled environments) is DCTCP [RFC8257], which has been implemented and deployed in Windows Server Editions (since 2012), in Linux, and in FreeBSD. Although DCTCP as-is functions well over wide-area round-trip times (RTTs), most implementations lack certain safety features that would be necessary for use outside controlled environments, like data centres (see Section 6.4.3). Therefore, Scalable congestion control needs to be implemented in TCP and other transport protocols (QUIC, Stream Control Transmission Protocol (SCTP), RTP/RTCP, RTP Media Congestion Avoidance Techniques (RMCAT), etc.). Indeed, between the present document being drafted and published, the following Scalable congestion controls were implemented: Prague over TCP and QUIC [PRAGUE-CC] [PragueLinux], an L4S variant of the RMCAT SCReAM controller [SCReAM-L4S], and the L4S ECN part of Bottleneck Bandwidth and Round-trip propagation time (BBRv2) [BBRv2] intended for TCP and QUIC transports.
スケーラブルな輻輳制御により、1つの輻輳信号から次の混雑信号までの平均時間（回復時間）までの平均時間は、流量スケールとして不変のままであり、他のすべての要因は等しい。これにより、流量が何であれ、キューイングと使用率に対する同じ程度の制御が維持され、高スループットが乱れに対してより堅牢であることを保証します。最も広く（制御された環境で）使用されるスケーラブルな制御は、DCTCP [RFC8257]であり、Windows Server Editions（2012年）、Linux、およびFreeBSDで実装および展開されています。DCTCP AS-ISは、広いエリアの往復時間（RTT）をはるかに超えて機能しますが、ほとんどの実装には、データセンターなどの外部制御環境を使用するために必要な特定の安全機能がありません（セクション6.4.3を参照）。したがって、スケーラブルな輻輳制御は、TCPおよびその他の輸送プロトコル（QUIC、ストリーム制御伝送プロトコル（SCTP）、RTP/RTCP、RTPメディア混雑回避技術（RMCAT）など）に実装する必要があります。実際、現在の文書が起草され、公開されている間に、次のスケーラブルな混雑コントロールが実装されました：TCPおよびQUIC [Prague-CC] [Praguelinux]、RMCAT Scream Controller [Scream-L4S]、およびL4SECN Bottleneckの帯域幅と往復伝播時間（BBRV2）[BBRV2]の一部は、TCPおよびQUIC輸送を目的としています。
2) Network:
2) 通信網：
L4S traffic needs to be isolated from the queuing latency of Classic traffic. One queue per application flow (FQ) is one way to achieve this, e.g., FQ-CoDel [RFC8290]. However, using just two queues is sufficient and does not require inspection of transport layer headers in the network, which is not always possible (see Section 5.2). With just two queues, it might seem impossible to know how much capacity to schedule for each queue without inspecting how many flows at any one time are using each. And it would be undesirable to arbitrarily divide access network capacity into two partitions. The Dual-Queue Coupled AQM was developed as a minimal complexity solution to this problem. It acts like a 'semi-permeable' membrane that partitions latency but not bandwidth. As such, the two queues are for transitioning from Classic to L4S behaviour, not bandwidth prioritization.
L4Sトラフィックは、古典的なトラフィックのキューイングレイテンシから分離する必要があります。アプリケーションフロー（FQ）ごとに1つのキューは、これを達成する1つの方法です。たとえば、FQ-Codel [RFC8290]。ただし、2つのキューを使用するだけで十分で、ネットワーク内の輸送層ヘッダーの検査は必要ありません。これは常に可能ではありません（セクション5.2を参照）。たった2つのキューで、一度に使用しているフローの数を検査せずに、各キューのスケジュール容量を知ることは不可能に思えるかもしれません。また、アクセスネットワーク容量を2つのパーティションに任意に分割することは望ましくありません。デュアルキュー結合AQMは、この問題に対する最小限の複雑さのソリューションとして開発されました。それは、帯域幅ではなく潜在性を分割する「半透視可能な」膜のように機能します。そのため、2つのキューは、帯域幅の優先順位付けではなく、クラシックの動作からL4Sの動作に移行するためのものです。
Section 4 gives a high-level explanation of how the per-flow queue (FQ) and DualQ variants of L4S work, and [RFC9332] gives a full explanation of the DualQ Coupled AQM framework. A specific marking algorithm is not mandated for L4S AQMs. Appendices of [RFC9332] give non-normative examples that have been implemented and evaluated and give recommended default parameter settings. It is expected that L4S experiments will improve knowledge of parameter settings and whether the set of marking algorithms needs to be limited.
セクション4では、L4S作業の流量ごとのキュー（FQ）とDualQバリアントがどのように機能し、[RFC9332]がどのようにDualQ結合されたAQMフレームワークの完全な説明を提供するかについての高レベルの説明を示します。L4S AQMSには特定のマーキングアルゴリズムが義務付けられていません。[RFC9332]の付録は、実装および評価された非規範的な例を示し、推奨されるデフォルトのパラメーター設定を提供します。L4S実験により、パラメーター設定の知識と、マーキングアルゴリズムのセットを制限する必要があるかどうかが期待されます。
3) Protocol:
3) プロトコル：
A sending host needs to distinguish L4S and Classic packets with an identifier so that the network can classify them into their separate treatments. The L4S identifier spec [RFC9331] concludes that all alternatives involve compromises, but the ECT(1) and Congestion Experienced (CE) codepoints of the ECN field represent a workable solution. As already explained, the network also uses ECN to immediately signal the very start of queue growth to the transport.
送信ホストは、ネットワークがそれらを個別の治療に分類できるように、識別子とL4とクラシックパケットを区別する必要があります。L4S識別子仕様[RFC9331]は、すべての代替品には妥協が含まれると結論付けていますが、ECNフィールドのECT（1）と経験豊富な（CE）コードポイントは実行可能なソリューションを表していると結論付けています。すでに説明されているように、ネットワークはECNを使用して、輸送のキューの成長のまさに開始を直ちに通知します。
Classic Congestion Control: A congestion control behaviour that can coexist with standard Reno [RFC5681] without causing significantly negative impact on its flow rate [RFC5033]. The scaling problem with Classic congestion control is explained, with examples, in Section 5.1 and in [RFC3649].
古典的な混雑制御：流量に大きな悪影響を与えることなく、標準のリノ[RFC5681]と共存できる混雑制御挙動[RFC5033]。古典的な混雑制御のスケーリング問題については、例を挙げて、セクション5.1および[RFC3649]で説明します。
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. 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 for TCP and QUIC [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], and the L4S variant of SCReAM for real-time media [SCReAM-L4S] [RFC8298]. See Section 4.3 of [RFC9331] for more explanation.
スケーラブルな混雑制御：1つの輻輳信号から次の輻輳信号までの平均時間（回復時間）までの平均時間が、流量スケールとして不変のままで、他のすべての要因が等しい場合。たとえば、DCTCPは、最近開発された他のスケーラブルな混雑コントロール、たとえば容赦ないTCP [容赦ない]、TCPおよびQUIC [Prague-CC] [Praguelinux]、BBRv2 [BBRV2]など、流量が何であれ、往復あたり2つの混雑信号を平均します。BBRV2] [BBR-CC]、およびリアルタイムメディアのScreamのL4Sバリアント[Scream-L4S] [RFC8298]。詳細については、[RFC9331]のセクション4.3を参照してください。
Classic Service: The Classic service is intended for all the congestion control behaviours that coexist with Reno [RFC5681] (e.g., Reno itself, CUBIC [RFC8312], Compound [CTCP], and TFRC [RFC5348]). The term 'Classic queue' means a queue providing the Classic service.
古典的なサービス：クラシックサービスは、Reno [RFC5681]（例えば、Reno自体、Cubic [RFC8312]、化合物[CTCP]、およびTFRC [RFC5348]と共存するすべての混雑制御行動を対象としています。「クラシックキュー」という用語は、クラシックサービスを提供するキューを意味します。
Low Latency, Low Loss, and Scalable throughput (L4S) service: The 'L4S' service is intended for traffic from Scalable congestion control algorithms, such as the Prague congestion control [PRAGUE-CC], which was derived from DCTCP [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 above (Relentless, SCReAM, etc.). The term 'L4S queue' means a queue providing the L4S service.
低遅延、低損失、スケーラブルスループット（L4S）サービス：「L4S」サービスは、DCTCP [RFC8257]から導出されたプラハ輻輳制御[Prague-CC]などのスケーラブルな混雑制御アルゴリズムからのトラフィックを対象としています。L4Sサービスは、単なるプラハよりも一般的なトラフィックを対象としています。これにより、上記の例（容赦ない、叫びなど）など、プラハと同様のスケーリング特性を持つ混雑コントロールのセットが進化します。「L4Sキュー」という用語は、L4Sサービスを提供するキューを意味します。
The terms Classic or L4S can also qualify other nouns, such as 'queue', 'codepoint', 'identifier', 'classification', 'packet', and 'flow'. For example, an L4S packet means a packet with an L4S identifier sent from an L4S congestion control.
クラシックまたはL4Sという用語は、「キュー」、「コードポイント」、「識別子」、「分類」、「パケット」、「フロー」など、他の名詞を認定することもできます。たとえば、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.).
クラシックサービスとL4Sサービスはどちらも、反応しないまたは応答性の低いトラフィックの割合にも対処できますが、L4Sの場合、そのレートはキューを構築しないほど十分にスムーズまたは低くなければなりません（例：DNS、Voice over IP（VoIP）、ゲーム同期データグラムなど）。
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プロトコルは非常に多くの異なる混雑制御挙動で使用されており、RENOがQUICなどの非TCPトランスポートで使用されているため、後者が不正確になっていることを考えると、「TCPフレンドリー」の代わりにRENOフレンドリーが使用されています。[RFC9000]。
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を明らかにする場合、「マーク」と呼ばれます。
Site: A home, mobile device, small enterprise, or campus where the network bottleneck is typically the access link to the site. Not all network arrangements fit this model, but it is a useful, widely applicable generalization.
サイト：ネットワークボトルネックが通常サイトへのアクセスリンクであるホーム、モバイルデバイス、中小企業、またはキャンパス。すべてのネットワーク配置がこのモデルに適合するわけではありませんが、それは有用で広く適用可能な一般化です。
Traffic Policing: Limiting traffic by dropping packets or shifting them to a lower service class (as opposed to introducing delay, which is termed 'traffic shaping'). Policing can involve limiting the average rate and/or burst size. Policing focused on limiting queuing but not the average flow rate is termed 'congestion policing', 'latency policing', 'burst policing', or 'queue protection' in this document. Otherwise, the term rate policing is used.
トラフィックポリシング：パケットをドロップしたり、より低いサービスクラスに移行したりすることでトラフィックを制限します（「トラフィックシェーピング」と呼ばれる遅延を導入するのではなく）。ポリシングには、平均レートおよび/またはバーストサイズの制限が含まれます。ポリシングは、キューイングの制限に焦点を当てていますが、平均流量は「混雑警察」、「レイテンシポリシング」、「バーストポリシング」、またはこのドキュメントの「キュー保護」と呼ばれます。それ以外の場合、用語レートポリシングが使用されます。
The L4S architecture is composed of the elements in the following three subsections.
L4Sアーキテクチャは、次の3つのサブセクションの要素で構成されています。
The L4S architecture involves: a) unassignment of the previous use of the identifier; b) reassignment of the same identifier; and c) optional further identifiers:
L4Sアーキテクチャには次のものが含まれます。a）識別子の以前の使用の割り当て。b）同じ識別子の再割り当て。c）オプションのさらなる識別子：
a. An essential aspect of a Scalable congestion control is the use of explicit congestion signals. Classic ECN [RFC3168] requires an ECN signal to be treated as equivalent to drop, both when it is generated in the network and when it is responded to by hosts. L4S needs networks and hosts to support a more fine-grained meaning for each ECN signal that is less severe than a drop, so that the L4S signals:
a. スケーラブルな混雑制御の重要な側面は、明示的な輻輳シグナルの使用です。古典的なECN [RFC3168]では、ネットワークで生成された場合とホストによって応答される場合の両方で、ECN信号をドロップに相当するものとして扱う必要があります。L4Sは、L4Sが信号するように、ドロップよりも重度ではない各ECN信号に対してより微調整された意味をサポートするためにネットワークとホストを必要としています。
* can be much more frequent and
* はるかに頻繁になる可能性があります
* can be signalled immediately, without the significant delay required to smooth out fluctuations in the queue.
* キューの変動を滑らかにするために必要な大きな遅延はなく、すぐに信号を送ることができます。
To enable L4S, the Standards Track Classic ECN spec [RFC3168] has had to be updated to allow L4S packets to depart from the 'equivalent-to-drop' constraint. [RFC8311] is a Standards Track update to relax specific requirements in [RFC3168] (and certain other Standards Track RFCs), which clears the way for the experimental changes proposed for L4S. Also, the ECT(1) codepoint was previously assigned as the experimental ECN nonce [RFC3540], which [RFC8311] recategorizes as historic to make the codepoint available again.
L4Sを有効にするために、L4Sパケットが「同等のドロップ」制約から離れることを可能にするために、標準はClassic ECN Spec [RFC3168]を更新する必要がありました。[RFC8311]は、[RFC3168]の特定の要件を緩和するための標準トラックアップデート（および特定の他の標準を追跡）であり、L4Sに提案された実験的変更の道をクリアします。また、ECT（1）CodePointは以前に実験的なECN NonCe [RFC3540]として割り当てられていました。
b. [RFC9331] specifies that ECT(1) is used as the identifier to classify L4S packets into a separate treatment from Classic packets. This satisfies the requirement for identifying an alternative ECN treatment in [RFC4774].
b. [RFC9331]は、ECT（1）が識別子として使用され、L4Sパケットを古典的なパケットから個別の処理に分類することを指定します。これは、[RFC4774]の代替ECN治療を特定するための要件を満たします。
The CE codepoint is used to indicate Congestion Experienced by both L4S and Classic treatments. This raises the concern that a Classic AQM earlier on the path might have marked some ECT(0) packets as CE. Then, these packets will be erroneously classified into the L4S queue. Appendix B of [RFC9331] explains why five unlikely eventualities all have to coincide for this to have any detrimental effect, which even then would only involve a vanishingly small likelihood of a spurious retransmission.
CE CodePointは、L4と古典的な治療法の両方が経験した混雑を示すために使用されます。これにより、パス上の古典的なAQMがECT（0）パケットをCEとしてマークした可能性があるという懸念が高まります。次に、これらのパケットは誤ってL4Sキューに分類されます。[RFC9331]の付録Bは、なぜ5つの可能性の低い不測の事態が、これが有害な効果をもたらすために一致しなければならない理由を説明しています。
c. A network operator might wish to include certain unresponsive, non-L4S traffic in the L4S queue if it is deemed to be paced smoothly enough and at a low enough rate not to build a queue, for instance, VoIP, low rate datagrams to sync online games, relatively low rate application-limited traffic, DNS, Lightweight Directory Access Protocol (LDAP), etc. This traffic would need to be tagged with specific identifiers, e.g., a low-latency Diffserv codepoint such as Expedited Forwarding (EF) [RFC3246], Non-Queue-Building (NQB) [NQB-PHB], or operator-specific identifiers.
c. ネットワークオペレーターは、L4Sキューに十分なスムーズにペースを合わせているとみなされ、キューを構築しないほど十分に低いレートであるとみなされる場合、L4Sキューに特定の無反応の非L4Sトラフィックを含めることを望む場合があります。ゲーム、比較的低いレートのアプリケーション制限トラフィック、DNS、軽量ディレクトリアクセスプロトコル（LDAP）など。このトラフィックは、Expedited Forwarding（EF）[RFC3246などの低遅量DiffServ CodePointなどの特定の識別子でタグ付けする必要があります。]、非キュービルディング（NQB）[NQB-PHB]、または演算子固有の識別子。
The L4S architecture aims to provide low latency without the _need_ for per-flow operations in network components. Nonetheless, the architecture does not preclude per-flow solutions. The following bullets describe the known arrangements: a) the DualQ Coupled AQM with an L4S AQM in one queue coupled from a Classic AQM in the other; b) per-flow queues with an instance of a Classic and an L4S AQM in each queue; and c) Dual queues with per-flow AQMs but no per-flow queues:
L4Sアーキテクチャは、ネットワークコンポーネントでのフローごとの操作に_need_なしで低レイテンシを提供することを目的としています。それにもかかわらず、アーキテクチャは流量あたりのソリューションを排除しません。次の弾丸は、既知の配置について説明しています。a）Dualq結合されたAQMと、1つのキューにあるL4S AQMと、もう1つのClassic AQMから結合されたキュー。b）各キューにクラシックとL4S AQMのインスタンスを使用したフローごとのキュー。およびc）流量あたりのAQMSを使用したデュアルキューですが、フローごとのキューはありません。
a. The Dual-Queue Coupled AQM (illustrated in Figure 1) achieves the 'semi-permeable' membrane property mentioned earlier as follows:
a. デュアルキュー結合AQM（図1に示す）は、次のように前述の「半透過性」膜特性を実現します。
* Latency isolation: Two separate queues are used to isolate L4S queuing delay from the larger queue that Classic traffic needs to maintain full utilization.
* レイテンシの分離：2つの別々のキューを使用して、L4Sキューイングの遅延を、完全な利用を維持するために必要なより大きなキューからの遅延を隔離します。
* Bandwidth pooling: The two queues act as if they are a single pool of bandwidth in which flows of either type get roughly equal throughput without the scheduler needing to identify any flows. This is achieved by having an AQM in each queue, but the Classic AQM provides a congestion signal to both queues in a manner that ensures a consistent response from the two classes of congestion control. Specifically, the Classic AQM generates a drop/mark probability based on congestion in its own queue, which it uses both to drop/mark packets in its own queue and to affect the marking probability in the L4S queue. The strength of the coupling of the congestion signalling between the two queues is enough to make the L4S flows slow down to leave the right amount of capacity for the Classic flows (as they would if they were the same type of traffic sharing the same queue).
* 帯域幅のプーリング：2つのキューは、スケジューラがフローを識別する必要がなくても、どちらのタイプのフローがほぼ等しいスループットを得る帯域幅の単一のプールであるかのように機能します。これは、各キューにAQMを持つことで達成されますが、クラシックAQMは、2つのクラスの混雑制御から一貫した応答を保証する方法で両方のキューに輻輳信号を提供します。具体的には、クラシックAQMは、独自のキュー内の輻輳に基づいてドロップ/マークの確率を生成します。これは、独自のキューにパケットをドロップ/マークし、L4Sキューのマーク確率に影響を与えるために使用します。2つのキュー間の輻輳シグナル伝達の結合の強度は、L4Sフローを遅くしてクラシックフローの適切な量の容量を残すのに十分です（同じタイプのトラフィックを共有している場合と同じように）。
Then, the scheduler can serve the L4S queue with priority (denoted by the '1' on the higher priority input), because the L4S traffic isn't offering up enough traffic to use all the priority that it is given. Therefore:
次に、スケジューラは、L4Sトラフィックが指定されているすべての優先度を使用するのに十分なトラフィックを提供していないため、優先度を持ってL4Sキュー（より高い優先度入力で「1」で示される）を提供できます。したがって：
* for latency isolation on short timescales (sub-round-trip), the prioritization of the L4S queue protects its low latency by allowing bursts to dissipate quickly;
* 短いタイムスケール（サブラウンドトリップ）での遅延分離の場合、L4Sキューの優先順位付けにより、バーストが迅速に消散できるようにすることで、低遅延を保護します。
* but for bandwidth pooling on longer timescales (round-trip and longer), the Classic queue creates an equal and opposite pressure against the L4S traffic to ensure that neither has priority when it comes to bandwidth -- the tension between prioritizing L4S and coupling the marking from the Classic AQM results in approximate per-flow fairness.
* しかし、より長いタイムスケール（往復以降）で帯域幅プーリングの場合、クラシックキューはL4Sトラフィックに対して等しく反対の圧力を生み出し、帯域幅に関してどちらも優先されないことを保証します。古典的なAQMから、概算あたりの公平性が発生します。
To protect against the prioritization of persistent L4S traffic deadlocking the Classic queue for a while in some implementations, it is advisable for the priority to be conditional, not strict (see Appendix A of the DualQ spec [RFC9332]).
いくつかの実装でしばらくの間、古典的なキューを締め切る永続的なL4Sトラフィックの優先順位付けから保護するために、優先順位は厳格ではなく条件付きであることをお勧めします（DUALQ仕様の付録Aを参照[RFC9332]を参照）。
When there is no Classic traffic, the L4S queue's own AQM comes into play. It starts congestion marking with a very shallow queue, so L4S traffic maintains very low queuing delay.
古典的なトラフィックがない場合、L4Sキュー自身のAQMが作用します。非常に浅いキューで輻輳マーキングを開始するため、L4Sトラフィックは非常に低いキューイング遅延を維持します。
If either queue becomes persistently overloaded, drop of some ECN-capable packets is introduced, as recommended in Section 7 of the ECN spec [RFC3168] and Section 4.2.1 of the AQM recommendations [RFC7567]. The trade-offs with different approaches are discussed in Section 4.2.3 of the DualQ spec [RFC9332] (not shown in the figure here).
いずれかのキューが永続的に過負荷になった場合、ECN仕様[RFC3168]のセクション7およびAQM推奨[RFC7567]のセクション4.2.1で推奨されるように、いくつかのECN対応パケットのドロップが導入されます。さまざまなアプローチを備えたトレードオフについては、DUALQ仕様[RFC9332]のセクション4.2.3で説明されています（ここの図には示されていません）。
The Dual-Queue Coupled AQM has been specified as generically as possible [RFC9332] without specifying the particular AQMs to use in the two queues so that designers are free to implement diverse ideas. Informational appendices in that document give pseudocode examples of two different specific AQM approaches: one called DualPI2 (pronounced Dual PI Squared) [DualPI2Linux] that uses the PI2 variant of PIE and a zero-config variant of Random Early Detection (RED) called Curvy RED. A DualQ Coupled AQM based on PIE has also been specified and implemented for Low Latency DOCSIS [DOCSIS3.1].
デュアルキュー結合AQMは、2つのキューで使用する特定のAQMを指定することなく、可能な限り一般的に[RFC9332]を指定して、デザイナーが自由に多様なアイデアを実装できるように指定されています。そのドキュメントの情報付録は、2つの異なる特定のAQMアプローチの擬似コード例を示しています：1つはDualPi2（DualPi Squaredと発音）[DualPi2linux]と呼ばれるPIEのPI2バリアントと、REDと呼ばれるランダムアーリー検出のゼロコンフィグバリアント（赤）を使用します。。PIEに基づいたDualQ結合AQMも指定されており、低レイテンシDOCSIS [DOCSIS3.1]に実装されています。
(3) (2)
.-------^------..------------^------------------.
,-(1)-----. _____
; ________ : L4S -------. | |
:|Scalable| : _\ ||__\_|mark |
:| sender | : __________ / / || / |_____|\ _________
:|________|\; | |/ -------' ^ \1|condit'nl|
`---------'\_| IP-ECN | Coupling : \|priority |_\
________ / |Classifier| : /|scheduler| /
|Classic |/ |__________|\ -------. __:__ / |_________|
| sender | \_\ || | ||__\_|mark/|/
|________| / || | || / |drop |
Classic -------' |_____|
(1) Scalable sending host (2) Isolation in separate network queues (3) Packet identification protocol
(1) スケーラブル送信ホスト（2）別々のネットワークキュー（3）パケット識別プロトコルでの分離
Figure 1: Components of an L4S DualQ Coupled AQM Solution
図1：L4Sデュアルク結合AQMソリューションのコンポーネント
b. Per-Flow Queues and AQMs: A scheduler with per-flow queues, such as FQ-CoDel or FQ-PIE, can be used for L4S. For instance, within each queue of an FQ-CoDel system, as well as a CoDel AQM, there is typically also the option of ECN marking at an immediate (unsmoothed) shallow threshold to support use in data centres (see Section 5.2.7 of the FQ-CoDel spec [RFC8290]). In Linux, this has been modified so that the shallow threshold can be solely applied to ECT(1) packets [FQ_CoDel_Thresh]. Then, if there is a flow of Not-ECT or ECT(0) packets in the per-flow queue, the Classic AQM (e.g., CoDel) is applied; whereas, if there is a flow of ECT(1) packets in the queue, the shallower (typically sub-millisecond) threshold is applied. In addition, ECT(0) and Not-ECT packets could potentially be classified into a separate flow queue from ECT(1) and CE packets to avoid them mixing if they share a common flow identifier (e.g., in a VPN).
b. FLOW PHEUSおよびAQMS：FQコデルやFQ-PIEなどのフローごとのキューを備えたスケジューラは、L4に使用できます。たとえば、FQコデルシステムの各キューとコーデルAQM内で、通常、データセンターでの使用をサポートするための即時（滑らかな）浅い浅いしきい値でのECNマーキングのオプションもあります（セクション5.2.7を参照してください。FQコデル仕様[RFC8290]）。Linuxでは、これが変更されているため、浅いしきい値をECT（1）パケット[FQ_Codel_Thresh]にのみ適用できます。次に、フローごとのキューにnot-ectまたはect（0）パケットのフローがある場合、クラシックAQM（例：Codel）が適用されます。一方、キューにECT（1）パケットのフローがある場合、浅い（通常はサブミリ秒）しきい値が適用されます。さらに、ECT（0）およびNOT-ECTパケットは、ECT（1）およびCEパケットから個別のフローキューに分類される可能性があります。
c. Dual queues but per-flow AQMs: It should also be possible to use dual queues for isolation but with per-flow marking to control flow rates (instead of the coupled per-queue marking of the Dual-Queue Coupled AQM). One of the two queues would be for isolating L4S packets, which would be classified by the ECN codepoint. Flow rates could be controlled by flow-specific marking. The policy goal of the marking could be to differentiate flow rates (e.g., [Nadas20], which requires additional signalling of a per-flow 'value') or to equalize flow rates (perhaps in a similar way to Approx Fair CoDel [AFCD] [CODEL-APPROX-FAIR] but with two queues not one).
c. デュアルキューですが、流量あたりのAQMS：デュアルキューを分離に使用することも可能ですが、流量を制御するためにフローごとのマーキングを使用すると（デュアルキュー結合AQMのキューごとのマークが結合されています）。2つのキューの1つは、ECN CodePointによって分類されるL4Sパケットの分離です。流量は、フロー固有のマーキングによって制御できます。マーキングのポリシー目標は、流量（たとえば[NADAS20]）を区別することです。これには、流量あたりの「値」の追加のシグナル伝達が必要です）、または流量を均等化することです（おそらく、Fair Codelと同様の方法で[AFCD][Codel-Approx-Fair]しかし、2つのキューが1つではありません）。
Note that, whenever the term 'DualQ' is used loosely without saying whether marking is per queue or per flow, it means a dual-queue AQM with per-queue marking.
「dualq」という用語が、キューごとにマーキングがフローごとであるか、フローごとにかかわらずにゆるく使用される場合はいつでも、それはキューごとのマーキングを備えたデュアルキューAQMを意味することに注意してください。
The L4S architecture includes two main mechanisms in the end host that we enumerate next:
L4Sアーキテクチャには、次に列挙する最後のホストに2つの主要なメカニズムが含まれています。
a. Scalable congestion control at the sender: Section 2 defines a Scalable congestion control as one 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. DCTCP is the most widely used example. It has been documented as an informational record of the protocol currently in use in controlled environments [RFC8257]. A list of safety and performance improvements for a Scalable congestion control to be usable on the public Internet has been drawn up (see the so-called 'Prague L4S requirements' in Appendix A of [RFC9331]). The subset that involve risk of harm to others have been captured as normative requirements in Section 4 of [RFC9331]. TCP Prague [PRAGUE-CC] has been implemented in Linux as a reference implementation to address these requirements [PragueLinux].
a. 送信者でのスケーラブルな輻輳制御：セクション2では、スケーラブルな輻輳制御を、1つの輻輳信号から次の輻輳信号までの平均時間（回復時間）までの平均時間を、流量スケールとして不変のままで、他のすべての要因が等しいものとして定義されています。DCTCPは最も広く使用されている例です。制御された環境で現在使用されているプロトコルの情報記録として文書化されています[RFC8257]。公開インターネットで使用可能なスケーラブルな混雑制御の安全性とパフォーマンスの改善のリストが作成されました（[RFC9331]の付録Aのいわゆる「プラハL4S要件」を参照）。他の人への危害のリスクを伴うサブセットは、[RFC9331]のセクション4で規範的要件として捉えられています。TCP Prague [Prague-CC]は、これらの要件に対処するための参照実装としてLinuxに実装されています[Praguelinux]。
Transport protocols other than TCP use various congestion controls that are designed to be friendly with Reno. Before they can use the L4S service, they will need to be updated to implement a Scalable congestion response, which they will have to indicate by using the ECT(1) codepoint. Scalable variants are under consideration for more recent transport protocols (e.g., QUIC), and the L4S ECN part of BBRv2 [BBRv2] [BBR-CC] is a Scalable congestion control intended for the TCP and QUIC transports, amongst others. Also, an L4S variant of the RMCAT SCReAM controller [RFC8298] has been implemented [SCReAM-L4S] for media transported over RTP.
TCP以外の輸送プロトコルは、リノとフレンドリーになるように設計されたさまざまな混雑制御を使用します。L4Sサービスを使用する前に、スケーラブルな輻輳応答を実装するために更新する必要があります。これは、ECT（1）CodePointを使用して示す必要があります。スケーラブルなバリアントは、より最近の輸送プロトコル（例：QUIC）について考慮されており、BBRV2 [BBRV2] [BBR-CC]のL4S ECN部分は、とりわけTCPおよびQUICトランスポートを対象としたスケーラブルな輻輳制御です。また、RMCAT Scream Controller [RFC8298]のL4Sバリアントが、RTPを介して輸送されるメディア用に[Scream-L4S]に実装されています。
Section 4.3 of the L4S ECN spec [RFC9331] defines Scalable congestion control in more detail and specifies the requirements that an L4S Scalable congestion control has to comply with.
L4S ECN仕様[RFC9331]のセクション4.3は、スケーラブルな輻輳制御をより詳細に定義し、L4Sスケーラブル輻輳制御が従わなければならない要件を指定します。
b. The ECN feedback in some transport protocols is already sufficiently fine-grained for L4S (specifically DCCP [RFC4340] and QUIC [RFC9000]). But others either require updates or are in the process of being updated:
b. 一部の輸送プロトコルのECNフィードバックは、L4S（具体的にはDCCP [RFC4340]およびQUIC [RFC9000]）ですでに十分に細粒化されています。しかし、他の人は更新を必要とするか、更新の過程にあります。
* For the case of TCP, the feedback protocol for ECN embeds the assumption from Classic ECN [RFC3168] that an ECN mark is equivalent to a drop, making it unusable for a Scalable TCP. Therefore, the implementation of TCP receivers will have to be upgraded [RFC7560]. Work to standardize and implement more accurate ECN feedback for TCP (AccECN) is in progress [ACCECN] [PragueLinux].
* TCPの場合、ECNのフィードバックプロトコルは、ECNマークがドロップと同等であるという古典的なECN [RFC3168]からの仮定を埋め込んでおり、スケーラブルなTCPで使用できません。したがって、TCP受信機の実装をアップグレードする必要があります[RFC7560]。TCP（accecn）のより正確なECNフィードバックを標準化して実装する作業が進行中です[accecn] [praguelinux]。
* ECN feedback was only roughly sketched in the appendix of the now obsoleted second specification of SCTP [RFC4960], while a fuller specification was proposed in a long-expired document [ECN-SCTP]. A new design would need to be implemented and deployed before SCTP could support L4S.
* ECNフィードバックは、SCTP [RFC4960]の現在廃止された2番目の仕様の付録で大まかにスケッチされていましたが、長期にわたるドキュメント[ECN-SCTP]でフラー仕様が提案されました。SCTPがL4をサポートする前に、新しい設計を実装および展開する必要があります。
* For RTP, sufficient ECN feedback was defined in [RFC6679], but [RFC8888] defines the latest Standards Track improvements.
* RTPの場合、[RFC6679]で十分なECNフィードバックが定義されていましたが、[RFC8888]は最新の標準トラックの改善を定義しています。
Explicit congestion signalling (protocol): Explicit congestion signalling is a key part of the L4S approach. In contrast, use of drop as a congestion signal creates tension because drop is both an impairment (less would be better) and a useful signal (more would be better):
明示的な混雑シグナル伝達（プロトコル）：明示的な輻輳シグナル伝達は、L4Sアプローチの重要な部分です。対照的に、落下が減損（より少ない方が良い）と有用な信号の両方であるため、輻輳信号としてのドロップを使用すると張力が生じます。
* Explicit congestion signals can be used many times per round trip to keep tight control without any impairment. Under heavy load, even more explicit signals can be applied so that the queue can be kept short whatever the load. In contrast, Classic AQMs have to introduce very high packet drop at high load to keep the queue short. By using ECN, an L4S congestion control's sawtooth reduction can be smaller and therefore return to the operating point more often, without worrying that more sawteeth will cause more signals. The consequent smaller amplitude sawteeth fit between an empty queue and a very shallow marking threshold (~1 ms in the public Internet), so queue delay variation can be very low, without risk of underutilization.
* 明示的な混雑信号は、往復あたり何度も使用して、障害なしに厳しい制御を維持することができます。重い負荷の下では、さらに明示的な信号を適用できるため、荷重が何であれ、キューを短く保つことができます。対照的に、クラシックAQMSは、キューを短く保つために、高負荷で非常に高いパケットドロップを導入する必要があります。ECNを使用することにより、L4Sの混雑制御の鋸歯状の削減は小さくなる可能性があるため、より多くの鋸が多くの信号を引き起こすことを心配することなく、より頻繁に動作点に戻ります。その結果、空のキューと非常に浅いマーキングのしきい値（パブリックインターネットでは〜1ms）の間にはより小さな振幅の鋸歯状が適合するため、キューの遅延変動は、十分に活用されるリスクなしに非常に低くなります。
* Explicit congestion signals can be emitted immediately to track fluctuations of the queue. L4S shifts smoothing from the network to the host. The network doesn't know the round-trip times (RTTs) of any of the flows. So if the network is responsible for smoothing (as in the Classic approach), it has to assume a worst case RTT, otherwise long RTT flows would become unstable. This delays Classic congestion signals by 100-200 ms. In contrast, each host knows its own RTT. So, in the L4S approach, the host can smooth each flow over its own RTT, introducing no more smoothing delay than strictly necessary (usually only a few milliseconds). A host can also choose not to introduce any smoothing delay if appropriate, e.g., during flow start-up.
* 明示的なうっ血信号をすぐに放出して、キューの変動を追跡できます。L4Sは、ネットワークからホストに滑らかにシフトします。ネットワークは、フローのいずれの往復時間（RTT）を知りません。したがって、ネットワークが（古典的なアプローチのように）スムージングの責任がある場合、最悪のケースRTTを想定する必要があります。そうでなければ、長いRTTフローは不安定になります。これにより、古典的な輻輳シグナルが100〜200ミリ秒遅くなります。対照的に、各ホストは独自のRTTを知っています。したがって、L4Sアプローチでは、ホストはそれぞれのフローを独自のRTT上のフローを滑らかにすることができ、厳密に必要なほどスムージング遅延（通常は数ミリ秒だけ）を導入できます。ホストは、必要に応じてスムージング遅延を導入しないことを選択することもできます。たとえば、フローの起動中に。
Neither of the above are feasible if explicit congestion signalling has to be considered 'equivalent to drop' (as was required with Classic ECN [RFC3168]), because drop is an impairment as well as a signal. So drop cannot be excessively frequent, and drop cannot be immediate; otherwise, too many drops would turn out to have been due to only a transient fluctuation in the queue that would not have warranted dropping a packet in hindsight. Therefore, in an L4S AQM, the L4S queue uses a new L4S variant of ECN that is not equivalent to drop (see Section 5.2 of the L4S ECN spec [RFC9331]), while the Classic queue uses either Classic ECN [RFC3168] or drop, which are still equivalent to each other.
ドロップは障害と信号であるため、明示的な混雑シグナル伝達を「ドロップに相当する」と見なされなければならない場合、上記のどちらも実現可能ではありません（古典的なECN [RFC3168]で必要でした）。したがって、ドロップを過度に頻繁にすることはできず、ドロップを即座にすることはできません。そうしないと、あまりにも多くのドロップが、後知恵でパケットを落とすことを保証しないであろうキューの一時的な変動だけが原因であることが判明しました。したがって、L4S AQMでは、L4Sキューはドロップと同等ではないECNの新しいL4Sバリアントを使用します（L4S ECN Spec [RFC9331]のセクション5.2を参照）。、それはまだ互いに同等です。
Before Classic ECN was standardized, there were various proposals to give an ECN mark a different meaning from drop. However, there was no particular reason to agree on any one of the alternative meanings, so 'equivalent to drop' was the only compromise that could be reached. [RFC3168] contains a statement that:
古典的なECNが標準化される前に、ECNマークにドロップとは異なる意味を与えるというさまざまな提案がありました。ただし、代替の意味のいずれかに同意する特別な理由はなかったため、「ドロップに相当する」が到達できる唯一の妥協点でした。[RFC3168]には次の声明が含まれています。
An environment where all end nodes were ECN-Capable could allow new criteria to be developed for setting the CE codepoint, and new congestion control mechanisms for end-node reaction to CE packets. However, this is a research issue, and as such is not addressed in this document.
すべてのエンドノードがECN対応である環境により、CEコードポイントを設定するための新しい基準を開発できるようになり、CEパケットに対するエンドノード反応のための新しい輻輳制御メカニズムが開発されます。ただし、これは研究の問題であり、この文書では対処されていません。
Latency isolation (network): L4S congestion controls keep queue delay low, whereas Classic congestion controls need a queue of the order of the RTT to avoid underutilization. One queue cannot have two lengths; therefore, L4S traffic needs to be isolated in a separate queue (e.g., DualQ) or queues (e.g., FQ).
Latency Isolation（ネットワーク）：L4S混雑制御により、キューの遅延が低くなりますが、古典的な混雑制御には、十分に活用されないようにRTTの順序のキューが必要です。1つのキューには2つの長さがありません。したがって、L4Sトラフィックは、別のキュー（DualQなど）またはキュー（FQなど）で分離する必要があります。
Coupled congestion notification: Coupling the congestion notification between two queues as in the DualQ Coupled AQM is not necessarily essential, but it is a simple way to allow senders to determine their rate packet by packet, rather than be overridden by a network scheduler. An alternative is for a network scheduler to control the rate of each application flow (see the discussion in Section 5.2).
結合輻輳通知：DualQ結合されたAQMのように2つのキュー間の混雑通知を結合することは必ずしも必ずしも必ずしも不可欠ではありませんが、ネットワークスケジューラーによってオーバーライドされるのではなく、送信者がパケットでレートパケットを決定できるようにする簡単な方法です。別の方法は、ネットワークスケジューラが各アプリケーションフローのレートを制御することです（セクション5.2の説明を参照）。
L4S packet identifier (protocol): Once there are at least two treatments in the network, hosts need an identifier at the IP layer to distinguish which treatment they intend to use.
L4Sパケット識別子（プロトコル）：ネットワークに少なくとも2つの処理が行われると、ホストはIPレイヤーで識別子を必要として、使用する治療を区別します。
Scalable congestion notification: A Scalable congestion control in the host keeps the signalling frequency from the network high, whatever the flow rate, so that queue delay variations can be small when conditions are stable, and rate can track variations in available capacity as rapidly as possible otherwise.
スケーラブルな輻輳通知：ホストのスケーラブルな輻輳制御により、フロー率が何であれ、ネットワークからシグナリング周波数を高く保ちます。そうでなければ。
Low loss: Latency is not the only concern of L4S. The 'Low Loss' part of the name denotes that L4S generally achieves zero congestion loss due to its use of ECN. Otherwise, loss would itself cause delay, particularly for short flows, due to retransmission delay [RFC2884].
低損失：L4の懸念は唯一の潜在ではありません。名前の「低損失」部分は、L4SがECNの使用により一般的に混雑損失がゼロになることを示しています。それ以外の場合、再送信の遅延により、特に短いフローの場合、損失自体が遅延を引き起こします[RFC2884]。
Scalable throughput: 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 Reno-friendly congestion control algorithms [RFC3649]. It was known when TCP congestion avoidance was first developed in 1988 that it would not scale to high bandwidth-delay products (see footnote 6 in [TCP-CA]). Today, regular broadband flow rates over WAN distances are already beyond the scaling range of Classic Reno congestion control. So 'less unscalable' CUBIC [RFC8312] and Compound [CTCP] variants of TCP have been successfully deployed. However, these are now approaching their scaling limits.
スケーラブルなスループット：名前の「スケーラブルなスループット」部分は、スケーラブル鬱血コントロールの流量あたりのスループットが無期限にスケーリングする必要があることを示しています。1988年にTCPの混雑回避が最初に開発されたときに、高帯域幅遅延製品に拡大しないことが知られていました（[TCP-CA]の脚注6を参照）。今日、WAN距離にわたる定期的なブロードバンド流量は、すでに古典的なリノ輻輳制御のスケーリング範囲を超えています。したがって、TCPの「非衝撃性の低い」立方[RFC8312]および化合物[CTCP]バリアントは正常に展開されています。ただし、これらは現在、スケーリング制限に近づいています。
For instance, we will consider a scenario with a maximum RTT of 30 ms at the peak of each sawtooth. As Reno packet rate scales 8 times from 1,250 to 10,000 packet/s (from 15 to 120 Mb/s with 1500 B packets), the time to recover from a congestion event rises proportionately by 8 times as well, from 422 ms to 3.38 s. It is clearly problematic for a congestion control to take multiple seconds to recover from each congestion event. CUBIC [RFC8312] was developed to be less unscalable, but it is approaching its scaling limit; with the same max RTT of 30 ms, at 120 Mb/s, CUBIC is still fully in its Reno-friendly mode, so it takes about 4.3 s to recover. However, once flow rate scales by 8 times again to 960 Mb/s it enters true CUBIC mode, with a recovery time of 12.2 s. From then on, each further scaling by 8 times doubles CUBIC's recovery time (because the cube root of 8 is 2), e.g., at 7.68 Gb/ s, the recovery time is 24.3 s. In contrast, a Scalable congestion control like DCTCP or Prague induces 2 congestion signals per round trip on average, which remains invariant for any flow rate, keeping dynamic control very tight.
たとえば、各鋸歯状のピーク時に最大RTTが30ミリ秒のシナリオを検討します。リノパケットレートが1,250〜10,000パケット/s（1500 Bパケットで15〜120 MB/s）の8回スケーリングされるため、輻輳イベントから回復する時間は、422ミリ秒から3.38秒まで8倍も上昇します。混雑コントロールが各混雑イベントから回復するのに複数秒かかることは明らかに問題です。Cubic [rfc8312]は、より少ない無効化できないように開発されましたが、スケーリング制限に近づいています。同じ最大RTTが30ミリ秒の120 MB/sで、Cubicはまだリノフレンドリーモードであるため、回復するには約4.3秒かかります。ただし、流量が再び960 MB/sに8倍スケーリングすると、12.2秒の回復時間で真の立方モードに入ります。それ以降、さらに8倍のスケーリングを2倍のCubicの回復時間（8のキューブルートが2であるため）、たとえば7.68 GB/ sで、回復時間は24.3秒です。対照的に、DCTCPやプラハのようなスケーラブルな混雑制御は、平均して往復あたり2つの混雑信号を誘導します。これは、あらゆる流量に対して不変のままであり、動的制御を非常にタイトに保ちます。
For a feel of where the global average lone-flow download sits on this scale at the time of writing (2021), according to [BDPdata], the global average fixed access capacity was 103 Mb/s in 2020 and the average base RTT to a CDN was 25 to 34 ms in 2019. Averaging of per-country data was weighted by Internet user population (data collected globally is necessarily of variable quality, but the paper does double-check that the outcome compares well against a second source). So a lone CUBIC flow would at best take about 200 round trips (5 s) to recover from each of its sawtooth reductions, if the flow even lasted that long. This is described as 'at best' because it assumes everyone uses an AQM, whereas in reality, most users still have a (probably bloated) tail-drop buffer. In the tail-drop case, the likely average recovery time would be at least 4 times 5 s, if not more, because RTT under load would be at least double that of an AQM, and the recovery time of Reno-friendly flows depends on the square of RTT.
[BDPDATA]によると、執筆時点（2021年）にグローバルな平均孤独なフローダウンロードがこのスケールにある場所の感触については、2020年には世界平均固定アクセス容量が103 MB/s、平均RTTはCDNは2019年の25〜34ミリ秒でした。国ごとのデータの平均化は、インターネットユーザー人口によって重み付けされていました（グローバルに収集されたデータは必然的にさまざまな品質ですが、このペーパーは結果が2番目のソースとよく比較されることを再確認します）。したがって、孤独な立方体の流れは、せいぜい約200ラウンド旅行（5秒）をかけて、その流れが長く続いた場合、それぞれの通路削減から回復します。これは、誰もがAQMを使用すると仮定しているため、「せいぜい」と説明されていますが、実際には、ほとんどのユーザーはまだ（おそらく肥大化した）テールドロップバッファーを持っています。テールドロップの場合、RTTが少なくともAQMの2倍になり、リノにやさしいフローの回復時間は依存するため、平均回復時間は少なくとも4倍ではありません。RTTの正方形。
Although work on scaling congestion controls tends to start with TCP as the transport, the above is not intended to exclude other transports (e.g., SCTP and QUIC) or less elastic algorithms (e.g., RMCAT), which all tend to adopt the same or similar developments.
スケーリングの混雑コントロールの作業は輸送としてTCPから始まる傾向がありますが、上記は他の輸送（SCTPやQUICなど）を除外することを意図していません。開発。
All the following approaches address some part of the same problem space as L4S. In each case, it is shown that L4S complements them or improves on them, rather than being a mutually exclusive alternative:
次のすべてのアプローチは、L4と同じ問題空間の一部に対応しています。いずれの場合も、相互に排他的な代替品ではなく、L4Sがそれらを補完または改善することが示されています。
Diffserv: Diffserv addresses the problem of bandwidth apportionment for important traffic as well as queuing latency for delay-sensitive traffic. Of these, L4S solely addresses the problem of queuing latency. Diffserv will still be necessary where important traffic requires priority (e.g., for commercial reasons or for protection of critical infrastructure traffic) -- see [L4S-DIFFSERV]. Nonetheless, the L4S approach can provide low latency for all traffic within each Diffserv class (including the case where there is only the one default Diffserv class).
diffserv：diffservは、重要なトラフィックの帯域幅配分の問題と、遅延に敏感なトラフィックの待ち行列の問題に対処します。これらのうち、L4は、キューイングレイテンシの問題にのみ対処しています。重要なトラフィックが優先順位を必要とする場合（たとえば、商業的理由や重要なインフラストラクチャトラフィックの保護のために）、[L4S-Diffserv]を参照してください。それにもかかわらず、L4Sアプローチは、各diffservクラス内のすべてのトラフィックに対して低レイテンシを提供できます（デフォルトのDiffServクラスのみがある場合を含む）。
Also, Diffserv can only provide a latency benefit if a small subset of the traffic on a bottleneck link requests low latency. As already explained, it has no effect when all the applications in use at one time at a single site (e.g., a home, small business, or mobile device) require low latency. In contrast, because L4S works for all traffic, it needs none of the management baggage (traffic policing or traffic contracts) associated with favouring some packets over others. This lack of management baggage ought to give L4S a better chance of end-to-end deployment.
また、diffservは、ボトルネックリンクのトラフィックの小さなサブセットが低レイテンシを要求した場合にのみ、遅延メリットを提供できます。すでに説明されているように、単一のサイトで一度に使用されているすべてのアプリケーション（家庭、中小企業、モバイルデバイスなど）が低いレイテンシーを必要とする場合、それは効果がありません。対照的に、L4Sはすべてのトラフィックで機能するため、他のパケットよりも一部のパケットを支持することに関連する管理手荷物（交通警察または交通契約）は必要ありません。この管理手荷物の不足は、L4Sにエンドツーエンドの展開の可能性が高いとするべきです。
In particular, if networks do not trust end systems to identify which packets should be favoured, they assign packets to Diffserv classes themselves. However, the techniques available to such networks, like inspection of flow identifiers or deeper inspection of application signatures, do not always sit well with encryption of the layers above IP [RFC8404]. In these cases, users can have either privacy or Quality of Service (QoS), but not both.
特に、ネットワークが最終システムを信頼していない場合、どのパケットが優先されるべきかを識別しない場合、パケットをDiffServクラス自体に割り当てます。ただし、フロー識別子の検査やアプリケーション署名のより深い検査など、このようなネットワークが利用できる手法は、IPの上のレイヤーの暗号化と常にうまく座るとは限りません[RFC8404]。これらの場合、ユーザーはプライバシーまたはサービス品質（QO）を持つことができますが、両方ではありません。
As with Diffserv, the L4S identifier is in the IP header. But, in contrast to Diffserv, the L4S identifier does not convey a want or a need for a certain level of quality. Rather, it promises a certain behaviour (Scalable congestion response), which networks can objectively verify if they need to. This is because low delay depends on collective host behaviour, whereas bandwidth priority depends on network behaviour.
DiffServと同様に、L4S識別子はIPヘッダーにあります。しかし、Diffservとは対照的に、L4S識別子は、あるレベルの品質の必要性や必要性を伝えません。むしろ、ネットワークが必要かどうかを客観的に検証できる特定の動作（スケーラブルな輻輳応答）を約束します。これは、低遅延が集合ホストの動作に依存するのに対し、帯域幅の優先度はネットワークの動作に依存するためです。
State-of-the-art AQMs: AQMs for Classic traffic, such as PIE and FQ-CoDel, give a significant reduction in queuing delay relative to no AQM at all. L4S is intended to complement these AQMs and should not distract from the need to deploy them as widely as possible. Nonetheless, AQMs alone cannot reduce queuing delay too far without significantly reducing link utilization, because the root cause of the problem is on the host -- where Classic congestion controls use large sawtoothing rate variations. The L4S approach resolves this tension between delay and utilization by enabling hosts to minimize the amplitude of their sawteeth. A single-queue Classic AQM is not sufficient to allow hosts to use small sawteeth for two reasons: i) smaller sawteeth would not get lower delay in an AQM designed for larger amplitude Classic sawteeth, because a queue can only have one length at a time and ii) much smaller sawteeth implies much more frequent sawteeth, so L4S flows would drive a Classic AQM into a high level of ECN-marking, which would appear as heavy congestion to Classic flows, which in turn would greatly reduce their rate as a result (see Section 6.4.4).
最先端のAQMS：PIEやFQコデルなどの古典的なトラフィック用のAQMSは、AQM NOに比べてキューイング遅延を大幅に減らします。L4Sは、これらのAQMを補完することを目的としており、可能な限り広く展開する必要性から気を散らすべきではありません。それにもかかわらず、問題の根本原因はホストにあるため、AQMSだけがリンクの使用率を大幅に削減することなく、キューイングの遅延を大幅に減らすことはできません。これは、古典的な混雑コントロールが大きな鋸のかかる速度の変動を使用しているためです。L4Sアプローチは、ホストが鋸の振幅を最小化できるようにすることにより、遅延と利用の間のこの緊張を解決します。シングルキューの古典的なAQMでは、ホストが2つの理由で小さな鋸を使用できるようにするには十分ではありません。i）小型の鋸は、より大きな振幅の古典的な鋸に設計されたAQMで低い遅延を取得しません。ii）はるかに小さい鋸は、はるかに頻繁な鋸を意味するため、L4Sフローは古典的なAQMを高レベルのECNマークに駆り立てます。（セクション6.4.4を参照）。
Per-flow queuing or marking: Similarly, per-flow approaches, such as FQ-CoDel or Approx Fair CoDel [AFCD], are not incompatible with the L4S approach. However, per-flow queuing alone is not enough -- it only isolates the queuing of one flow from others, not from itself. Per-flow implementations need to have support for Scalable congestion control added, which has already been done for FQ-CoDel in Linux (see Section 5.2.7 of [RFC8290] and [FQ_CoDel_Thresh]). Without this simple modification, per-flow AQMs, like FQ-CoDel, would still not be able to support applications that need both very low delay and high bandwidth, e.g., video-based control of remote procedures or interactive cloud-based video (see Note 1 below).
フローごとのキューイングまたはマーキング：同様に、FQコデルやおおよそのフェアコーデル[AFCD]などのフローごとのアプローチは、L4Sアプローチと互換性がありません。ただし、流量あたりのキューイングだけでは十分ではありません。それは、それ自体からではなく、他のフローからの1つのフローのキューイングのみを分離します。フローあたりの実装では、LinuxのFQコデルに対してすでに行われているスケーラブル輻輳制御をサポートする必要があります（[RFC8290]および[FQ_Codel_Thresh]のセクション5.2.7を参照）。この単純な変更がなければ、FQコデルのようなフローあたりのAQMSは、非常に低い遅延と高い帯域幅の両方を必要とするアプリケーションをサポートできません。注1以下）。
Although per-flow techniques are not incompatible with L4S, it is important to have the DualQ alternative. This is because handling end-to-end (layer 4) flows in the network (layer 3 or 2) precludes some important end-to-end functions. For instance:
流量あたりの手法はL4と互換性がありませんが、DualQの代替品を持つことが重要です。これは、ネットワーク内のエンドツーエンド（レイヤー4）の流れ（レイヤー3または2）がいくつかの重要なエンドツーエンド関数を排除するためです。例えば：
a. Per-flow forms of L4S, like FQ-CoDel, are incompatible with full end-to-end encryption of transport layer identifiers for privacy and confidentiality (e.g., IPsec or encrypted VPN tunnels, as opposed to DTLS over UDP), because they require packet inspection to access the end-to-end transport flow identifiers.
a. FQコデルのようなL4の流量あたりのフォームは、プライバシーと機密性のための輸送層識別子の完全なエンドツーエンド暗号化と互換性がありません（例：UDPを超えるDTLとは対照的に、IPSECまたは暗号化されたVPNトンネル）。エンドツーエンドの輸送フロー識別子にアクセスするためのパケット検査。
In contrast, the DualQ form of L4S requires no deeper inspection than the IP layer. So as long as operators take the DualQ approach, their users can have both very low queuing delay and full end-to-end encryption [RFC8404].
対照的に、L4のDualQ形式では、IPレイヤーよりも深い検査を必要としません。したがって、オペレーターがDualQアプローチをとる限り、ユーザーは非常に低いキューイング遅延とフルエンドツーエンド暗号化の両方を持つことができます[RFC8404]。
b. With per-flow forms of L4S, the network takes over control of the relative rates of each application flow. Some see it as an advantage that the network will prevent some flows running faster than others. Others consider it an inherent part of the Internet's appeal that applications can control their rate while taking account of the needs of others via congestion signals. They maintain that this has allowed applications with interesting rate behaviours to evolve, for instance: i) a variable bit-rate video that varies around an equal share, rather than being forced to remain equal at every instant or ii) end-to-end scavenger behaviours [RFC6817] that use less than an equal share of capacity [LEDBAT_AQM].
b. L4の流量あたりのフォームを使用すると、ネットワークは各アプリケーションフローの相対レートの制御を引き継ぎます。一部の人は、ネットワークが他のフローよりも速く実行されるフローを防ぐという利点があると考えています。他の人は、それをインターネットの魅力の固有の部分であると考えています。アプリケーションは、混雑信号を介して他の人のニーズを考慮しながら、レートを制御できると考えています。彼らは、これにより、興味深いレートの動作を備えたアプリケーションが進化することができると主張しています。たとえば、次のようになります。i）すべての瞬間またはii）エンドツーエンドで平等に存在することを余儀なくされるのではなく、等しいシェアを中心に変化する可変ビットレートビデオです。容量の等しいシェア未満[LEDBAT_AQM]を使用するスカベンジャーの動作[RFC6817]。
The L4S architecture does not require the IETF to commit to one approach over the other, because it supports both so that the 'market' can decide. Nonetheless, in the spirit of 'Do one thing and do it well' [McIlroy78], the DualQ option provides low delay without prejudging the issue of flow-rate control. Then, flow rate policing can be added separately if desired. In contrast to scheduling, a policer would allow application control up to a point, but the network would still be able to set the point at which it intervened to prevent one flow completely starving another.
L4Sアーキテクチャは、「市場」が決定できるように両方をサポートするため、IETFが一方のアプローチにコミットする必要はありません。それにもかかわらず、「1つのことをして、それをうまくやる」[McIlroy78]の精神で、DualQオプションは、フローレート制御の問題を損なうことなく低遅延を提供します。次に、必要に応じて、流量ポリシングを個別に追加できます。スケジューリングとは対照的に、ポリサーはアプリケーション制御をポイントまで許可しますが、ネットワークは、あるフローが完全に飢えているのを防ぐために介入したポイントを設定することができます。
Note:
ノート：
1. It might seem that self-inflicted queuing delay within a per-flow queue should not be counted, because if the delay wasn't in the network, it would just shift to the sender. However, modern adaptive applications, e.g., HTTP/2 [RFC9113] or some interactive media applications (see Section 6.1), can keep low latency objects at the front of their local send queue by shuffling priorities of other objects dependent on the progress of other transfers (for example, see [lowat]). They cannot shuffle objects once they have released them into the network.
1. 遅延がネットワーク内にない場合、送信者に移行するだけで、フローあたりのキュー内の自傷行為のキューイング遅延をカウントすべきではないように見えるかもしれません。ただし、最新の適応アプリケーション、たとえばHTTP/2 [RFC9113]またはいくつかのインタラクティブメディアアプリケーション（セクション6.1を参照）は、他のオブジェクトの優先順位をシャッフルすることにより、ローカル送信キューの前面に低いレイテンシオブジェクトを保持できます。転送（たとえば、[lowat]を参照）。オブジェクトをネットワークにリリースすると、オブジェクトをシャッフルできません。
Alternative Back-off ECN (ABE): Here again, L4S is not an alternative to ABE but a complement that introduces much lower queuing delay. ABE [RFC8511] alters the host behaviour in response to ECN marking to utilize a link better and give ECN flows faster throughput. It uses ECT(0) and assumes the network still treats ECN and drop the same. Therefore, ABE exploits any lower queuing delay that AQMs can provide. But, as explained above, AQMs still cannot reduce queuing delay too much without losing link utilization (to allow for other, non-ABE, flows).
代替バックオフECN（ABE）：ここでも、L4SはABEの代替品ではなく、キューイングの遅延がはるかに低い補完です。ABE [RFC8511]は、ECNマーキングに応答してホストの動作を変化させ、リンクをより良く利用し、ECNフローをより速くスループットにします。ECT（0）を使用し、ネットワークがまだECNを処理し、同じものをドロップしていると想定しています。したがって、ABEはAQMSが提供できるより低いキューイング遅延を活用します。しかし、上記で説明したように、AQMSはリンクの使用率を失うことなく（他の非ABE、フローを可能にするため）、キューイングの遅延をあまり減らすことができません。
BBR: Bottleneck Bandwidth and Round-trip propagation time (BBR) [BBR-CC] controls queuing delay end-to-end without needing any special logic in the network, such as an AQM. So it works pretty much on any path. BBR keeps queuing delay reasonably low, but perhaps not quite as low as with state-of-the-art AQMs, such as PIE or FQ-CoDel, and certainly nowhere near as low as with L4S. Queuing delay is also not consistently low, due to BBR's regular bandwidth probing spikes and its aggressive flow start-up phase.
BBR：ボトルネックの帯域幅と往復伝播時間（BBR）[BBR-CC]は、AQMなどのネットワークの特別なロジックを必要とせずに、エンドツーエンドのキューイングエンドツーエンドを制御します。したがって、それはどんな道でもほとんど動作します。BBRはキューイングの遅延をかなり低く維持しますが、おそらくパイやFQコデルなどの最先端のAQMSほど低くはなく、L4Sほど低い場所ではありません。BBRの通常の帯域幅プロービングスパイクとその積極的なフロースタートアップフェーズにより、キューイングの遅延も一貫して低くありません。
L4S complements BBR. Indeed, BBRv2 can use L4S ECN where available and a Scalable L4S congestion control behaviour in response to any ECN signalling from the path [BBRv2]. The L4S ECN signal complements the delay-based congestion control aspects of BBR with an explicit indication that hosts can use, both to converge on a fair rate and to keep below a shallow queue target set by the network. Without L4S ECN, both these aspects need to be assumed or estimated.
L4SはBBRを補完します。実際、BBRV2は、利用可能な場合はL4S ECNを使用し、パスからのECNシグナル伝達に応じてスケーラブルなL4S輻輳制御挙動を使用できます[BBRV2]。L4S ECN信号は、BBRの遅延ベースの混雑制御の側面を、ホストが使用できるという明示的な兆候を補完します。L4S ECNがなければ、これらの側面の両方を想定または推定する必要があります。
A transport layer that solves the current latency issues will provide new service, product, and application opportunities.
現在のレイテンシの問題を解決する輸送層は、新しいサービス、製品、およびアプリケーションの機会を提供します。
With the L4S approach, the following existing applications also experience significantly better quality of experience under load:
L4Sアプローチにより、以下の既存のアプリケーションは、負荷の下での経験の質が大幅に向上します。
* gaming, including cloud-based gaming;
* クラウドベースのゲームを含むゲーム。
* VoIP;
* voip;
* video conferencing;
* ビデオ会議;
* web browsing;
* Webブラウジング;
* (adaptive) video streaming; and
* （適応型）ビデオストリーミング;と
* instant messaging.
* インスタントメッセージング。
The significantly lower queuing latency also enables some interactive application functions to be offloaded to the cloud that would hardly even be usable today, including:
また、キューイングレイテンシが大幅に低くなると、インタラクティブなアプリケーション関数がクラウドにオフロードされることも可能になります。
* cloud-based interactive video and
* クラウドベースのインタラクティブビデオと
* cloud-based virtual and augmented reality.
* クラウドベースの仮想および拡張現実。
The above two applications have been successfully demonstrated with L4S, both running together over a 40 Mb/s broadband access link loaded up with the numerous other latency-sensitive applications in the previous list, as well as numerous downloads, with all sharing the same bottleneck queue simultaneously [L4Sdemo16] [L4Sdemo16-Video]. For the former, a panoramic video of a football stadium could be swiped and pinched so that, on the fly, a proxy in the cloud could generate a sub-window of the match video under the finger-gesture control of each user. For the latter, a virtual reality headset displayed a viewport taken from a 360-degree camera in a racing car. The user's head movements controlled the viewport extracted by a cloud-based proxy. In both cases, with a 7 ms end-to-end base delay, the additional queuing delay of roughly 1 ms was so low that it seemed the video was generated locally.
上記の2つのアプリケーションは、L4Sで正常に実証されており、両方とも40 MB/sのブロードバンドアクセスリンクを使用して、以前のリストにある他の多数のレイテンシセンシティブアプリケーションと多数のダウンロードをロードし、すべてが同じボトルネックを共有しています。同時にキュー[L4SDEMO16] [L4SDEMO16-Video]。前者の場合、サッカースタジアムのパノラマビデオをスワイプしてつまむことができるため、クラウドのプロキシが各ユーザーの指 - グレイグアコントロールの下にマッチビデオのサブウィンドウを生成できるようにします。後者の場合、仮想現実ヘッドセットがレーシングカーの360度のカメラから取られたビューポートを表示しました。ユーザーのヘッドの動きは、クラウドベースのプロキシによって抽出されたビューポートを制御しました。どちらの場合も、7ミリ秒のエンドツーエンドのベース遅延があるため、約1ミリ秒の追加のキューイング遅延が非常に低かったため、ビデオがローカルで生成されたように見えました。
Using a swiping finger gesture or head movement to pan a video are extremely latency-demanding actions -- far more demanding than VoIP -- because human vision can detect extremely low delays of the order of single milliseconds when delay is translated into a visual lag between a video and a reference point (the finger or the orientation of the head sensed by the balance system in the inner ear, i.e., the vestibular system). With an alternative AQM, the video noticeably lagged behind the finger gestures and head movements.
スワイプフィンガージェスチャーまたはヘッドの動きを使用してビデオをパンすることは、VoIPよりもはるかに要求の厳しいアクションです。これは、遅延が視覚的な遅延に変換されたときに単一ミリ秒の順序の非常に低い遅延を検出できるため、VoIPよりもはるかに厳しいアクションです。ビデオと参照ポイント（内耳のバランスシステムによって感知される頭の指または方向、つまり前庭系）。代替AQMを使用して、ビデオは指のジェスチャーと頭の動きの後ろに著しく遅れています。
Without the low queuing delay of L4S, cloud-based applications like these would not be credible without significantly more access-network bandwidth (to deliver all possible areas of the video that might be viewed) and more local processing, which would increase the weight and power consumption of head-mounted displays. When all interactive processing can be done in the cloud, only the data to be rendered for the end user needs to be sent.
L4のキューイングの低い遅延がなければ、このようなクラウドベースのアプリケーションは、アクセスネットワークの帯域幅が大幅に増加することなく（表示されるビデオのすべての可能な領域を提供するため）、より多くのローカル処理がなければ信頼できません。ヘッドマウントディスプレイの消費電力。すべてのインタラクティブ処理をクラウドで実行できる場合、エンドユーザー用にレンダリングされるデータのみを送信する必要があります。
Other low latency high bandwidth applications, such as:
次のような、その他の低潜伏帯域幅アプリケーション。
* interactive remote presence and
* インタラクティブなリモートプレゼンスと
* video-assisted remote control of machinery or industrial processes
* 機械または産業プロセスのビデオ支援リモートコントロール
are not credible at all without very low queuing delay. No amount of extra access bandwidth or local processing can make up for lost time.
キューイングの遅延が非常に低い場合、まったく信頼できません。余分なアクセス帯域幅やローカル処理は、失われた時間を補うことはできません。
The following use cases for L4S are being considered by various interested parties:
L4の以下のユースケースは、さまざまな利害関係者によって考慮されています。
* where the bottleneck is one of various types of access network, e.g., DSL, Passive Optical Networks (PONs), DOCSIS cable, mobile, satellite; or where it's a Wi-Fi link (see Section 6.3 for some technology-specific details)
* ボトルネックは、DSL、パッシブ光ネットワーク（ポン）、DocSISケーブル、モバイル、衛星など、さまざまなタイプのアクセスネットワークの1つです。または、それがWi-Fiリンクである場合（いくつかの技術固有の詳細についてはセクション6.3を参照）
* private networks of heterogeneous data centres, where there is no single administrator that can arrange for all the simultaneous changes to senders, receivers, and networks needed to deploy DCTCP:
* 不均一なデータセンターのプライベートネットワーク。DCTCPを展開するために必要な送信者、受信機、およびネットワークにすべての同時変更を手配できる単一の管理者が存在しません。
- a set of private data centres interconnected over a wide area with separate administrations but within the same company
- 一連のプライベートデータセンターは、別々の管理者とともに広いエリアで相互接続されていますが、同じ会社内で
- a set of data centres operated by separate companies interconnected by a community of interest network (e.g., for the finance sector)
- 関心のあるコミュニティネットワークによって相互接続された別々の企業が運営する一連のデータセンター（例：金融セクター向け）
- multi-tenant (cloud) data centres where tenants choose their operating system stack (Infrastructure as a Service (IaaS))
- マルチテナント（クラウド）データセンターテナントがオペレーティングシステムスタックを選択する（インフラストラクチャ（IAAS））
* different types of transport (or application) congestion control:
* さまざまな種類の輸送（またはアプリケーション）混雑制御：
- elastic (TCP/SCTP);
- 弾性（TCP/SCTP）;
- real-time (RTP, RMCAT); and
- リアルタイム（rtp、rmcat）;と
- query-response (DNS/LDAP).
- Query-Response（DNS/LDAP）。
* where low delay QoS is required but without inspecting or intervening above the IP layer [RFC8404]:
* 低遅延QoSが必要ですが、IPレイヤーの上に検査または介入することはありません[RFC8404]：
- Mobile and other networks have tended to inspect higher layers in order to guess application QoS requirements. However, with growing demand for support of privacy and encryption, L4S offers an alternative. There is no need to select which traffic to favour for queuing when L4S can give favourable queuing to all traffic.
- モバイルおよびその他のネットワークは、アプリケーションのQoS要件を推測するために、より高いレイヤーを検査する傾向があります。ただし、プライバシーと暗号化のサポートに対する需要の高まりにより、L4Sは代替品を提供します。L4がすべてのトラフィックに好ましいキューイングを与えることができる場合、キューイングに支持するトラフィックを選択する必要はありません。
* If queuing delay is minimized, applications with a fixed delay budget can communicate over longer distances or via more circuitous paths, e.g., longer chains of service functions [RFC7665] or of onion routers.
* キューイングの遅延が最小化されると、固定遅延予算を持つアプリケーションは、より長い距離にわたって、またはより長いサービス関数[RFC7665]またはオニオンルーターのより長いチェーンを介して通信できます。
* If delay jitter is minimized, it is possible to reduce the dejitter buffers on the receiving end of video streaming, which should improve the interactive experience.
* 遅延ジッターが最小化された場合、ビデオストリーミングの受信側のデジターバッファを減らすことができ、インタラクティブエクスペリエンスが向上するはずです。
Certain link technologies aggregate data from multiple packets into bursts and buffer incoming packets while building each burst. Wi-Fi, PON, and cable all involve such packet aggregation, whereas fixed Ethernet and DSL do not. No sender, whether L4S or not, can do anything to reduce the buffering needed for packet aggregation. So an AQM should not count this buffering as part of the queue that it controls, given no amount of congestion signals will reduce it.
特定のLink Technologiesは、複数のパケットからデータをバーストとバッファ化パケットに集約し、各バーストを構築します。Wi-Fi、PON、およびケーブルはすべてそのようなパケット集約を伴いますが、固定イーサネットとDSLはそうではありません。L4Sであろうとなかろうと、送信者は、パケット集約に必要なバッファリングを減らすために何でもできません。したがって、AQMは、このバッファリングを制御するキューの一部としてカウントしてはなりません。渋滞信号の量が減っても、それを減らすことはできません。
Certain link technologies also add buffering for other reasons, specifically:
特定のリンクテクノロジーも、他の理由でバッファリングを追加します。
* Radio links (cellular, Wi-Fi, or satellite) that are distant from the source are particularly challenging. The radio link capacity can vary rapidly by orders of magnitude, so it is considered desirable to hold a standing queue that can utilize sudden increases of capacity.
* ソースから離れた無線リンク（セルラー、Wi-Fi、または衛星）は特に困難です。無線リンク容量は桁違いに急速に変化する可能性があるため、突然の容量の増加を利用できるスタンディングキューを保持することが望ましいと考えられています。
* Cellular networks are further complicated by a perceived need to buffer in order to make hand-overs imperceptible.
* 携帯電話のネットワークは、ハンドオーバーを認識できないようにするために、バッファする必要性が認識されていることにより、さらに複雑になります。
L4S cannot remove the need for all these different forms of buffering. However, by removing 'the longest pole in the tent' (buffering for the large sawteeth of Classic congestion controls), L4S exposes all these 'shorter poles' to greater scrutiny.
L4は、これらすべての異なる形式のバッファリングの必要性を削除することはできません。ただし、「テント内で最も長い極」（古典的な混雑コントロールの大きな測量のためのバッファリング）を除去することにより、L4Sはこれらすべての「短い極」をより大きな精査にさらします。
Until now, the buffering needed for these additional reasons tended to be over-specified -- with the excuse that none were 'the longest pole in the tent'. But having removed the 'longest pole', it becomes worthwhile to minimize them, for instance, reducing packet aggregation burst sizes and MAC scheduling intervals.
これまで、これらの追加の理由でバッファリングが必要とされていたため、過度に指定される傾向がありました - 「テントで最も長いポール」ではないという言い訳がありました。しかし、「最も長いポール」を削除したため、それらを最小限に抑えることは価値があります。たとえば、パケット集約のバーストサイズとMACスケジューリング間隔を削減します。
Also, certain link types, particularly radio-based links, are far more prone to transmission losses. Section 6.4.3 explains how an L4S response to loss has to be as drastic as a Classic response. Nonetheless, research referred to in the same section has demonstrated potential for considerably more effective loss repair at the link layer, due to the relaxed ordering constraints of L4S packets.
また、特定のリンクタイプ、特にラジオベースのリンクは、伝送損失をもたらす傾向があります。セクション6.4.3では、損失に対するL4Sの反応が、古典的な応答と同じくらい抜本的になければならない方法について説明します。それにもかかわらず、同じセクションで言及されている研究は、L4Sパケットの緩和順序制約により、リンク層でかなり効果的な損失修復の可能性を実証しています。
L4S AQMs, whether DualQ [RFC9332] or FQ [RFC8290], are in themselves an incremental deployment mechanism for L4S -- so that L4S traffic can coexist with existing Classic (Reno-friendly) traffic. Section 6.4.1 explains why only deploying an L4S AQM in one node at each end of the access link will realize nearly all the benefit of L4S.
L4S AQMは、DualQ [RFC9332]またはFQ [RFC8290]であろうと、L4Sの増分展開メカニズムであるため、L4Sトラフィックは既存のクラシック（リノフレンドリー）トラフィックと共存できます。セクション6.4.1では、アクセスリンクの両端に1つのノードにL4S AQMのみを展開するだけで、L4Sのほぼすべての利点が実現する理由について説明します。
L4S involves both the network and end systems, so Section 6.4.2 suggests some typical sequences to deploy each part and why there will be an immediate and significant benefit after deploying just one part.
L4Sにはネットワークとエンドの両方のシステムが含まれるため、セクション6.4.2は、各部品を展開するための典型的なシーケンスと、1つの部品のみを展開した後に即時かつ重要な利益がある理由を提案します。
Sections 6.4.3 and 6.4.4 describe the converse incremental deployment case where there is no L4S AQM at the network bottleneck, so any L4S flow traversing this bottleneck has to take care in case it is competing with Classic traffic.
セクション6.4.3および6.4.4は、ネットワークボトルネックにL4S AQMがないコンバース増分展開ケースについて説明するため、このボトルネックを通過するL4Sフローは、古典的なトラフィックと競合している場合に注意する必要があります。
L4S AQMs will not have to be deployed throughout the Internet before L4S can benefit anyone. Operators of public Internet access networks typically design their networks so that the bottleneck will nearly always occur at one known (logical) link. This confines the cost of queue management technology to one place.
L4Sは、L4Sが誰にでも利益をもたらす前に、インターネット全体に展開する必要はありません。パブリックインターネットアクセスネットワークのオペレーターは、通常、ネットワークを設計して、ボトルネックがほぼ常に既知の（論理的な）リンクで発生するようにします。これにより、キュー管理技術のコストが1つの場所に限定されます。
The case of mesh networks is different and will be discussed later in this section. However, the known-bottleneck case is generally true for Internet access to all sorts of different 'sites', where the word 'site' includes home networks, small- to medium-sized campus or enterprise networks and even cellular devices (Figure 2). Also, this known-bottleneck case tends to be applicable whatever the access link technology, whether xDSL, cable, PON, cellular, line of sight wireless, or satellite.
メッシュネットワークの場合は異なり、このセクションで後述します。ただし、既知のボトルネックのケースは、一般に、「サイト」という単語には、ホームネットワーク、中規模から中規模のキャンパスまたはエンタープライズネットワーク、さらにはセルラーデバイスが含まれる、あらゆる種類の「サイト」へのインターネットアクセスに一般的に当てはまります（図2）。また、この既知のボトルネックケースは、XDSL、ケーブル、ポン、セルラー、視力線、衛星、または衛星など、アクセスリンクテクノロジーが何であれ適用される傾向があります。
Therefore, the full benefit of the L4S service should be available in the downstream direction when an L4S AQM is deployed at the ingress to this bottleneck link. And similarly, the full upstream service will typically be available once an L4S AQM is deployed at the ingress into the upstream link. (Of course, multihomed sites would only see the full benefit once all their access links were covered.)
したがって、L4S ACMがこのボトルネックリンクにイングレスに展開される場合、L4Sサービスの完全な利点は、下流の方向に利用できるようにする必要があります。同様に、L4S AQMがイングレスでアップストリームリンクに展開されると、通常、上流のサービスが利用可能になります。（もちろん、マルチホームのサイトでは、すべてのアクセスリンクがカバーされた場合にのみ完全なメリットが表示されます。）
______
( )
__ __ ( )
|DQ\________/DQ|( enterprise )
___ |__/ \__| ( /campus )
( ) (______)
( ) ___||_
+----+ ( ) __ __ / \
| DC |-----( Core )|DQ\_______________/DQ|| home |
+----+ ( ) |__/ \__||______|
(_____) __
|DQ\__/\ __ ,===.
|__/ \ ____/DQ||| ||mobile
\/ \__|||_||device
| o |
`---'
Figure 2: Likely Location of DualQ (DQ) Deployments in Common Access Topologies
図2：一般的なアクセストポロジのデュアルク（DQ）展開の可能性
Deployment in mesh topologies depends on how overbooked the core is. If the core is non-blocking, or at least generously provisioned so that the edges are nearly always the bottlenecks, it would only be necessary to deploy an L4S AQM at the edge bottlenecks. For example, some data-centre networks are designed with the bottleneck in the hypervisor or host Network Interface Controllers (NICs), while others bottleneck at the top-of-rack switch (both the output ports facing hosts and those facing the core).
メッシュトポロジーの展開は、コアのオーバーブッキング方法によって異なります。コアがノンブロッキングであるか、少なくともエッジがボトルネックになるように少なくとも寛大にプロビジョニングされている場合、EdgeボトルネックにL4S AQMを展開する必要があります。たとえば、一部のデータセンターネットワークは、ハイパーバイザーまたはホストネットワークインターフェイスコントローラー（NICS）のボトルネックを使用して設計されていますが、他のネットワークスイッチ（ホストに面した出力ポートとコアに面した出力ポートの両方）でボトルネックがあります。
An L4S AQM would often next be needed where the Wi-Fi links in a home sometimes become the bottleneck. Also an L4S AQM would eventually need to be deployed at any other persistent bottlenecks, such as network interconnections, e.g., some public Internet exchange points and the ingress and egress to WAN links interconnecting data centres.
L4S AQMが次に必要になることがよくあります。ここでは、家のWi-Fiリンクがボトルネックになることがあります。また、L4S AQMは、最終的に、ネットワーク相互接続など、他の永続的なボトルネックに展開する必要があります。
For any one L4S flow to provide benefit, it requires three (or sometimes two) parts to have been deployed: i) the congestion control at the sender; ii) the AQM at the bottleneck; and iii) older transports (namely TCP) need upgraded receiver feedback too. This was the same deployment problem that ECN faced [RFC8170], so we have learned from that experience.
1つのL4Sフローに利益をもたらすために、3つ（または場合によっては2つの）パーツが展開される必要があります。i）送信者での混雑制御。ii）ボトルネックのAQM。iii）古い輸送（すなわち、TCP）もアップグレードされたレシーバーフィードバックも必要です。これは、ECNが直面した[RFC8170]と同じ展開の問題であったため、その経験から学びました。
Firstly, L4S deployment exploits the fact that DCTCP already exists on many Internet hosts (e.g., Windows, FreeBSD, and Linux), both servers and clients. Therefore, an L4S AQM can be deployed at a network bottleneck to immediately give a working deployment of all the L4S parts for testing, as long as the ECT(0) codepoint is switched to ECT(1). DCTCP needs some safety concerns to be fixed for general use over the public Internet (see Section 4.3 of the L4S ECN spec [RFC9331]), but DCTCP is not on by default, so these issues can be managed within controlled deployments or controlled trials.
第一に、L4Sの展開は、DCTCPがサーバーとクライアントの両方の多くのインターネットホスト（Windows、FreeBSD、Linuxなど）にすでに存在するという事実を活用しています。したがって、ECT（0）CodePointがECT（1）に切り替えられる限り、L4S AQMをネットワークボトルネックに展開して、テスト用のすべてのL4Sパーツをすぐに展開することができます。DCTCPには、パブリックインターネットで一般的に使用するためにいくつかの安全性の懸念を修正する必要があります（L4S ECN Spec [RFC9331]のセクション4.3を参照）が、DCTCPはデフォルトではありません。
Secondly, the performance improvement with L4S is so significant that it enables new interactive services and products that were not previously possible. It is much easier for companies to initiate new work on deployment if there is budget for a new product trial. In contrast, if there were only an incremental performance improvement (as with Classic ECN), spending on deployment tends to be much harder to justify.
第二に、L4Sによるパフォーマンスの改善は非常に重要であるため、以前は不可能だった新しいインタラクティブなサービスと製品が可能になります。新製品トライアルの予算がある場合、企業は展開に関する新しい作業を開始するのははるかに簡単です。対照的に、（古典的なECNと同様に）増分パフォーマンスの改善しかなかった場合、展開への支出は正当化するのがはるかに難しい傾向があります。
Thirdly, the L4S identifier is defined so that network operators can initially enable L4S exclusively for certain customers or certain applications. However, this is carefully defined so that it does not compromise future evolution towards L4S as an Internet-wide service. This is because the L4S identifier is defined not only as the end-to-end ECN field, but it can also optionally be combined with any other packet header or some status of a customer or their access link (see Section 5.4 of [RFC9331]). Operators could do this anyway, even if it were not blessed by the IETF. However, it is best for the IETF to specify that, if they use their own local identifier, it must be in combination with the IETF's identifier, ECT(1). Then, if an operator has opted for an exclusive local-use approach, they only have to remove this extra rule later to make the service work across the Internet -- it will already traverse middleboxes, peerings, etc.
第三に、L4S識別子は定義されているため、ネットワークオペレーターは最初に特定の顧客または特定のアプリケーション専用にL4Sを有効にすることができます。ただし、これは慎重に定義されているため、インターネット全体のサービスとしてL4に対する将来の進化を妥協しません。これは、L4S識別子がエンドツーエンドECNフィールドとしてだけでなく、オプションで他のパケットヘッダーまたは顧客のステータスまたはそのアクセスリンクと組み合わせることもできます（[RFC9331]のセクション5.4を参照してください。）。とにかく、オペレーターはIETFに恵まれていなくても、とにかくこれを行うことができます。ただし、IETFが独自のローカル識別子を使用する場合、IETFの識別子ECECT（1）と組み合わせている必要があることを指定することが最適です。その後、オペレーターが排他的なローカル使用アプローチを選択した場合、インターネット全体でサービスを機能させるためにこの追加ルールを後で削除するだけで、すでにミドルボックス、ピーリングなどを通過します。
+-+--------------------+----------------------+---------------------+
| | Servers or proxies | Access link | Clients |
+-+--------------------+----------------------+---------------------+
|0| DCTCP (existing) | | DCTCP (existing) |
+-+--------------------+----------------------+---------------------+
|1| |Add L4S AQM downstream| |
| | WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS |
+-+--------------------+----------------------+---------------------+
|2| Upgrade DCTCP to | |Replace DCTCP feedb'k|
| | TCP Prague | | with AccECN |
| | FULLY WORKS DOWNSTREAM |
+-+--------------------+----------------------+---------------------+
| | | | Upgrade DCTCP to |
|3| | Add L4S AQM upstream | TCP Prague |
| | | | |
| | FULLY WORKS UPSTREAM AND DOWNSTREAM |
+-+--------------------+----------------------+---------------------+
Figure 3: Example L4S Deployment Sequence
図3：L4S展開シーケンスの例
Figure 3 illustrates some example sequences in which the parts of L4S might be deployed. It consists of the following stages, preceded by a presumption that DCTCP is already installed at both ends:
図3は、L4Sの部分が展開される可能性のあるいくつかの例を示しています。これは、次の段階で構成されており、DCTCPがすでに両端にインストールされているという推定があります。
1. DCTCP is not applicable for use over the public Internet, so it is emphasized here that any DCTCP flow has to be completely contained within a controlled trial environment.
1. DCTCPはパブリックインターネットでの使用には適用できないため、DCTCPフローは制御された試行環境内に完全に含まれる必要があることが強調されています。
Within this trial environment, once an L4S AQM has been deployed, the trial DCTCP flow will experience immediate benefit, without any other deployment being needed. In this example, downstream deployment is first, but in other scenarios, the upstream might be deployed first. If no AQM at all was previously deployed for the downstream access, an L4S AQM greatly improves the Classic service (as well as adding the L4S service). If an AQM was already deployed, the Classic service will be unchanged (and L4S will add an improvement on top).
このトライアル環境内で、L4S AQMが展開されると、他の展開が必要になることなく、Trial DCTCPフローが即座に利益をもたらします。この例では、ダウンストリームの展開が最初ですが、他のシナリオでは、上流が最初に展開される可能性があります。以前にダウンストリームアクセスのためにAQMが展開されていない場合、L4S AQMはクラシックサービスを大幅に改善します（L4Sサービスの追加）。AQMがすでに展開されている場合、クラシックサービスは変更されません（L4Sは上部に改善を追加します）。
2. In this stage, the name 'TCP Prague' [PRAGUE-CC] is used to represent a variant of DCTCP that is designed to be used in a production Internet environment (that is, it has to comply with all the requirements in Section 4 of the L4S ECN spec [RFC9331], which then means it can be used over the public Internet). If the application is primarily unidirectional, 'TCP Prague' at the sending end will provide all the benefit needed, as long as the receiving end supports Accurate ECN (AccECN) feedback [ACCECN].
2. この段階では、「TCP Prague」[Prague-CC]という名前は、生産インターネット環境で使用されるように設計されたDCTCPのバリアントを表すために使用されます（つまり、セクション4のすべての要件に準拠する必要があります。L4S ECN仕様[RFC9331]は、パブリックインターネットで使用できることを意味します）。アプリケーションが主に単方向である場合、受信エンドが正確なECN（accecn）フィードバック[accecn]をサポートしている限り、送信端での「TCPプラハ」は必要なすべての利益を提供します。
For TCP transports, AccECN feedback is needed at the other end, but it is a generic ECN feedback facility that is already planned to be deployed for other purposes, e.g., DCTCP and BBR. The two ends can be deployed in either order because, in TCP, an L4S congestion control only enables itself if it has negotiated the use of AccECN feedback with the other end during the connection handshake. Thus, deployment of TCP Prague on a server enables L4S trials to move to a production service in one direction, wherever AccECN is deployed at the other end. This stage might be further motivated by the performance improvements of TCP Prague relative to DCTCP (see Appendix A.2 of the L4S ECN spec [RFC9331]).
TCPトランスポートの場合、反対側ではAcceCNフィードバックが必要ですが、それはすでに他の目的のために展開される予定の一般的なECNフィードバック施設です。たとえば、DCTCPやBBR。TCPでは、L4Sの混雑制御は、接続ハンドシェイク中に反対側とのacceCNフィードバックの使用を交渉した場合にのみそれ自体を有効にするため、どちらの順序で展開できます。したがって、サーバー上のTCPプラハの展開により、L4Sトライアルは、accecnがもう一方の端に展開されていれば、一方向に生産サービスに移動できます。この段階は、DCTCPに対するTCPプラハのパフォーマンスの改善によってさらに動機付けられる可能性があります（L4S ECN Spec [RFC9331]の付録A.2を参照）。
Unlike TCP, from the outset, QUIC ECN feedback [RFC9000] has supported L4S. Therefore, if the transport is QUIC, one-ended deployment of a Prague congestion control at this stage is simple and sufficient.
TCPとは異なり、最初から、QUIC ECNフィードバック[RFC9000]はL4をサポートしています。したがって、輸送がQUICである場合、この段階でのプラハの混雑制御の片端の展開は簡単で十分です。
For QUIC, if a proxy sits in the path between multiple origin servers and the access bottlenecks to multiple clients, then upgrading the proxy with a Scalable congestion control would provide the benefits of L4S over all the clients' downstream bottlenecks in one go -- whether or not all the origin servers were upgraded. Conversely, where a proxy has not been upgraded, the clients served by it will not benefit from L4S at all in the downstream, even when any origin server behind the proxy has been upgraded to support L4S.
QUICの場合、プロキシが複数のオリジンサーバーと複数のクライアントへのアクセスボトルネックの間のパスに配置されている場合、スケーラブルな混雑制御でプロキシをアップグレードすると、すべてのクライアントのダウンストリームボトルネックにおけるL4の利点が得られます - または、すべてのオリジンサーバーがアップグレードされたわけではありません。逆に、プロキシがアップグレードされていない場合、プロキシの背後にあるオリジンサーバーがL4Sをサポートするためにアップグレードされた場合でも、それが提供するクライアントは下流でL4の恩恵を受けません。
For TCP, a proxy upgraded to support 'TCP Prague' would provide the benefits of L4S downstream to all clients that support AccECN (whether or not they support L4S as well). And in the upstream, the proxy would also support AccECN as a receiver, so that any client deploying its own L4S support would benefit in the upstream direction, irrespective of whether any origin server beyond the proxy supported AccECN.
TCPの場合、「TCPプラハ」をサポートするためにアップグレードされたプロキシは、ACCECNをサポートするすべてのクライアントにL4Sの利点を提供します（L4もサポートするかどうか）。また、上流では、プロキシはレシーバーとしてのAccecnもサポートします。そのため、プロキシを超えてサポートされているAccecnを超えたOrigin Serverがサポートされているかどうかに関係なく、独自のL4Sサポートを展開するクライアントは上流の方向に利益を得ます。
3. This is a two-move stage to enable L4S upstream. An L4S AQM or TCP Prague can be deployed in either order as already explained. To motivate the first of two independent moves, the deferred benefit of enabling new services after the second move has to be worth it to cover the first mover's investment risk. As explained already, the potential for new interactive services provides this motivation. An L4S AQM also improves the upstream Classic service significantly if no other AQM has already been deployed.
3. これは、上流のL4Sを有効にするための2-Moveステージです。L4S AQMまたはTCPプラハは、すでに説明されているように、どちらの順序でも展開できます。2つの独立した動きの最初の動機を動機付けるために、2番目の動きの後に新しいサービスを有効にするという延期された利益は、最初のムーバーの投資リスクをカバーする価値がなければなりません。すでに説明されているように、新しいインタラクティブサービスの可能性はこの動機を提供します。L4S AQMは、他のAQMが既に展開されていない場合、上流のクラシックサービスも大幅に改善します。
Note that other deployment sequences might occur. For instance, the upstream might be deployed first; a non-TCP protocol might be used end to end, e.g., QUIC and RTP; a body, such as the 3GPP, might require L4S to be implemented in 5G user equipment; or other random acts of kindness might arise.
他の展開シーケンスが発生する可能性があることに注意してください。たとえば、上流が最初に展開される可能性があります。非TCPプロトコルは、End to End、例えばQUICやRTPを使用する場合があります。3GPPなどのボディでは、5Gユーザー機器にL4を実装する必要がある場合があります。または他のランダムな親切な行為が発生する可能性があります。
If L4S is enabled between two hosts, the L4S sender is required to coexist safely with Reno in response to any drop (see Section 4.3 of the L4S ECN spec [RFC9331]).
L4Sが2つのホスト間で有効になっている場合、L4S送信者は、ドロップに応じてRENOと安全に共存する必要があります（L4S ECN仕様[RFC9331]のセクション4.3を参照）。
Unfortunately, as well as protecting Classic traffic, this rule degrades the L4S service whenever there is any loss, even if the cause is not persistent congestion at a bottleneck, for example:
残念ながら、古典的なトラフィックを保護するだけでなく、このルールは、ボトルネックでの原因が持続的な混雑ではない場合でも、損失がある場合はいつでもL4Sサービスを分解します。
* congestion loss at other transient bottlenecks, e.g., due to bursts in shallower queues;
* 他の一時的なボトルネックでの混雑損失。たとえば、浅いキューのバーストによるもの。
* transmission errors, e.g., due to electrical interference; and
* たとえば、電気干渉による伝送エラー。と
* rate policing.
* ポリシングを評価します。
Three complementary approaches are in progress to address this issue, but they are all currently research:
この問題に対処するために3つの補完的なアプローチが進行中ですが、それらはすべて現在研究です。
* In Prague congestion control, ignore certain losses deemed unlikely to be due to congestion (using some ideas from BBR [BBR-CC] regarding isolated losses). This could mask any of the above types of loss while still coexisting with drop-based congestion controls.
* プラハの混雑制御では、混雑によるものとは考えられない特定の損失を無視します（隔離された損失に関するBBR [BBR-CC]のいくつかのアイデアを使用）。これにより、ドロップベースの混雑コントロールと共存している間、上記の種類の損失のいずれかを隠す可能性があります。
* A combination of Recent Acknowledgement (RACK) [RFC8985], L4S, and link retransmission without resequencing could repair transmission errors without the head of line blocking delay usually associated with link-layer retransmission [UnorderedLTE] [RFC9331].
* 最近の確認（RACK）[RFC8985]、L4S、およびリンク再送信の組み合わせは、リンク層の再送信に通常関連付けられているラインブロッキング遅延[UNORDEREDLTE] [RFC9331]を使用せずに、伝送エラーを修復できます。
* Hybrid ECN/drop rate policers (see Section 8.3).
* ハイブリッドECN/ドロップレートポリサー（セクション8.3を参照）。
L4S deployment scenarios that minimize these issues (e.g., over wireline networks) can proceed in parallel to this research, in the expectation that research success could continually widen L4S applicability.
これらの問題を最小限に抑えるL4S展開シナリオ（例：Wireline Networksなど）は、研究の成功がL4Sの適用性を継続的に拡大できると期待して、この研究と並行して進むことができます。
Classic ECN support is starting to materialize on the Internet as an increased level of CE marking. It is hard to detect whether this is all due to the addition of support for ECN in implementations of FQ-CoDel and/or FQ-COBALT, which is not generally problematic, because flow queue (FQ) scheduling inherently prevents a flow from exceeding the 'fair' rate irrespective of its aggressiveness. However, some of this Classic ECN marking might be due to single-queue ECN deployment. This case is discussed in Section 4.3 of the L4S ECN spec [RFC9331].
古典的なECNサポートは、CEマーキングのレベルの向上としてインターネット上で実現し始めています。これがFQコデルおよび/またはFQコバルトの実装におけるECNのサポートの追加によるものであるかどうかを検出するのは困難です。これは一般的に問題ではありません。フローキュー（FQ）スケジューリングは本質的にフローを超えるのを防ぐため、「公正」の攻撃性に関係なく。ただし、この古典的なECNマーキングの一部は、単一のECN展開によるものかもしれません。このケースは、L4S ECN仕様[RFC9331]のセクション4.3で説明されています。
An L4S AQM uses the ECN field to signal congestion. So in common with Classic ECN, if the AQM is within a tunnel or at a lower layer, correct functioning of ECN signalling requires standards-compliant propagation of the ECN field up the layers [RFC6040] [ECN-SHIM] [ECN-ENCAP].
L4S AQMは、ECNフィールドを使用して混雑を信号します。したがって、古典的なECNと共通して、AQMがトンネル内または下層にある場合、ECNシグナル伝達の正しい機能は、層の上にECNフィールドの標準に準拠した伝播を必要とします[RFC6040] [ECN-ENCAP]。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
In the current Internet, ISPs usually enforce separation between the capacity of shared links assigned to different 'sites' (e.g., households, businesses, or mobile users -- see terminology in Section 3) using some form of scheduler [RFC0970]. And they use various techniques, like redirection to traffic scrubbing facilities, to deal with flooding attacks. However, there has never been a universal need to police the rate of individual application flows -- the Internet has generally always relied on self-restraint of congestion controls at senders for sharing intra-'site' capacity.
現在のインターネットでは、ISPは通常、何らかの形のスケジューラ[RFC0970]を使用して、異なる「サイト」に割り当てられた共有リンク（世帯、企業、モバイルユーザーなど）の分離を強制します（例：世帯、企業、モバイルユーザー - セクション3の用語を参照）。また、洪水攻撃に対処するために、交通スクラブ施設へのリダイレクトなどのさまざまな手法を使用しています。ただし、個々のアプリケーションフローのレートを警察する普遍的なニーズはありませんでした。インターネットは一般に、「サイト内」の容量を共有するために、送信者の混雑制御の自己抑制に常に依存してきました。
L4S has been designed not to upset this status quo. If a DualQ is used to provide L4S service, Section 4.2 of [RFC9332] explains how it is designed to give no more rate advantage to unresponsive flows than a single-queue AQM would, whether or not there is traffic overload.
L4Sは、この現状を混乱させないように設計されています。DUALQを使用してL4Sサービスを提供する場合、[RFC9332]のセクション4.2は、シングルキューAQMよりも反応のないフローにレートの利点を与えないように設計されている方法を説明します。
Also, in case per-flow rate policing is ever required, it can be added because it is orthogonal to the distinction between L4S and Classic. As explained in Section 5.2, the DualQ variant of L4S provides low delay without prejudging the issue of flow-rate control. So if flow-rate control is needed, per-flow queuing (FQ) with L4S support can be used instead, or flow rate policing can be added as a modular addition to a DualQ. However, per-flow rate control is not usually deployed as a security mechanism, because an active attacker can just shard its traffic over more flow identifiers if the rate of each is restricted.
また、流量あたりのレートポリシングが必要な場合は、L4Sとクラシックの区別に直交するため、追加できます。セクション5.2で説明したように、L4SのDualQバリアントは、フローレート制御の問題を事前に判断することなく低遅延を提供します。したがって、フローレート制御が必要な場合は、L4Sサポートを備えた流量あたりのキューイング（FQ）を代わりに使用するか、フローレートポリシングをデュアルクへのモジュラー追加として追加できます。ただし、アクティブな攻撃者は、各レートが制限されている場合、アクティブな攻撃者はより多くのフロー識別子にわたってトラフィックを削減できるため、通常、フローあたりのレート制御はセキュリティメカニズムとして展開されません。
Section 5.2 explains how Diffserv only makes a difference if some packets get less favourable treatment than others, which typically requires traffic rate policing for a low latency class. In contrast, it should not be necessary to rate-police access to the L4S service to protect the Classic service, because L4S is designed to reduce delay without harming the delay or rate of any Classic traffic.
セクション5.2では、一部のパケットが他のパケットよりも好ましくない治療を受けた場合にのみ違いを生じる方法について説明します。対照的に、L4Sは古典的なトラフィックの遅延やレートを損なうことなく遅延を減らすように設計されているため、L4Sサービスを保護するためにL4Sサービスへのポリスを評価する必要はありません。
During early deployment (and perhaps always), some networks will not offer the L4S service. In general, these networks should not need to police L4S traffic. They are required (by both the ECN spec [RFC3168] and the L4S ECN spec [RFC9331]) not to change the L4S identifier, which would interfere with end-to-end congestion control. If they already treat ECN traffic as Not-ECT, they can merely treat L4S traffic as Not-ECT too. At a bottleneck, such networks will introduce some queuing and dropping. When a Scalable congestion control detects a drop, it will have to respond safely with respect to Classic congestion controls (as required in Section 4.3 of [RFC9331]). This will degrade the L4S service to be no better (but never worse) than Classic best efforts whenever a non-ECN bottleneck is encountered on a path (see Section 6.4.3).
早期展開中（そしておそらく常に）、一部のネットワークはL4Sサービスを提供しません。一般に、これらのネットワークはL4Sトラフィックを警察する必要はありません。それらは（ECN仕様[RFC3168]とL4S ECN仕様[RFC9331]の両方）L4S識別子を変更しないことが必要です。既にECNトラフィックを非ectとして扱っている場合、L4Sトラフィックを単に扱うだけではないと扱うこともできます。ボトルネックでは、そのようなネットワークはキューイングとドロップを導入します。スケーラブルな輻輳制御がドロップを検出すると、古典的なうっ血コントロールに関して安全に応答する必要があります（[RFC9331]のセクション4.3で必要な場合）。これにより、L4Sサービスは、ECN以外のボトルネックがパスで遭遇するたびに、古典的な最善の努力よりも優れていない（しかし、決して悪いことではない）になります（セクション6.4.3を参照）。
In cases that are expected to be rare, networks that solely support Classic ECN [RFC3168] in a single queue bottleneck might opt to police L4S traffic so as to protect competing Classic ECN traffic (for instance, see Section 6.1.3 of the L4S operational guidance [L4SOPS]). However, Section 4.3 of the L4S ECN spec [RFC9331] recommends that the sender adapts its congestion response to properly coexist with Classic ECN flows, i.e., reverting to the self-restraint approach.
まれであると予想される場合には、単一のキューで古典的なECN [RFC3168]のみをサポートするネットワークは、競合する古典的なECNトラフィックを保護するためにL4Sトラフィックを警察することを選択する可能性があります（たとえば、L4S運用のセクション6.1.3を参照してくださいガイダンス[L4SOPS]）。ただし、L4S ECN Spec [RFC9331]のセクション4.3は、送信者が混雑反応を適切に適応させ、古典的なECNフローと適切に共存することを推奨しています。
Certain network operators might choose to restrict access to the L4S service, perhaps only to selected premium customers as a value-added service. Their packet classifier (item 2 in Figure 1) could identify such customers against some other field (e.g., source address range), as well as classifying on the ECN field. If only the ECN L4S identifier matched, but not (say) the source address, the classifier could direct these packets (from non-premium customers) into the Classic queue. Explaining clearly how operators can use additional local classifiers (see Section 5.4 of [RFC9331]) is intended to remove any motivation to clear the L4S identifier. Then at least the L4S ECN identifier will be more likely to survive end to end, even though the service may not be supported at every hop. Such local arrangements would only require simple registered/not-registered packet classification, rather than the managed, application-specific traffic policing against customer-specific traffic contracts that Diffserv uses.
特定のネットワークオペレーターは、L4Sサービスへのアクセスを制限することを選択する場合があります。おそらく、選択されたプレミアム顧客には付加価値サービスとしてのみです。それらのパケット分類器（図1の項目2）は、ECNフィールドで分類するだけでなく、他のフィールド（例：ソースアドレス範囲）に対してそのような顧客を識別できます。ECN L4S識別子のみが一致したが、ソースアドレスとは一致しない場合、分類器はこれらのパケット（非プレミアムの顧客から）を古典的なキューに向けることができます。オペレーターが追加のローカル分類子を使用する方法を明確に説明する（[RFC9331]のセクション5.4を参照）は、L4S識別子をクリアする動機を削除することを目的としています。その場合、少なくともL4S ECN識別子は、すべてのホップでサービスがサポートされていない場合でも、端から端まで生き残る可能性が高くなります。このようなローカルアレンジメントでは、DiffServが使用する顧客固有のトラフィック契約に対するマネージドアプリケーション固有のトラフィックポリシングではなく、単純な登録/登録されていないパケット分類のみが必要です。
Like the Classic service, the L4S service relies on self-restraint to limit the rate in response to congestion. In addition, the L4S service requires self-restraint in terms of limiting latency (burstiness). It is hoped that self-interest and guidance on dynamic behaviour (especially flow start-up, which might need to be standardized) will be sufficient to prevent transports from sending excessive bursts of L4S traffic, given the application's own latency will suffer most from such behaviour.
古典的なサービスと同様に、L4Sサービスは自己抑制に依存して、混雑に応じてレートを制限します。さらに、L4Sサービスには、潜時を制限するという点で自己抑制が必要です（バーティネス）。ダイナミックな動作に関する自己利益とガイダンス（特に標準化する必要がある可能性があるフロースタートアップ）では、アプリケーションのレイテンシがそのように最も苦しむことを考えると、輸送がL4Sトラフィックの過度のバーストを送信するのを防ぐのに十分であることが期待されています。行動。
Because the L4S service can reduce delay without discernibly increasing the delay of any Classic traffic, it should not be necessary to police L4S traffic to protect the delay of Classic traffic. However, whether burst policing becomes necessary to protect other L4S traffic remains to be seen. Without it, there will be potential for attacks on the low latency of the L4S service.
L4Sサービスは、古典的なトラフィックの遅延を識別できるほど増やすことなく遅延を減らすことができるため、古典的なトラフィックの遅延を保護するためにL4Sトラフィックを警察する必要はありません。ただし、他のL4Sトラフィックを保護するためにバーストポリシングが必要になるかどうかはまだ不明です。それがなければ、L4Sサービスの低遅延に対する攻撃の可能性があります。
If needed, various arrangements could be used to address this concern:
必要に応じて、この懸念に対処するためにさまざまな取り決めを使用できます。
Local bottleneck queue protection: A per-flow (5-tuple) queue protection function [DOCSIS-Q-PROT] has been developed for the low latency queue in DOCSIS, which has adopted the DualQ L4S architecture. It protects the low latency service from any queue-building flows that accidentally or maliciously classify themselves into the low latency queue. It is designed to score flows based solely on their contribution to queuing (not flow rate in itself). Then, if the shared low latency queue is at risk of exceeding a threshold, the function redirects enough packets of the highest scoring flow(s) into the Classic queue to preserve low latency.
ローカルボトルネックキュー保護：フローごと（5タプル）キュー保護機能[docsis-q-prot]は、dualq L4Sアーキテクチャを採用したDocsisの低レイテンシキュー用に開発されました。誤ってまたは悪意を持って低レイテンシキューに分類するキュービルディングフローから低レイテンシサービスを保護します。キューイング（フローレート自体ではなく）への貢献だけに基づいてフローを獲得するように設計されています。次に、共有された低レイテンシーキューがしきい値を超えるリスクがある場合、関数は最高のスコアリングフローの十分なパケットをクラシックキューにリダイレクトして、低遅延を保持します。
Distributed traffic scrubbing: Rather than policing locally at each bottleneck, it may only be necessary to address problems reactively, e.g., punitively target any deployments of new bursty malware, in a similar way to how traffic from flooding attack sources is rerouted via scrubbing facilities.
分散型トラフィックスクラブ：各ボトルネックでローカルにポリシングするのではなく、洪水攻撃ソースからのトラフィックがスクラビングファシリティを介して再ルーティングされる方法と同様の方法で、新しいバーストマルウェアの展開を罰して標的にすることだけで問題に対処する必要がある場合があります。
Local bottleneck per-flow scheduling: Per-flow scheduling should inherently isolate non-bursty flows from bursty flows (see Section 5.2 for discussion of the merits of per-flow scheduling relative to per-flow policing).
ローカルボトルネックごとのスケジューリング：流量ごとのスケジューリングは、バーストフローから非燃えるフローを本質的に分離する必要があります（フローごとのポリシングと比較したフローごとのスケジューリングのメリットの議論については、セクション5.2を参照してください）。
Distributed access subnet queue protection: Per-flow queue protection could be arranged for a queue structure distributed across a subnet intercommunicating using lower layer control messages (see Section 2.1.4 of [QDyn]). For instance, in a radio access network, user equipment already sends regular buffer status reports to a radio network controller, which could use this information to remotely police individual flows.
分散アクセスサブネットキュー保護：フローごとのキュー保護は、下層制御メッセージを使用してサブネット間通信に分配されるキュー構造のために配置できます（[QDyn]のセクション2.1.4を参照）。たとえば、ラジオアクセスネットワークでは、ユーザー機器はすでに定期的なバッファーステータスレポートをラジオネットワークコントローラーに送信しており、この情報を使用して個々のフローをリモートで警察することができます。
Distributed Congestion Exposure to ingress policers: The Congestion Exposure (ConEx) architecture [RFC7713] uses an egress audit to motivate senders to truthfully signal path congestion in-band, where it can be used by ingress policers. An edge-to-edge variant of this architecture is also possible.
侵入ポリサーへの分散輻輳曝露：混雑暴露（CONEX）アーキテクチャ[RFC7713]は、出口監査を使用して、送信者を動機づけて、イングレスポリサーが使用できる帯域内のパス輻輳を誠実に信号することを行います。このアーキテクチャのエッジツーエッジバリアントも可能です。
Distributed domain-edge traffic conditioning: An architecture similar to Diffserv [RFC2475] may be preferred, where traffic is proactively conditioned on entry to a domain, rather than reactively policed only if it leads to queuing once combined with other traffic at a bottleneck.
分散ドメインエッジトラフィックコンディショニング：diffserv [RFC2475]に類似したアーキテクチャが好まれる場合があります。ここで、トラフィックは、ボトルネックでの他のトラフィックと組み合わせた場合にのみ、キューイングにつながる場合にのみ反応的にポリシングするのではなく、ドメインへの入力を積極的に条件付けられます。
Distributed core network queue protection: The policing function could be divided between per-flow mechanisms at the network ingress that characterize the burstiness of each flow into a signal carried with the traffic and per-class mechanisms at bottlenecks that act on these signals if queuing actually occurs once the traffic converges. This would be somewhat similar to [Nadas20], which is in turn similar to the idea behind core stateless fair queuing.
分散コアネットワークキュー保護：ポリシング関数は、各フローの爆発を特徴付けるネットワーク侵入での流量あたりのメカニズムに分割することができます。トラフィックが収束すると発生します。これは[NADAS20]に多少似ており、Core Stateless Fair Keuingの背後にあるアイデアに似ています。
No single one of these possible queue protection capabilities is considered an essential part of the L4S architecture, which works without any of them under non-attack conditions (much as the Internet normally works without per-flow rate policing). Indeed, even where latency policers are deployed, under normal circumstances, they would not intervene, and if operators found they were not necessary, they could disable them. Part of the L4S experiment will be to see whether such a function is necessary and which arrangements are most appropriate to the size of the problem.
これらの可能なキュー保護機能のいずれかは、L4Sアーキテクチャの重要な部分と見なされていません。これは、非攻撃条件の下ではそれらのいずれもなく動作します（インターネットが通常、フローレートポリシングなしで機能するのと同じように）。確かに、通常の状況下では、潜時ポリシーが展開されている場合でも、介入せず、オペレーターが必要でないと判断した場合、それらを無効にすることができます。L4S実験の一部は、そのような関数が必要かどうか、そしてどの配置が問題のサイズに最も適しているかを確認することです。
As mentioned in Section 5.2, L4S should remove the need for low latency Diffserv classes. However, those Diffserv classes that give certain applications or users priority over capacity would still be applicable in certain scenarios (e.g., corporate networks). Then, within such Diffserv classes, L4S would often be applicable to give traffic low latency and low loss as well. Within such a Diffserv class, the bandwidth available to a user or application is often limited by a rate policer. Similarly, in the default Diffserv class, rate policers are sometimes used to partition shared capacity.
セクション5.2で述べたように、L4Sは低レイテンシDiffServクラスの必要性を削除する必要があります。ただし、特定のアプリケーションまたはユーザーが容量よりも優先されるようにするDiffServクラスは、特定のシナリオ（例：企業ネットワーク）でまだ適用されます。その後、このようなDiffServクラス内では、L4Sがトラフィックが低下し、損失が低いことにも適用されることがよくあります。このようなdiffservクラス内では、ユーザーまたはアプリケーションが利用できる帯域幅は、レートポリサーによって制限されることがよくあります。同様に、デフォルトのDiffServクラスでは、レートポリサーが共有容量を分割するために使用されることがあります。
A Classic rate policer drops any packets exceeding a set rate, usually also giving a burst allowance (variants exist where the policer re-marks noncompliant traffic to a discard-eligible Diffserv codepoint, so they can be dropped elsewhere during contention). Whenever L4S traffic encounters one of these rate policers, it will experience drops and the source will have to fall back to a Classic congestion control, thus losing the benefits of L4S (Section 6.4.3). So in networks that already use rate policers and plan to deploy L4S, it will be preferable to redesign these rate policers to be more friendly to the L4S service.
古典的なレートポリサーは、設定レートを超えるパケットをドロップし、通常はバースト手当（バリアントが存在します（ポリサーが廃棄対象のdiffserv codePointに非接続トラフィックを再マークするため、競合中に他の場所にドロップできます）。L4Sトラフィックがこれらのレートポリサーの1つに遭遇すると、ドロップが発生し、ソースは古典的な混雑コントロールに戻る必要があり、L4Sの利点を失う必要があります（セクション6.4.3）。そのため、既にレートポリサーを使用しており、L4Sを展開することを計画しているネットワークでは、これらのレートポリサーを再設計して、L4Sサービスにより友好的になることが望ましいでしょう。
L4S-friendly rate policing is currently a research area (note that this is not the same as latency policing). It might be achieved by setting a threshold where ECN marking is introduced, such that it is just under the policed rate or just under the burst allowance where drop is introduced. For instance, the two-rate, three-colour marker [RFC2698] or a PCN threshold and excess-rate marker [RFC5670] could mark ECN at the lower rate and drop at the higher. Or an existing rate policer could have congestion-rate policing added, e.g., using the 'local' (non-ConEx) variant of the ConEx aggregate congestion policer [CONG-POLICING]. It might also be possible to design Scalable congestion controls to respond less catastrophically to loss that has not been preceded by a period of increasing delay.
L4Sに優しいレートポリシングは現在、研究分野です（これはレイテンシポリシングと同じではないことに注意してください）。ECNマーキングが導入されるしきい値を設定することで達成される可能性があります。これにより、ポリシーレートのすぐ下またはドロップが導入されるバースト手当のすぐ下にあります。たとえば、2レートの3色マーカー[RFC2698]またはPCNしきい値と過剰率マーカー[RFC5670]は、ECNを低いレートでマークし、高で低下する可能性があります。または、既存のレートポリサーには、Conex Aggregate混雑ポリサー[Cong-Policing]の「ローカル」（非コネックス）バリアントを使用して、混雑レートポリシングを追加する可能性があります。また、スケーラブルな輻輳制御を設計して、遅延の期間が先行していない損失に対する壊滅的な反応を少なくすることも可能かもしれません。
The design of L4S-friendly rate policers will require a separate, dedicated document. For further discussion of the interaction between L4S and Diffserv, see [L4S-DIFFSERV].
L4Sに優しいレートポリサーの設計には、独立した専用のドキュメントが必要です。L4Sとdiffserv間の相互作用の詳細については、[L4S-Diffserv]を参照してください。
Various ways have been developed to protect the integrity of the congestion feedback loop (whether signalled by loss, Classic ECN, or L4S ECN) against misbehaviour by the receiver, sender, or network (or all three). Brief details of each, including applicability, pros, and cons, are given in Appendix C.1 of the L4S ECN spec [RFC9331].
受信者、送信者、またはネットワーク（または3つすべて）による不正行為に対する輻輳フィードバックループ（損失、古典的なECN、またはL4S ECNによってシグナル化されているかどうか）の完全性を保護するために、さまざまな方法が開発されました。適用性、長所、短所を含むそれぞれの簡単な詳細については、L4S ECN仕様の付録C.1に記載されています[RFC9331]。
As discussed in Section 5.2, the L4S architecture does not preclude approaches that inspect end-to-end transport layer identifiers. For instance, L4S support has been added to FQ-CoDel, which classifies by application flow identifier in the network. However, the main innovation of L4S is the DualQ AQM framework that does not need to inspect any deeper than the outermost IP header, because the L4S identifier is in the IP-ECN field.
セクション5.2で説明したように、L4Sアーキテクチャは、エンドツーエンドの輸送層識別子を検査するアプローチを排除しません。たとえば、L4SサポートはFQコデルに追加されており、ネットワーク内のアプリケーションフロー識別子によって分類されます。ただし、L4Sの主な革新は、L4S識別子がIP-ECNフィールドにあるため、最も外側のIPヘッダーよりも深いIPヘッダーよりも深い検査を行う必要のないDualQ AQMフレームワークです。
Thus, the L4S architecture enables very low queuing delay without _requiring_ inspection of information above the IP layer. This means 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].
したがって、L4Sアーキテクチャは、IPレイヤーの上の情報を_requiring_検査せずに非常に低いキューイング遅延を可能にします。これは、アプリケーションフロー識別子を暗号化したいユーザー、たとえば、IPSECまたはその他の暗号化されたVPNトンネルで、低遅延を犠牲にする必要はないことを意味します[RFC8404]。
Because L4S can provide low delay for a broad set of applications that choose to use it, there is no need for individual applications or classes within that broad set to be distinguishable in any way while traversing networks. This removes much of the ability to correlate between the delay requirements of traffic and other identifying features [RFC6973]. There may be some types of traffic that prefer not to use L4S, but the coarse binary categorization of traffic reveals very little that could be exploited to compromise privacy.
L4Sは、使用することを選択する幅広いアプリケーションに低い遅延を提供できるため、ネットワークを通過する際に、その幅広いセット内の個々のアプリケーションまたはクラスを何らかの形で区別できる必要はありません。これにより、トラフィックの遅延要件と他の識別機能[RFC6973]との間に相関する能力の多くが削除されます。L4を使用しないことを好むトラフィックにはいくつかの種類があるかもしれませんが、トラフィックの粗いバイナリ分類は、プライバシーを妥協するために悪用される可能性のあるものをほとんど明らかにしていません。
[ACCECN] Briscoe, B., Khlewind, M., and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, Internet-Draft, draft-ietf-tcpm-accurate-ecn-22, 9 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-22>.
[Accecn] Briscoe、B.、Khlewind、M。、およびR. Scheffenegger、「TCPでのより正確なECNフィードバック」、Work in Progress、Internet-Draft、Draft-IITF-TCPM-Accurate-ECN-22、2022年11月9日、<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-22>。
[AFCD] Xue, L., Kumar, S., Cui, C., Kondikoppa, P., Chiu, C-H., and S-J. Park, "Towards fair and low latency next generation high speed networks: AFCD queuing", Journal of Network and Computer Applications, Volume 70, pp. 183-193, DOI 10.1016/j.jnca.2016.03.021, July 2016, <https://doi.org/10.1016/j.jnca.2016.03.021>.
[AFCD] Xue、L.、Kumar、S.、Cui、C.、Kondikoppa、P.、Chiu、C-H。、およびS-J。パーク、「公正および低レイテンシの次世代高速ネットワーク：AFCDキューイング」、Journal of Network and Computer Applications、Volume 70、pp。183-193、DOI 10.1016/j.jnca.2016.03.021、2016年7月、<https：//doi.org/10.1016/j.jnca.2016.03.021>。
[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>。
[BDPdata] Briscoe, B., "PI2 Parameters", TR-BB-2021-001, arXiv:2107.01003 [cs.NI], DOI 10.48550/arXiv.2107.01003, October 2021, <https://arxiv.org/abs/2107.01003>.
[BDPDATA] Briscoe、B。、「Pi2パラメーター」、TR-BB-2021-001、Arxiv：2107.01003 [Cs.ni]、doi 10.48550/arxiv.2107.01003、2021年10月、<https://arxiv.org/abss/2107.01003>。
[BufferSize] Appenzeller, G., Keslassy, I., and N. McKeown, "Sizing Router Buffers", SIGCOMM '04: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 281-292, DOI 10.1145/1015467.1015499, October 2004, <https://doi.org/10.1145/1015467.1015499>.
[Buffersize] Appenzeller、G.、Keslassy、I。、およびN. McKeown、「サイジングルーターバッファー」、Sigcomm '04：コンピューター通信のためのアプリケーション、技術、建築、プロトコルに関する2004年の会議の議事録、281-ページ292、DOI 10.1145/1015467.1015499、2004年10月、<https://doi.org/10.1145/1015467.1015499>。
[COBALT] Palmei, J., Gupta, S., Imputato, P., Morton, J., Tahiliani, M. P., Avallone, S., and D. Tht, "Design and Evaluation of COBALT Queue Discipline", IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), DOI 10.1109/LANMAN.2019.8847054, July 2019, <https://ieeexplore.ieee.org/abstract/document/8847054>.
[コバルト] Palmei、J.、Gupta、S.、Inputato、P.、Morton、J.、Tahiliani、M.P.、Avallone、S.、およびD. Tht、「コバルトキューの規律の設計と評価」、IEEE International Symposiumローカルおよびメトロポリタンエリアネットワーク（LANMAN）、DOI 10.1109/LANMAN.2019.8847054、2019年7月、<https://ieeexplore.ieee.org/abstract/document/8847054>。
[CODEL-APPROX-FAIR] Morton, J. and P. Heist, "Controlled Delay Approximate Fairness AQM", Work in Progress, Internet-Draft, draft-morton-tsvwg-codel-approx-fair-01, 9 March 2020, <https://datatracker.ietf.org/doc/html/draft-morton-tsvwg-codel-approx-fair-01>.
[Codel-Approx-Fair] Morton、J。およびP. Heist、「制御された遅延概算公平性AQM」、作業中の作業、インターネットドラフト、ドラフトモートン-TSVWGコデルアプロックスフェア-01、2020年3月9日、<https://datatracker.ietf.org/doc/html/draft-morton-tsvwg-codel-approx-fair-01>。
[CONG-POLICING] Briscoe, B., "Network Performance Isolation using Congestion Policing", Work in Progress, Internet-Draft, draft-briscoe-conex-policing-01, 14 February 2014, <https://datatracker.ietf.org/doc/html/draft-briscoe-conex-policing-01>.
[Cong-Policing] Briscoe、B。、「混雑ポリシングを使用したネットワークパフォーマンスの分離」、作業中の作業、インターネットドラフト、Draft-Briscoe-Conex-Policing-01、2014年2月14日、<https：//datatracker.ietf。org/doc/html/draft-briscoe-conex-policing-01>。
[CTCP] Sridharan, M., Tan, K., Bansal, D., and D. Thaler, "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Work in Progress, Internet-Draft, draft-sridharan-tcpm-ctcp-02, 11 November 2008, <https://datatracker.ietf.org/doc/html/draft-sridharan-tcpm-ctcp-02>.
[CTCP] Sridharan、M.、Tan、K.、Bansal、D。、およびD. Thaler、「化合物TCP：高速および長距離ネットワークの新しいTCP混雑制御」、進行中の作業、インターネットドラフト、Draft-sridharan-tcpm-ctcp-02、2008年11月11日、<https://datatracker.ietf.org/doc/html/draft-sridharan-tcpm-ctcp-02>。
[DOCSIS-Q-PROT] Briscoe, B., Ed. and G. White, "The DOCSIS Queue Protection Algorithm 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-Q-Protection-06、2022年5月13日、<https：//datatracker.ietf。org/doc/html/draft-briscoe-docsis-q-portection-06>。
[DOCSIS3.1] CableLabs, "MAC and Upper Layer Protocols Interface (MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable Service Interface Specifications DOCSIS 3.1 Version i17 or later, 21 January 2019, <https://specification-search.cablelabs.com/CM-SP-MULPIv3.1>.
[docsis3.1] cablelabs、 "Macおよび上層層プロトコルインターフェイス（Mulpi）仕様、CM-SP-Mulpiv3.1"、データオーバーケーブルサービスインターフェイス仕様DOCSIS 3.1バージョンI17以降、2019年1月21日、<HTTPS：//specification-search.cablelabs.com/cm-spmulpiv3.1>。
[DOCSIS3AQM] White, G., "Active Queue Management Algorithms for DOCSIS 3.0: A Simulation Study of CoDel, SFQ-CoDel and PIE in DOCSIS 3.0 Networks", CableLabs Technical Report, April 2013, <https://www.cablelabs.com/wp-content/uploads/2013/11/ Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf>.
[docsis3aqm] White、G。、「Docsis 3.0のアクティブキュー管理アルゴリズム：Docsis 3.0ネットワークのコーデル、SFQコデル、およびパイのシミュレーション研究」、Cablelabsテクニカルレポート、2013年4月、<https：//www.cablelabs。com/wp-content/uploads/2013/11/active_queue_management_algorithms_docsis_3_0.pdf>。
[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>。
[Dukkipati06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is the Right Metric for Congestion Control", ACM SIGCOMM Computer Communication Review, Volume 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、Volume 36、Issue 1、pp。59-62、DOI 10.1145/1111322.111136、2006年1月、<https://dl.acm.org/doi/10.1145/1111322.1111336>。
[ECN-ENCAP] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-encap-guidelines-17, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>.
[ECN-ENCAP] Briscoe、B。およびJ. Kaippallimalil、「IPをカプセル化するプロトコルに混雑通知を追加するためのガイドライン」、進行中の作業、インターネットドラフト、ドラフト-TSVWG-ECN-ECDAP-GUIDERINES-17、11 112022年7月、<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>。
[ECN-SCTP] Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Control Transmission Protocol (SCTP)", Work in Progress, Internet-Draft, draft-stewart-tsvwg-sctpecn-05, 15 January 2014, <https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctpecn-05>.
[ECN-SCTP] Stewart、R.、Tuexen、M。、およびX. Dong、「Stream Control Transmission Protocol（SCTP）のECN」、Work in Progress、Internet-Draft、Draft-Stewart-TSVWG-SCTPECN-05、2014年1月15日、<https://datatracker.ietf.org/doc/html/draft-stewart-tsvwg-sctpecn-05>。
[ECN-SHIM] Briscoe, B., "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim", Work in Progress, Internet-Draft, draft-ietf-tsvwg-rfc6040update-shim-15, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-15>.
[ECN-Shim] Briscoe、B。、「シムで区切られたIPトンネルヘッダー全体で明示的な混雑通知を伝播する」、進行中の作業、インターネットドラフト、ドラフト-IITF-TSVWG-RFC6040404040402222222、<<<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-15>。
[FQ_CoDel_Thresh] "fq_codel: generalise ce_threshold marking for subset of traffic", commit dfcb63ce1de6b10b, October 2021, <https://git.kernel.org/pub/scm/linux/kernel/git/netdev/ net-next.git/commit/?id=dfcb63ce1de6b10b>.
[fq_codel_thresh] "fq_codel：トラフィックのサブセットのce_thresholdマーキングを一般化する"、dfcb63ce1de6b10bをコミットします。コミット/？id = dfcb63ce1de6b10b>。
[Hohlfeld14] Hohlfeld, O., Pujol, E., Ciucu, F., Feldmann, A., and P. Barford, "A QoE Perspective on Sizing Network Buffers", IMC '14: Proceedings of the 2014 Conference on Internet Measurement, pp. 333-346, DOI 10.1145/2663716.2663730, November 2014, <https://doi.acm.org/10.1145/2663716.2663730>.
[Hohlfeld14] Hohlfeld、O.、Pujol、E.、Ciucu、F.、Feldmann、A。、およびP. Barford、「サイジングネットワークバッファーに関するQoEの視点」、IMC '14：インターネット測定に関する2014年の会議の議事録、pp。333-346、DOI 10.1145/2663716.2663730、2014年11月、<https://doi.acm.org/10.1145/2663716.2663730>。
[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>。
[L4Sdemo16-Video] "Videos used in IETF dispatch WG 'Ultra-Low Queuing Delay for All Apps' slot", <https://riteproject.eu/dctth/#1511dispatchwg>.
[L4SDEMO16-Video]「すべてのアプリ「スロット」のIETFディスパッチWG 'Ultra-low Queuing Delay」、<https://riteproject.eu/dctth/#1511dispatchwg>。
[L4Seval22] De Schepper, K., Albisser, O., Tilmans, O., and B. Briscoe, "Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All", TR-BB-2022-001, arXiv:2209.01078 [cs.NI], 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：すべての展開可能な非常に低いキューイング遅延」、TR-BB-2022-001、ARXIV：2209.010788[cs.ni]、doi 10.48550/arxiv.2209.01078、2022年9月、<https://arxiv.org/abs/2209.01078>。
[L4SOPS] White, G., Ed., "Operational Guidance for Deployment of L4S in the Internet", Work in Progress, Internet-Draft, draft-ietf-tsvwg-l4sops-03, 28 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4sops-03>.
[L4SOPS] White、G.、ed。、「インターネットでのL4の展開のための運用ガイダンス」、進行中の作業、インターネットドラフト、ドラフト-ITSF-TSVWG-L4SOPS-03、2022年4月28日、<https：//datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4sops-03>。
[LEDBAT_AQM] Al-Saadi, R., Armitage, G., and J. But, "Characterising LEDBAT Performance Through Bottlenecks Using PIE, FQ-CoDel and FQ-PIE Active Queue Management", IEEE 42nd Conference on Local Computer Networks (LCN), DOI 10.1109/LCN.2017.22, October 2017, <https://ieeexplore.ieee.org/document/8109367>.
[LEDBAT_AQM] Al-Saadi、R.、Armitage、G。、およびJ. But、「Pie、FQ-Codel、FQ-Pie Active Keue Managementを使用したボトルネックを通じてLedbatパフォーマンスを特徴づける」、IEEE 42nd Conference on Local Computer（LCN）、doi 10.1109/lcn.2017.22、2017年10月、<https://ieeexplore.ieee.org/document/8109367>。
[lowat] Meenan, P., "Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowat", Cloudflare Blog, October 2018, <https://blog.cloudflare.com/http-2-prioritization-with-nginx/>.
[Lowat] Meenan、P。、「BBRおよびTCP_NOTSENT_LOWATによるHTTP/2の優先順位付けの最適化」、CloudFlareブログ、2018年10月、<https://blog.cloudflare.com/http-2-prioritization-with-nginx/>。
[McIlroy78] McIlroy, M.D., Pinson, E. N., and B. A. Tague, "UNIX Time-Sharing System: Foreword", The Bell System Technical Journal 57: 6, pp. 1899-1904, DOI 10.1002/j.1538-7305.1978.tb02135.x, July 1978, <https://archive.org/details/bstj57-6-1899>.
[McIlroy78] McIlroy、M.D.、Pinson、E。N.、およびB. A. Tague、「Unix Time-Sharing System：Foreword」、The Bell System Technical Journal 57：6、pp。1899-1904、doi 10.1002/J.1538-7305.1978.TB021355.x、1978年7月、<https://archive.org/details/bstj57-6-1899>。
[Nadas20] Ndas, S., Gombos, G., Fejes, F., and S. Laki, "A Congestion Control Independent L4S Scheduler", ANRW '20: Proceedings of the Applied Networking Research Workshop, pp. 45-51, DOI 10.1145/3404868.3406669, July 2020, <https://doi.org/10.1145/3404868.3406669>.
[Nadas20] Ndas、S.、Gombos、G.、Fejes、F。、およびS. Laki、「混雑制御独立L4Sスケジューラ」、ANRW '20：Applied Networking Research Workshopの議事録、45-51ページ、pp。45-51、doi 10.1145/3404868.3406669、2020年7月、<https://doi.org/10.1145/3404868.340669>。
[NASA04] Bailey, R., Trey Arthur III, J., and S. Williams, "Latency Requirements for Head-Worn Display S/EVS Applications", Proceedings of SPIE 5424, DOI 10.1117/12.554462, April 2004, <https://ntrs.nasa.gov/api/citations/20120009198/ downloads/20120009198.pdf?attachment=true>.
[NASA04] Bailey、R.、Trey Arthur III、J。、およびS. Williams、「Head Worn Display S/EVSアプリケーションの待ち時間要件」、SPIE 5424の議事録、DOI 10.1117/12.554462、2004年4月、<https：//ntrs.nasa.gov/api/citations/20120009198/ downloads/20120009198.pdf？attachment = true>。
[NQB-PHB] White, G. and T. Fossati, "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services", Work in Progress, Internet-Draft, draft-ietf-tsvwg-nqb-15, 11 January 2023, <https://datatracker.ietf.org/doc/html/ draft-ietf-tsvwg-nqb-15>.
[NQB-PHB] White、G。およびT. Fossati、「差別化されたサービスのための非キュービルディングあたりの動作（NQB PHB）」、進行中の作業、インターネットドラフト、ドラフト-TSVWG-NQB-15、2023年1月11日、<https://datatracker.ietf.org/doc/html/ draft-ietf-tsvwg-nqb-15>。
[PRAGUE-CC] De Schepper, K., Tilmans, O., and B. Briscoe, Ed., "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、ed。、「Prague commestion Control」、Work in Progress、Internet-Draft、Draft-Briscoe-Iccrg-Prague-Congestion-Control--01、2022年7月11日、<https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01>。
[PragueLinux] Briscoe, B., De Schepper, K., Albisser, O., Misund, J., Tilmans, O., Khlewind, M., and A.S. Ahmed, "Implementing the 'TCP Prague' Requirements for Low Latency Low Loss Scalable Throughput (L4S)", Proceedings 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.、Khlewind、M。、およびA.S.Ahmed、「低潜伏期低損失スケーラブルスループット（L4S）の「TCPプラハ」要件の実装」、Proceedings Linux NetDev 0x13、2019年3月、<https://www.netdevconf.org/0x13/ session.html？-prague-l4s>。
[QDyn] Briscoe, B., "Rapid Signalling of Queue Dynamics", TR-BB-2017-001, arXiv:1904.07044 [cs.NI], DOI 10.48550/arXiv.1904.07044, April 2019, <https://arxiv.org/abs/1904.07044>.
[Qdyn] Briscoe、B。、「キューダイナミクスの迅速なシグナル伝達」、TR-BB-2017-001、Arxiv：1904.07044 [Cs.ni]、doi 10.48550/arxiv.1904.07044、2019年4月、<https：// arxiv。org/abs/1904.07044>。
[Raaen14] Raaen, K. and T-M. Grnli, "Latency Thresholds for Usability in Games: A Survey", Norsk IKT-konferanse for forskning og utdanning (Norwegian ICT conference for research and education), 2014, <http://ojs.bibsys.no/index.php/NIK/article/view/9/6>.
[Raaen14] Raaen、K。およびT-M。Grnli、「ゲームでの使いやすさのレイテンシのしきい値：調査」、Norsk Ikt-Konferanse for forskning og utdanning（研究と教育のためのノルウェーICT会議）、2014年、<http://ojs.bibsys.no/index.php/nik/記事/ビュー/9/6>。
[Rajiullah15] Rajiullah, M., "Towards a Low Latency Internet: Understanding and Solutions", Dissertation, Karlstad University, 2015, <https://www.diva-portal.org/smash/get/diva2:846109/FULLTEXT01.pdf>.
[Rajiullah15] Rajiullah、M。、「低レイテンシインターネット：理解と解決策に向けて」、論文、Karlstad University、2015、<https://www.diva-portal.org/smash/get/diva2:846109/fulltext01。pdf>。
[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>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、DOI 10.17487/RFC2475、12月1998、<https://www.rfc-editor.org/info/rfc2475>。
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, <https://www.rfc-editor.org/info/rfc2698>.
[RFC2698] Heinanen、J。およびR. Guerin、「2つのレート3色マーカー」、RFC 2698、DOI 10.17487/RFC2698、1999年9月、<https://www.rfc-editor.org/info/rfc2698>
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, DOI 10.17487/RFC2884, July 2000, <https://www.rfc-editor.org/info/rfc2884>.
[RFC2884] Hadi Salim、J。およびU. Ahmed、「IPネットワークにおける明示的な混雑通知（ECN）のパフォーマンス評価」、RFC 2884、DOI 10.17487/RFC2884、2000年7月、<https：//www.rfc-editor。org/info/rfc2884>。
[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>。
[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>。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, DOI 10.17487/RFC3540, June 2003, <https://www.rfc-editor.org/info/rfc3540>.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、DOI 10.17487/RFC3540、2003年6月、<https：//www.rfcc-editor.org/info/rfc3540>。
[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>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487/RFC4340、2006年3月、<https：//www.rfc-editor。org/info/rfc4340>。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, <https://www.rfc-editor.org/info/rfc4774>.
[RFC4774] Floyd、S。、「明示的な混雑通知（ECN）フィールドの代替セマンティクスの指定」、BCP 124、RFC 4774、DOI 10.17487/RFC4774、2006年11月、<https：//www.rfc-editor.org/情報/RFC4774>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487/RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[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>。
[RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, DOI 10.17487/RFC5670, November 2009, <https://www.rfc-editor.org/info/rfc5670>.
[RFC5670] Eardley、P.、ed。、「PCN-Nodesの計測とマーキングの動作」、RFC 5670、DOI 10.17487/RFC5670、2009年11月、<https://www.rfc-editor.org/info/RFC5670>。
[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>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「明示的な混雑通知のトンネル」、RFC 6040、DOI 10.17487/RFC6040、2010年11月、<https://www.rfc-editor.org/info/rfc6040>
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <https://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「UDPを介したRTPの明示的な混雑通知（ECN）」、RFC 6679、DOI 10.17487/RFC6799999、2012年8月、<https://www.rfc-editor.org/info/rfc6679>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、 "Low Extra Delay Background Transport（LEDBAT）"、RFC 6817、DOI 10.17487/RFC6817、2012、<https：///www.rfc-editor.org/info/rfc6817>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、doi10.17487/rfc6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, "Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback", RFC 7560, DOI 10.17487/RFC7560, August 2015, <https://www.rfc-editor.org/info/rfc7560>.
[RFC7560] Kuehlewind、M.、ed。、Scheffenegger、R.、およびB. Briscoe、「明示的な混雑通知（ECN）フィードバックの精度の向上の問題声明と要件」、RFC 7560、DOI 10.17487/RFC7560、2015年8月、<https://www.rfc-editor.org/info/rfc7560>。
[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>
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、ed。and C. Pignataro、ed。、「サービス関数チェーン（SFC）アーキテクチャ」、RFC 7665、DOI 10.17487/RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc765>。
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, <https://www.rfc-editor.org/info/rfc7713>.
[RFC7713] Mathis、M。およびB. Briscoe、「混雑暴露（Conex）の概念、抽象的なメカニズム、および要件」、RFC 7713、DOI 10.17487/RFC7713、2015年12月、<https://www.rfc-editor.orgg/info/rfc7713>。
[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>。
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8170] Thaler、D.、ed。、「プロトコルの採用とその後の遷移の計画」、RFC 8170、DOI 10.17487/RFC8170、2017年5月、<https://www.rfc-editor.org/info/rfc8170>
[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 Data Centerの混雑制御」、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>。
[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>。
[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>。
[RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", RFC 8511, DOI 10.17487/RFC8511, December 2018, <https://www.rfc-editor.org/info/rfc8511>.
[RFC8511] Khademi、N.、Welzl、M.、Armitage、G。、およびG. Fairhurst、「ECN（ABE）とのTCP代替バックオフ」、RFC 8511、DOI 10.17487/RFC8511、2018年12月、<https：////////www.rfc-editor.org/info/rfc8511>。
[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", RFC 8888, DOI 10.17487/RFC8888, January 2021, <https://www.rfc-editor.org/info/rfc8888>.
[RFC8888] Sarker、Z.、Perkins、C.、Singh、V。、およびM. Ramalho、「RTPコントロールプロトコル（RTCP）輻輳制御のフィードバック」、RFC 8888、DOI 10.17487/RFC8888、2021年1月、<HTTPS：//www.rfc-editor.org/info/rfc8888>。
[RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, DOI 10.17487/RFC8985, February 2021, <https://www.rfc-editor.org/info/rfc8985>.
[RFC8985] Cheng、Y.、Cardwell、N.、Dukkipati、N.、およびP. Jha、「TCPのRack-TLP損失検出アルゴリズム」、RFC 8985、DOI 10.17487/RFC8985、2月2021年、<https：/<https：//www.rfc-editor.org/info/rfc8985>。
[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>
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[RFC9113] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[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>。
[RFC9332] De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9332, DOI 10.17487/RFC9332, January 2023, <https://www.rfc-editor.org/info/rfc9332>.
[RFC9332] De Schepper、K.、Briscoe、B.、Ed。、およびG. White、「低レイテンシ、低損失、スケーラブルスループット（L4S）のためのデュアルキュー結合アクティブキュー管理（AQM）」、RFC 9332、doi 10.17487/rfc9332、2023年1月、<https://www.rfc-editor.org/info/rfc9332>。
[SCReAM-L4S] "SCReAM", commit fda6c53, June 2022, <https://github.com/EricssonResearch/scream>.
[Scream-l4s] "Scream"、commit fda6c53、2022年6月、<https://github.com/ericssonresearch/scream>。
[TCP-CA] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", Laurence Berkeley Labs Technical Report , November 1988, <https://ee.lbl.gov/papers/congavoid.pdf>.
[TCP-CA]ジェイコブソン、V。およびM.カレル、「混雑の回避とコントロール」、ローレンス・バークレーラボテクニカルレポート、1988年11月、<https://ee.lbl.gov/papers/congavoid.pdf>。
[UnorderedLTE] Austrheim, M., "Implementing immediate forwarding for 4G in a network simulator", Master's Thesis, University of Oslo, 2018.
[Unoderedlte] Austrheim、M。、「ネットワークシミュレーターで4Gの即時転送の実装」、Master's論文、オスロ大学、2018年。
Acknowledgements
謝辞
Thanks to Richard Scheffenegger, Wes Eddy, Karen Nielsen, David Black, Jake Holland, Vidhi Goel, Ermin Sakic, Praveen Balasubramanian, Gorry Fairhurst, Mirja Kuehlewind, Philip Eardley, Neal Cardwell, Pete Heist, and Martin Duke for their useful review comments. Thanks also to the area reviewers: Marco Tiloca, Lars Eggert, Roman Danyliw, and ric Vyncke.
リチャード・シェフェネッガー、ウェス・エディ、カレン・ニールセン、デビッド・ブラック、ジェイク・ホランド、ヴィディ・ゴエル、エルミン・サキッチ、プラヴェン・バラスブラマニアン、ゴーリー・フェアハースト、ミルジャ・キュールウィンド、フィリップ・アードリー、ニール・カードウェル、ペテ・ヘイスト、そして彼らの有用なレビューのコメントのために、マルコ・ティロカ、ラース・エガート、ロマン・ダニリウ、リック・ヴィンケ：地域のレビュアーにも感謝します。
Bob Briscoe and Koen De Schepper were partly funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The contribution of Koen De Schepper was also partly funded by the 5Growth and DAEMON EU H2020 projects. Bob Briscoe was also partly funded by the Research Council of Norway through the TimeIn project, partly by CableLabs, and partly by the Comcast Innovation Fund. The views expressed here are solely those of the authors.
Bob BriscoeとKoen de Schepperは、還元インターネットトランスポートレイテンシ（Rite）プロジェクト（ICT-317700）を通じて、7番目のフレームワークプログラムの下で欧州共同体によって部分的に資金提供されました。Koen de Schepperの貢献は、5成長とDaemon Eu H2020プロジェクトによっても部分的に資金提供されていました。ボブ・ブリスコーはまた、ノルウェーの研究評議会によって、一部はケーブルラブによって、そして一部はコムキャスイノベーション基金によって、一部は部分的に資金提供されていました。ここで表明された見解は、著者の見解だけです。
Authors' Addresses
著者のアドレス
Bob Briscoe (editor) Independent United Kingdom Email: ietf@bobbriscoe.net URI: https://bobbriscoe.net/
Bob Briscoe（編集者）独立した英国電子メール：ietf@bobbriscoe.net uri：https：//bobbriscoe.net/
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/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 28911 Madrid Spain Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: https://www.it.uc3m.es
Marcelo Bagnulo Universidad Carlos III de Madrid av。Universidad 30 28911 Madrid Spain電話：34 91 6249500メール：marcelo@it.uc3m.ES URI：https：//www.it.uc3m.ES
Greg White CableLabs United States of America Email: G.White@CableLabs.com
Greg White CableLabs United States of America Email：g.white@cablelabs.com