[要約] RFC 9331 は、Low Latency, Low Loss, and Scalable Throughput (L4S) サービスのための Explicit Congestion Notification (ECN) プロトコルを定義し、L4S は低遅延、低損失、スケーラブルなスループットを提供することを目的としています。 L4S は、Classic とは異なる ECN スキームを使用し、Scalable 混雑制御を採用して、低遅延と高帯域幅を同時に実現することを可能にします。
Internet Engineering Task Force (IETF) K. De Schepper
Request for Comments: 9331 Nokia Bell Labs
Category: Experimental B. Briscoe, Ed.
ISSN: 2070-1721 Independent
January 2023
The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
低潜伏期、低損失、スケーラブルスループット（L4S）のための明示的な混雑通知（ECN）プロトコル
Abstract
概要
This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.
この仕様では、低レイテンシ、低損失、スケーラブルスループット（L4S）と呼ばれる新しいネットワークサービスに使用されるプロトコルを定義します。L4Sは、指定されている場合を除き、元の（または「クラシック」）ECNアプローチに似たIPレイヤーで明示的な混雑通知（ECN）スキームを使用します。L4Sは「スケーラブルな」混雑制御を使用します。これは、ネットワークからはるかに頻繁な制御信号を誘導し、非常に細かい調整で応答し、非常に低い（通常は平均してサブミリ秒）、一貫して低いキューイング遅延が可能になります。リンクの使用率を損なうことなくL4Sトラフィックの場合。したがって、容量を求める（TCPのような）トラフィックでさえ、交通量が多い場合でも、帯域幅が高いと同時に遅延が非常に低くなる可能性があります。
The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.
このドキュメントで定義されているL4S識別子は、L4を「クラシック」（TCP-Renoに優しい）トラフィックと区別しています。次に、ネットワークボトルネックを徐々に変更して、依然として古典的な動作に従う既存のトラフィックを区別し、分離することができ、L4Sトラフィックの低いキューイングの遅延と低い損失の低下を妨げることができます。この実験仕様は、L4Sが輸送し、ネットワーク要素が従う必要があるというルールを定義します。L4Sは、互いのパフォーマンスも古典的なトラフィックのパフォーマンスにも害を及ぼさないという意図があります。また、実験中に調査されるべき開かれた質問を提案しています。新しいアクティブキュー管理（AQM）マーキングアルゴリズムと新しいトランスポート（TCP様またはリアルタイム）の例は、個別に指定されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9331.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9331で取得できます。
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. Latency, Loss, and Scaling Problems
1.2. Terminology
1.3. Scope
2. L4S Packet Identification: Document Roadmap
3. Choice of L4S Packet Identifier: Requirements
4. Transport-Layer Behaviour (the 'Prague L4S Requirements')
4.1. Codepoint Setting
4.2. Prerequisite Transport Feedback
4.3. Prerequisite Congestion Response
4.3.1. Guidance on Congestion Response in the RFC Series
4.4. Filtering or Smoothing of ECN Feedback
5. Network Node Behaviour
5.1. Classification and Re-Marking Behaviour
5.2. The Strength of L4S CE Marking Relative to Drop
5.3. Exception for L4S Packet Identification by Network Nodes
with Transport-Layer Awareness
5.4. Interaction of the L4S Identifier with Other Identifiers
5.4.1. DualQ Examples of Other Identifiers Complementing L4S
Identifiers
5.4.1.1. Inclusion of Additional Traffic with L4S
5.4.1.2. Exclusion of Traffic from L4S Treatment
5.4.1.3. Generalized Combination of L4S and Other
Identifiers
5.4.2. Per-flow Queuing Examples of Other Identifiers
Complementing L4S Identifiers
5.5. Limiting Packet Bursts from Links
5.5.1. Limiting Packet Bursts from Links Fed by an L4S AQM
5.5.2. Limiting Packet Bursts from Links Upstream of an L4S
AQM
6. Behaviour of Tunnels and Encapsulations
6.1. No Change to ECN Tunnels and Encapsulations in General
6.2. VPN Behaviour to Avoid Limitations of Anti-Replay
7. L4S Experiments
7.1. Open Questions
7.2. Open Issues
7.3. Future Potential
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Rationale for the 'Prague L4S Requirements'
A.1. Rationale for the Requirements for Scalable Transport
Protocols
A.1.1. Use of L4S Packet Identifier
A.1.2. Accurate ECN Feedback
A.1.3. Capable of Replacement by Classic Congestion Control
A.1.4. Fall Back to Classic Congestion Control on Packet Loss
A.1.5. Coexistence with Classic Congestion Control at Classic
ECN Bottlenecks
A.1.6. Reduce RTT Dependence
A.1.7. Scaling Down to Fractional Congestion Windows
A.1.8. Measuring Reordering Tolerance in Time Units
A.2. Scalable Transport Protocol Optimizations
A.2.1. Setting ECT in Control Packets and Retransmissions
A.2.2. Faster than Additive Increase
A.2.3. Faster Convergence at Flow Start
Appendix B. Compromises in the Choice of L4S Identifier
Appendix C. Potential Competing Uses for the ECT(1) Codepoint
C.1. Integrity of Congestion Feedback
C.2. Notification of Less Severe Congestion than CE
Acknowledgements
Authors' Addresses
This Experimental specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer with the same set of codepoint transitions as the original (or 'Classic') ECN [RFC3168]. [RFC3168] requires an ECN mark to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike Classic ECN marking, i) the network applies L4S marking more immediately and more frequently than drop and ii) the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a comparable non-L4S flow under the same conditions. Nonetheless, the much more frequent ECN control signals and the finer responses to these signals result in very low queuing delay without compromising link utilization, and this low delay can be maintained during high load. For instance, queuing delay under heavy and highly varying load with the example DCTCP/DualQ solution described below on a DSL or Ethernet link is sub-millisecond on average and roughly 1 to 2 milliseconds at the 99th percentile without losing link utilization [L4Seval22] [DualPI2Linux]. Note that the queuing delay while waiting to acquire a shared medium such as wireless has to be added to the above. It is a different issue that needs to be addressed, but separately (see Section 6.3 of the L4S architecture [RFC9330]).
この実験仕様は、低レイテンシ、低損失、スケーラブルスループット（L4S）と呼ばれる新しいネットワークサービスに使用されるプロトコルを定義します。L4Sは、元の（または「クラシック」）ECN [RFC3168]と同じ一連のコードポイント遷移を備えたIPレイヤーで明示的な混雑通知（ECN）スキームを使用します。[RFC3168]は、ネットワークに適用された場合と輸送によって応答した場合の両方で、ECNマークをドロップに相当する必要があります。古典的なECNマーキングとは異なり、i）ネットワークは、ドロップやii）各マークへの輸送応答がドロップと比較して縮小され、滑らかにされるよりも頻繁にL4Sマーキングを適用します。2つの変化は、L4Sフローのスループットが同じ条件下で同等の非L4Sフローとほぼ同じになるように、相互に相殺されます。それにもかかわらず、はるかに頻繁なECN制御信号とこれらの信号に対するより細かい応答により、リンクの使用率を損なうことなく非常に低いキューイング遅延が発生し、この低遅延は高い負荷中に維持できます。たとえば、DSLまたはイーサネットリンクで以下で説明するDCTCP/DUALQソリューションの例を使用して、重度で非常に変化する負荷の下でのキューイングの遅延は、平均してサブミリ秒であり、リンクの使用率を失うことなく99パーセンタイルで約1〜2ミリ秒です[L4Seval22] [dualpi2linux]。ワイヤレスなどの共有メディアを取得するのを待っているときのキューイング遅延は、上記に追加する必要があることに注意してください。対処する必要があるのは別の問題ですが、別々には別の問題です（L4Sアーキテクチャ[RFC9330]のセクション6.3を参照）。
L4S relies on 'Scalable' congestion controls for these delay properties and for preserving low delay as flow rate scales, hence the name. The congestion control used in Data Center TCP (DCTCP) is an example of a Scalable congestion control, but DCTCP is applicable solely to controlled environments like data centres [RFC8257], because it is too aggressive to coexist with existing TCP-Reno-friendly traffic. Dual-Queue Coupled AQM, which is defined in a complementary Experimental specification [RFC9332], is an AQM framework that enables Scalable congestion controls derived from DCTCP to coexist with existing traffic, each getting roughly the same flow rate when they compete under similar conditions. Note that a Scalable congestion control is still not safe to deploy on the Internet unless it satisfies the requirements listed in Section 4.
L4Sは、これらの遅延プロパティの「スケーラブル」輻輳制御と、流量スケールとして低い遅延を維持するため、したがって名前に依存しています。データセンターTCP（DCTCP）で使用される混雑制御は、スケーラブルな混雑制御の例ですが、DCTCPは既存のTCP-レンに優しいトラフィックと共存するには攻撃的すぎるため、データセンター[RFC8257]などの制御された環境のみに適用できます。。補完的な実験仕様[RFC9332]で定義されているデュアルキュー結合AQMは、既存のトラフィックと共存するためにDCTCPから派生したスケーラブルな輻輳制御を可能にするAQMフレームワークであり、それぞれが同様の条件下で競合するとほぼ同じ流量を得ることができます。スケーラブルな混雑制御は、セクション4にリストされている要件を満たしていない限り、インターネット上に展開することは安全ではないことに注意してください。
L4S is not only for elastic (TCP-like) traffic -- there are Scalable congestion controls for real-time media, such as the L4S variant [SCReAM-L4S] of the SCReAM [RFC8298] RTP Media Congestion Avoidance Techniques (RMCAT). The factor that distinguishes L4S from Classic traffic is its behaviour in response to congestion. The transport wire protocol, e.g., TCP, QUIC, the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), or RTP/RTCP, is orthogonal (and therefore not suitable for distinguishing L4S from Classic packets).
L4Sは、弾性（TCPのような）トラフィックだけではありません。スクリーム[RFC8298] RTPメディア混雑回避技術（RMCAT）のL4Sバリアント[Scream-L4S]など、リアルタイムメディア用のスケーラブルな混雑制御があります。L4を古典的なトラフィックと区別する要因は、混雑に応じた動作です。TCP、QUIC、Stream Control Transmission Protocol（SCTP）、Datagram混雑制御プロトコル（DCCP）、またはRTP/RTCPなど、Transport Wireプロトコルは、直交している（したがって、L4Sを古典的なパケットから区別するのに適していません）。
The L4S identifier defined in this document is the key piece that distinguishes L4S from 'Classic' (e.g., Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing Classic traffic from L4S traffic, to prevent the former from degrading the very low queuing delay and loss of the new Scalable transports, without harming Classic performance at these bottlenecks. Although both sender and network deployment are required before any benefit, initial implementations of the separate parts of the system have been motivated by the potential performance benefits.
このドキュメントで定義されているL4S識別子は、L4を「クラシック」（例えば、リノにやさしい）トラフィックと区別する重要な部分です。次に、ネットワークボトルネックを徐々に変更して、既存の古典的なトラフィックをL4Sトラフィックと区別および分離し、前者が非常に低いキューイング遅延と新しいスケーラブルトランスポートの損失を低下させないようにします。送信者とネットワークの展開の両方が利益の前に必要ですが、システムの別々の部分の初期実装は、潜在的なパフォーマンスの利点によって動機付けられています。
Latency is becoming the critical performance factor for many (perhaps most) Internet applications, e.g., interactive web, web services, voice, conversational video, interactive video, interactive remote presence, instant messaging, online gaming, remote desktop, cloud-based applications & services, and remote control of machinery and industrial processes. In many parts of the world, further increases in access network bitrate offer diminishing returns [Dukkipati06], whereas latency is still a multi-faceted problem. As a result, much has been done to reduce propagation time by placing caches or servers closer to users. However, queuing remains a major, albeit intermittent, component of latency.
レイテンシは、インタラクティブなWeb、Webサービス、音声、会話ビデオ、インタラクティブビデオ、インタラクティブなリモート存在、インスタントメッセージング、オンラインゲーム、リモートデスクトップ、クラウドベースのアプリケーション＆サービス、および機械および産業プロセスのリモート制御。世界の多くの地域では、アクセスネットワークビットレートがさらに増加すると、リターンが減少します[Dukkipati06]が、レイテンシは依然として多面的な問題です。その結果、ユーザーの近くにキャッシュまたはサーバーを配置することにより、伝播時間を短縮するために多くのことが行われました。ただし、キューイングは、断続的ではあるが、レイテンシのコンポーネントである大規模なものであり続けています。
The Diffserv architecture provides Expedited Forwarding (EF) [RFC3246] so that low-latency traffic can jump the queue of other traffic. If growth in latency-sensitive applications continues, periods with solely latency-sensitive traffic will become increasingly common on links where traffic aggregation is low. During these periods, if all the traffic were marked for the same treatment, Diffserv would make no difference. The links with low aggregation also tend to become the path bottleneck under load, for instance, the access links dedicated to individual sites (homes, small enterprises, or mobile devices). So, instead of differentiation, it becomes imperative to remove the underlying causes of any unnecessary delay.
DiffServアーキテクチャは、迅速な転送（EF）[RFC3246]を提供し、低遅延トラフィックが他のトラフィックのキューにジャンプできるようにします。遅延に敏感なアプリケーションの成長が続くと、トラフィックの集約が低いリンクでは、潜伏感度に敏感なトラフィックのみの期間がますます一般的になります。これらの期間中、すべてのトラフィックが同じ治療でマークされた場合、Diffservは違いを生みません。凝集が低いリンクは、個々のサイト（家、中小企業、またはモバイルデバイス）専用のアクセスリンクなど、負荷の下でパスボトルネックになる傾向があります。したがって、差別化の代わりに、不必要な遅延の根本的な原因を除去することが不可欠になります。
The Bufferbloat project has shown that excessively large buffering ('bufferbloat') has been introducing significantly more delay than the underlying propagation time [Bufferbloat]. These delays appear only intermittently -- only when a capacity-seeking (e.g., TCP) flow is long enough for the queue to fill the buffer, causing every packet in other flows sharing the buffer to have to work its way through the queue.
BufferBloatプロジェクトは、過度に大きなバッファリング（「Bufferbloat」）が、基礎となる伝播時間[BufferBloat]よりも大幅に多くの遅延を導入していることを示しています。これらの遅延は断続的にのみ表示されます - 容量を求める（たとえばTCP）フローがキューがバッファーを埋めるのに十分な長さである場合にのみ、バッファーを共有する他のフローのすべてのパケットがキューを通過する必要があります。
AQM was originally developed to solve this problem (and others). Unlike Diffserv, which gives low latency to some traffic at the expense of others, AQM controls latency for _all_ traffic in a class. In general, AQM methods introduce an increasing level of discard from the buffer, the longer the queue persists above a shallow threshold. This gives sufficient signals to capacity-seeking (a.k.a. greedy) flows to keep the buffer empty for its intended purpose: absorbing bursts. However, Random Early Detection (RED) and other algorithms from the 1990s were sensitive to their configuration and hard to set correctly [RFC7567]. So this form of AQM was not widely deployed.
AQMはもともと、この問題（およびその他）を解決するために開発されました。他の人を犠牲にして一部のトラフィックに低下を与えるDiffservとは異なり、AQMはクラス内の_all_トラフィックの遅延を制御します。一般に、AQMメソッドはバッファからの廃棄レベルの増加を導入しますが、キューが浅いしきい値を超えて持続します。これにより、容量を求める（別名貪欲な）流れに十分な信号が与えられ、意図した目的のためにバッファーを空にしておくと、バーストを吸収します。ただし、1990年代のランダムな早期検出（赤）およびその他のアルゴリズムは、その構成に敏感であり、正しく設定するのが難しい[RFC7567]。したがって、この形式のAQMは広く展開されていませんでした。
More recent state-of-the-art AQM methods, such as Flow Queue CoDel [RFC8290], Proportional Integral controller Enhanced (PIE) [RFC8033], or Adaptive RED [ARED01], are easier to configure, because they define the queuing threshold in time not bytes, so configuration is invariant whatever the link rate. However, the sawtoothing window of a Classic congestion control creates a dilemma for the operator: either i) configure a shallow AQM operating point so the tips of the sawteeth cause minimal queue delay, but then the troughs underutilize the link, or ii) configure the operating point deeper into the buffer so the troughs utilize the link better, but then the tips cause more delay variation. Even with a perfectly tuned AQM, the additional queuing delay at the tips of the sawteeth will be of the same order as the underlying base round-trip time (RTT), thereby roughly doubling the total RTT.
フローキューコード[RFC8290]、比例積分コントローラーの強化（PIE）[RFC8033]、または適応レッド[ARED01]など、最近の最新のAQMメソッドは、キューイングのしきい値を定義するため、構成が容易です。バイトではないため、リンクレートが何であれ、構成は不変です。ただし、古典的な混雑制御の鋸窓は、オペレーターのジレンマを作成します。i）浅いAQM動作点を構成するため、鋸の先端が最小限のキュー遅延を引き起こしますが、トラフはリンクを十分に活用するか、ii）動作点はバッファーの奥深くにあるため、トラフはリンクをより適切に利用しますが、その後、ヒントはより多くの遅延変動を引き起こします。完全に調整されたAQMであっても、Sawteethのヒントでの追加のキューイング遅延は、基礎となるベースラウンドトリップ時間（RTT）と同じ順序であり、それにより合計RTTをほぼ2倍にします。
If a sender's own behaviour is introducing queuing delay variation, no AQM in the network can 'un-vary' the delay without significantly compromising link utilization. Even flow queuing (e.g., [RFC8290]), which isolates one flow from another, cannot isolate a flow from the delay variations it inflicts on itself. Therefore, those applications that need to seek out high bandwidth but also need low latency will have to migrate to Scalable congestion control, which uses much smaller sawtooth variations.
送信者自身の動作がキューイングの遅延変動を導入している場合、ネットワーク内のAQMは、リンクの使用率を大幅に損なうことなく遅延を「変化させない」ことはできません。ある流れを別のフローから分離するフローキューイング（[RFC8290]など）でさえ、それ自体に与える遅延変動から流れを隔離することはできません。したがって、高い帯域幅を探す必要があるが、低遅延を必要とするアプリケーションは、はるかに小さな鋸歯状のバリエーションを使用するスケーラブルなうっ血制御に移行する必要があります。
Altering host behaviour is not enough on its own though. Even if hosts adopt low-latency Scalable congestion controls, they need to be isolated from the large queue variations induced by existing Classic congestion controls. L4S AQMs provide that latency isolation in the network, and the L4S identifier enables the AQMs to distinguish the two types of packets that need to be isolated: L4S and Classic. L4S isolation can be achieved with a queue per flow (e.g., [RFC8290]), but a DualQ [RFC9332] is sufficient and actually gives better tail latency [DCttH19]. Both approaches are addressed in this document.
ただし、ホストの動作を変更するだけでは十分ではありません。ホストが低遅延のスケーラブルな混雑コントロールを採用していても、既存の古典的な混雑コントロールによって誘導される大きなキューのバリエーションから分離する必要があります。L4S AQMSは、ネットワーク内のレイテンシ分離を提供し、L4S識別子により、AQMSは分離する必要がある2種類のパケットを区別できます：L4Sとクラシック。L4S分離は、フローあたりのキュー（例：[RFC8290]）で行うことができますが、DualQ [RFC9332]で十分であり、実際にはテールレイテンシ[DCTTH19]をより良いものにします。このドキュメントでは、両方のアプローチについて説明します。
The DualQ solution was developed to make very low latency available without requiring per-flow queues at every bottleneck. This was useful because per-flow queuing (FQ) has well-known downsides -- not least the need to inspect transport-layer headers in the network, which makes it incompatible with privacy approaches such as IPsec Virtual Private Network (VPN) tunnels and incompatible with link-layer queue management, where transport-layer headers can be hidden, e.g., 5G.
DUALQソリューションは、すべてのボトルネックでフローごとのキューを必要とせずに非常に低いレイテンシを利用できるように開発されました。これは有用でした（FQ）にはよく知られている欠点があるため、特にネットワーク内の輸送レイヤーヘッダーを検査する必要性があるため、IPSEC仮想プライベートネットワーク（VPN）トンネルなどのプライバシーアプローチと互換性がありません。輸送層ヘッダーを隠すことができるリンク層キュー管理と互換性がありません。たとえば、5g。
Latency is not the only concern addressed by L4S. It was known when TCP congestion avoidance was first developed that it would not scale to high bandwidth-delay products (see footnote 6 of Jacobson and Karels [TCP-CA]). Given that Reno congestion control is already beyond its scaling range at regular broadband bitrates over WAN distances [RFC3649], 'less unscalable' CUBIC [RFC8312] and Compound [CTCP] variants of TCP have been successfully deployed. However, these are now approaching their scaling limits. Unfortunately, fully Scalable congestion controls such as DCTCP [RFC8257] outcompete Classic ECN congestion controls sharing the same queue, which is why they have been confined to private data centres or research testbeds.
L4が扱う懸念は唯一の懸念ではありません。TCPの混雑回避が最初に開発されたときに知られていたのは、高帯域幅遅延製品に拡大しないことがわかった（Jacobson and Karels [TCP-CA]の脚注6を参照）。Renoの混雑制御は、WAN距離[RFC3649]、「控えめでない」立方体[RFC8312]、およびTCPの化合物[CTCP]バリアントが正常に展開されている、通常のブロードバンドビットレートでのスケーリング範囲を超えていることを考えると、ただし、これらは現在、スケーリング制限に近づいています。残念ながら、DCTCP [RFC8257]などの完全にスケーラブルな輻輳制御は、同じキューを共有する古典的なECN混雑コントロールを転換します。そのため、プライベートデータセンターや研究テストベッドに限定されています。
It turns out that these Scalable congestion control algorithms that solve the latency problem can also solve the scalability problem of Classic congestion controls. The finer sawteeth in the congestion window (cwnd) have low amplitude, so they cause very little queuing delay variation, and the average time to recover from one congestion signal to the next (the average duration of each sawtooth) remains invariant, which maintains constant tight control as flow rate scales. A background paper [L4Seval22] gives the full explanation of why the design solves both the latency and the scaling problems, both in plain English and in more precise mathematical form. The explanation is summarized without the mathematics in Section 4 of the L4S architecture [RFC9330].
レイテンシの問題を解決するこれらのスケーラブルな輻輳制御アルゴリズムは、古典的なうっ血コントロールのスケーラビリティの問題も解決できることがわかります。混雑ウィンドウ（CWND）のより細かい鋸は振幅が低いため、鎮静遅延の変動がほとんどありません。1つの混雑信号から次の輻輳信号（各鋸歯の平均持続時間）に回復する平均時間は不変のままです。流量スケールとしての厳しい制御。バックグラウンドペーパー[L4Seval22]は、デザインがレイテンシとスケーリングの問題の両方を、平易な英語とより正確な数学的形式の両方で解決する理由を完全に説明しています。説明は、L4Sアーキテクチャ[RFC9330]のセクション4に数学なしで要約されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Classic Congestion Control: A congestion control behaviour that can coexist with standard Reno [RFC5681] without causing significantly negative impact on its flow rate [RFC5033]. With Classic congestion controls, such as Reno or CUBIC, because flow rate has scaled since TCP congestion control was first designed in 1988, it now takes hundreds of round trips (and growing) to recover after a congestion signal (whether a loss or an ECN mark) as shown in the examples in Section 5.1 of the L4S architecture [RFC9330] and in [RFC3649]. Therefore, control of queuing and utilization becomes very slack, and the slightest disturbances (e.g., from new flows starting) prevent a high rate from being attained.
古典的な混雑制御：流量に大きな悪影響を与えることなく、標準のリノ[RFC5681]と共存できる混雑制御挙動[RFC5033]。RenoやCubicなどの古典的な混雑コントロールにより、TCP混雑制御が1988年に設計されてから流量が拡大しているため、渋滞信号（損失またはECNのいずれか）の後に回復するには数百の往復（および成長）が必要です。マーク）L4Sアーキテクチャ[RFC9330]および[RFC3649]のセクション5.1の例に示されているように。したがって、キューイングと使用率の制御は非常に緩くなり、わずかな乱れ（例えば、新しいフローからの開始から）が達成されないようにします。
Scalable Congestion Control: A congestion control where the average time from one congestion signal to the next (the recovery time) remains invariant as flow rate scales, all other factors being equal. This maintains the same degree of control over queuing and utilization whatever the flow rate, as well as ensuring that high throughput is robust to disturbances. For instance, DCTCP averages 2 congestion signals per round trip, whatever the flow rate, as do other recently developed Scalable congestion controls, e.g., Relentless TCP [RELENTLESS], Prague for TCP and QUIC [PRAGUE-CC] [PragueLinux], the L4S ECN part of Bottleneck Bandwidth and Round-trip propagation time (BBRv2) [BBRv2] [BBR-CC], and the L4S variant of SCReAM for real-time media [SCReAM-L4S] [RFC8298]. See Section 4.3 for more explanation.
スケーラブルな混雑制御：1つの輻輳信号から次の輻輳信号までの平均時間（回復時間）までの平均時間が、流量スケールとして不変のままで、他のすべての要因が等しい場合。これにより、流量が何であれ、キューイングと利用に対する同じ程度の制御が維持され、高スループットが乱れに堅牢であることを保証します。たとえば、DCTCPは、最近開発された他のスケーラブルな混雑コントロール、たとえば容赦ないTCP [容赦ない]、TCPおよびQUIC [Prague-CC] [Praguelinux]、L4Sのように、流量が何であれ、往復あたり2つの混雑信号を平均します。ECN Bottleneck帯域幅と往復伝播時間（BBRV2）[BBR-CC]、およびリアルタイムメディア用のScreamのL4Sバリアント[Scream-L4S] [RFC8298]。詳細については、セクション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.
サイト：ネットワークボトルネックが通常サイトへのアクセスリンクであるホーム、モバイルデバイス、中小企業、またはキャンパス。すべてのネットワーク配置がこのモデルに適合するわけではありませんが、それは有用で広く適用可能な一般化です。
The new L4S identifier defined in this specification is applicable for IPv4 and IPv6 packets (as is Classic ECN [RFC3168]). It is applicable for the unicast, multicast, and anycast forwarding modes.
この仕様で定義されている新しいL4S識別子は、IPv4およびIPv6パケットに適用できます（古典的なECN [RFC3168]）。ユニキャスト、マルチキャスト、およびAnycastの転送モードに適用されます。
The L4S identifier is an orthogonal packet classification to the Differentiated Services Code Point (DSCP) [RFC2474]. Section 5.4 explains what this means in practice.
L4S識別子は、差別化されたサービスコードポイント（DSCP）[RFC2474]への直交パケット分類です。セクション5.4では、これが実際に何を意味するかを説明しています。
This document is Experimental, so it does not update any Standards Track RFCs. Therefore, it depends on [RFC8311], which is a Standards Track specification that:
このドキュメントは実験的なものであるため、RFCSの標準トラックを更新しません。したがって、それは[RFC8311]に依存します。これは、次の標準トラックの仕様です。
* updates the ECN Proposed Standard [RFC3168] to allow Experimental RFCs to relax the requirement that an ECN mark must be equivalent to a drop (when the network applies markings and/or when the sender responds to them). For instance, in the Alternative Backoff with ECN (ABE) experiment [RFC8511], this relaxation permits a sender to respond less to ECN marks than to drops;
* ECN提案された標準[RFC3168]を更新して、実験的なRFCがECNマークがドロップに相当する必要があるという要件を緩和できるようにします（ネットワークがマークを適用した場合、および/または送信者が応答するとき）。たとえば、ECN（ABE）実験[RFC8511]を使用した代替バックオフでは、このリラクゼーションにより、送信者はドロップよりもECNマークへの応答が少なくなります。
* changes the status of the Experimental ECN nonce spec [RFC3540] to Historic; and
* 実験的ECN Nonce Spec [RFC3540]のステータスを歴史的に変更します。と
* makes consequent updates to the following additional Proposed Standard RFCs to reflect the above two bullets:
* 上記の2つの弾丸を反映するために、次の追加の追加の標準RFCを結果として更新します。
- ECN for RTP [RFC6679] and
- RTP [RFC6679]のECN
- the congestion control specifications of various DCCP Congestion Control Identifier (CCID) profiles [RFC4341] [RFC4342] [RFC5622].
- さまざまなDCCP混雑制御識別子（CCID）プロファイルの輻輳制御仕様[RFC4341] [RFC4342] [RFC5622]。
This document is about identifiers that are used for interoperation between hosts and networks. So the audience is broad, covering developers of host transports and network AQMs, as well as covering how operators might wish to combine various identifiers, which would require flexibility from equipment developers.
このドキュメントは、ホストとネットワーク間の相互操作に使用される識別子に関するものです。そのため、視聴者は幅広く、ホストトランスポートとネットワークAQMの開発者をカバーしており、オペレーターがさまざまな識別子を組み合わせたい方法をカバーしているため、機器開発者からの柔軟性が必要です。
The L4S ECN marking treatment is an experimental alternative to the Classic ECN treatment in [RFC3168], which has been updated by [RFC8311] to allow experiments such as the one defined in the present specification. [RFC4774] discusses some of the issues and evaluation criteria when defining alternative ECN semantics, which are further discussed in Section 4.3.1.
L4S ECNマーキング治療は、[RFC3168]の古典的なECN処理の実験的代替手段であり、[RFC8311]によって更新され、現在の仕様で定義されたものなどの実験を可能にします。[RFC4774]は、セクション4.3.1でさらに説明する代替ECNセマンティクスを定義する際に、問題と評価基準のいくつかについて説明します。
The L4S architecture [RFC9330] describes the three main components of L4S: the sending host behaviour, the marking behaviour in the network, and the L4S ECN protocol that identifies L4S packets as they flow between the two.
L4Sアーキテクチャ[RFC9330]は、L4Sの3つの主要なコンポーネント、送信ホスト動作、ネットワーク内のマーキング動作、およびL4Sパケットが2つの間に流れるときに識別するL4S ECNプロトコルについて説明しています。
Section 3 of this document records the requirements that informed the choice of L4S identifier. Then, subsequent sections specify the L4S ECN protocol, which i) identifies packets that have been sent from hosts that are expected to comply with a broad type of sending behaviour and ii) identifies the marking treatment that network nodes are expected to apply to L4S packets.
このドキュメントのセクション3は、L4S識別子の選択を通知する要件を記録します。次に、後続のセクションはL4S ECNプロトコルを指定します。これはi）幅広い種類の送信行動に準拠すると予想されるホストから送信されたパケットを識別し、ii）ネットワークノードがL4Sパケットに適用されると予想されるマーキング処理を特定します。
For a packet to receive L4S treatment as it is forwarded, the sender sets the ECN field in the IP header to the ECT(1) codepoint. See Section 4 for full transport-layer behaviour requirements, including feedback and congestion response.
L4S処理を転送するパケットを受信するために、送信者はIPヘッダー内のECNフィールドをECT（1）CodePointに設定します。フィードバックや輻輳応答を含む、完全な輸送層の動作要件については、セクション4を参照してください。
A network node that implements the L4S service always classifies arriving ECT(1) packets for L4S treatment and by default classifies CE packets for L4S treatment unless the heuristics described in Section 5.3 are employed. See Section 5 for full network element behaviour requirements, including classification, ECN marking, and interaction of the L4S identifier with other identifiers and per-hop behaviours.
L4Sサービスを実装するネットワークノードは、常にL4S処理に到着するECT（1）パケットを分類し、デフォルトではセクション5.3で説明されているヒューリスティックが使用されない限り、L4S治療のCEパケットを分類します。分類、ECNマーキング、L4S識別子と他の識別子およびホップごとの動作を含む完全なネットワーク要素の動作要件については、セクション5を参照してください。
L4S ECN works with ECN tunnelling and encapsulation behaviour as is, except there is one known case where careful attention to configuration is required, which is detailed in Section 6.
L4S ECNは、ECNトンネルとカプセル化の動作で動作しますが、セクション6で詳述されている構成に注意する必要がある既知のケースがあります。
This specification of L4S ECN currently has Experimental status. So Section 7 collects the general questions and issues that remain open for investigation during L4S experimentation. Open issues or questions specific to particular components are called out in the specifications of each component part, such as the DualQ [RFC9332].
L4S ECNのこの仕様には現在、実験的状態があります。そのため、セクション7では、L4S実験中に調査のために開かれたままである一般的な質問と問題を収集します。特定のコンポーネントに固有のオープンな問題または質問は、DUALQ [RFC9332]など、各コンポーネント部分の仕様で呼び出されます。
The IANA assignment of the L4S identifier is specified in Section 8. And Section 9 covers security considerations specific to the L4S identifier. System security aspects, such as policing and privacy, are covered in the L4S architecture [RFC9330].
L4S識別子のIANA割り当ては、セクション8で指定されています。セクション9では、L4S識別子に固有のセキュリティ上の考慮事項について説明します。ポリシングやプライバシーなどのシステムセキュリティの側面は、L4Sアーキテクチャ[RFC9330]でカバーされています。
This subsection briefly records the process that led to the chosen L4S identifier.
このサブセクションは、選択したL4S識別子につながったプロセスを簡単に記録します。
The identifier for packets using the L4S service needs to meet the following requirements:
L4Sサービスを使用したパケットの識別子は、次の要件を満たす必要があります。
* it SHOULD survive end to end between source and destination endpoints: across the boundary between host and network, between interconnected networks, and through middleboxes;
* ソースエンドポイントと宛先エンドポイントの間の端から端まで生き残る必要があります。ホストとネットワークの境界を越えて、相互接続されたネットワーク間、およびミドルボックスを介して。
* it SHOULD be visible at the IP layer;
* IPレイヤーに表示される必要があります。
* it SHOULD be common to IPv4 and IPv6 and be transport-agnostic;
* IPv4とIPv6に共通しており、輸送に依存しないはずです。
* it SHOULD be incrementally deployable;
* 徐々に展開できるはずです。
* it SHOULD enable an AQM to classify packets encapsulated by outer IP or lower-layer headers;
* AQMが外側のIPまたは低層ヘッダーによってカプセル化されたパケットを分類できるようにする必要があります。
* it SHOULD consume minimal extra codepoints; and
* 最小限の追加コードポイントを消費する必要があります。と
* it SHOULD be consistent on all the packets of a transport-layer flow, so that some packets of a flow are not served by a different queue to others.
* 輸送層の流れのすべてのパケットと一貫性があるはずです。そうすれば、フローの一部のパケットが別のキューによって他のキューによって提供されないようにする必要があります。
Whether the identifier would be recoverable if the experiment failed is a factor that could be taken into account. However, this has not been made a requirement, because that would favour schemes that would be easier to fail rather than more likely to succeed.
実験が失敗した場合、識別子が回復可能かどうかは、考慮される可能性のある要因です。ただし、これは要件にされていません。これは、成功する可能性が高くなるのではなく、失敗しやすいスキームを支持するからです。
It is recognized that any choice of identifier is unlikely to satisfy all these requirements, particularly given the limited space left in the IP header. Therefore, a compromise will always be necessary, which is why all the above requirements are expressed with the word "SHOULD" not "MUST".
特にIPヘッダーに残っているスペースが限られていることを考えると、識別子の選択がこれらすべての要件を満たす可能性は低いことが認識されています。したがって、妥協は常に必要になります。そのため、上記の要件はすべて、「必要はない」という言葉で表現されます。
After extensive assessment of alternative schemes, "ECT(1) and CE codepoints" was chosen as the best compromise. Therefore, this scheme is defined in detail in the following sections, while Appendix B records its pros and cons against the above requirements.
代替スキームの広範な評価の後、「ECT（1）およびCE CodePoints」が最良の妥協として選択されました。したがって、このスキームは次のセクションで詳細に定義されていますが、付録Bは上記の要件に対して長所と短所を記録します。
This section defines L4S behaviour at the transport layer, also known as the 'Prague L4S Requirements' (see Appendix A for the origin of the name).
このセクションでは、「プラハL4S要件」とも呼ばれる輸送層でのL4Sの動作を定義します（名前の原点については付録Aを参照）。
A sender that wishes a packet to receive L4S treatment as it is forwarded MUST set the ECN field in the IP header (v4 or v6) to the ECT(1) codepoint.
転送されたL4Sトリートメントの受信を希望する送信者は、IPヘッダー（V4またはV6）のECNフィールドをECT（1）CodePointに設定する必要があります。
For a transport protocol to provide Scalable congestion control (Section 4.3), it MUST provide feedback of the extent of CE marking on the forward path. When ECN was added to TCP [RFC3168], the feedback method reported no more than one CE mark per round trip. Some transport protocols derived from TCP mimic this behaviour while others report the accurate extent of ECN marking. This means that some transport protocols will need to be updated as a prerequisite for Scalable congestion control. The position for a few well-known transport protocols is given below.
輸送プロトコルがスケーラブルな輻輳制御を提供するには（セクション4.3）、前方パスでのCEマーキングの範囲のフィードバックを提供する必要があります。ECNがTCP [RFC3168]に追加されたとき、フィードバック方法は、往復あたり1回のCEマーク以下を報告しました。TCPから派生した輸送プロトコルの中には、この動作を模倣した輸送プロトコルの中には、ECNマーキングの正確な範囲を報告する輸送プロトコルもあります。これは、いくつかの輸送プロトコルをスケーラブルな輻輳制御の前提条件として更新する必要があることを意味します。いくつかのよく知られている輸送プロトコルの位置を以下に示します。
TCP: Support for the accurate ECN feedback requirements [RFC7560] (such as that provided by AccECN [ACCECN]) by both ends is a prerequisite for Scalable congestion control in TCP. Therefore, the presence of ECT(1) in the IP headers even in one direction of a TCP connection will imply that both ends support accurate ECN feedback. However, the converse does not apply. So even if both ends support AccECN, either of the two ends can choose not to use a Scalable congestion control, whatever the other end's choice is.
TCP：正確なECNフィードバック要件[RFC7560]（accecn [accecn]によって提供されるものなど）のサポートは、TCPのスケーラブルな輻輳制御の前提条件です。したがって、TCP接続の一方向であっても、IPヘッダーにECT（1）が存在することは、両端が正確なECNフィードバックをサポートすることを意味します。ただし、コンバースは適用されません。したがって、両端がaccecnをサポートしていても、両端のいずれかが、反対側の選択が何であれ、スケーラブルな輻輳制御を使用しないことを選択できます。
SCTP: A suitable ECN feedback mechanism for SCTP could add a chunk to report the number of received CE marks (as described in a long-expired document [SCTP-ECN] or as sketched out in Appendix A of the now-obsolete second Standards Track specification of SCTP [RFC4960]).
SCTP：SCTPの適切なECNフィードバックメカニズムは、受信したCEマークの数を報告するためにチャンクを追加することができます（長期にわたるドキュメント[SCTP-ECN]で説明されているように、または現在オブソレテの2番目の標準トラックの付録AでスケッチしたようにSCTPの仕様[RFC4960]）。
RTP over UDP: A prerequisite for Scalable congestion control is for both (all) ends of one media-level hop to signal ECN support [RFC6679] and use the new generic RTCP feedback format of [RFC8888]. The presence of ECT(1) implies that both (all) ends of that media-level hop support ECN. However, the converse does not apply. So each end of a media-level hop can independently choose not to use a Scalable congestion control, even if both ends support ECN.
UDPを介したRTP：スケーラブルな輻輳制御の前提条件は、1つのメディアレベルのホップの両方の端部がECNサポート[RFC6679]を信号を送信し、[RFC8888]の新しいジェネリックRTCPフィードバック形式を使用することです。ECT（1）の存在は、そのメディアレベルのホップの両方の（すべて）端がECNをサポートすることを意味します。ただし、コンバースは適用されません。したがって、メディアレベルのホップの各端は、たとえ両端がECNをサポートしていても、スケーラブルな輻輳制御を使用しないことを独立して選択できます。
QUIC: Support for sufficiently fine-grained ECN feedback is provided by IETF QUIC transport v1 [RFC9000].
QUIC：IETF QUIC Transport V1 [RFC9000]によって、十分に細粒のECNフィードバックのサポートが提供されます。
DCCP: The Acknowledgement (ACK) vector in DCCP [RFC4340] is already sufficient to report the extent of CE marking as needed by a Scalable congestion control.
DCCP：DCCP [RFC4340]の確認（ACK）ベクトルは、スケーラブルな混雑制御によって必要に応じてCEマーキングの範囲を報告するのに十分です。
As a condition for a host to send packets with the L4S identifier (ECT(1)), it SHOULD implement a congestion control behaviour that ensures that, in steady state, the average duration between induced ECN marks does not increase as flow rate scales up, all other factors being equal. This is termed a Scalable congestion control. This invariant duration ensures that, as flow rate scales, the average period with no feedback information about capacity does not become excessive. It also ensures that queue variations remain small, without having to sacrifice utilization.
ホストがL4S識別子（ECT（1））でパケットを送信する条件として、定常状態では、誘導ECNマーク間の平均持続時間が増加すると、流量が上昇するにつれて増加しないことを保証する混雑制御挙動を実装する必要があります。、他のすべての要因が等しい。これは、スケーラブルな混雑制御と呼ばれます。この不変の期間は、流量が拡大すると、容量に関するフィードバック情報がない平均期間が過度にならないことを保証します。また、使用率を犠牲にすることなく、キューのバリエーションが小さいままであることも保証されます。
With a congestion control that sawtooths to probe capacity, this duration is called the recovery time, because each time the sawtooth yields, on average it takes this time to recover to its previous high point. A Scalable congestion control does not have to sawtooth, but it has to coexist with Scalable congestion controls that do.
Sawtoothが容量を調べる渋滞を制御すると、この期間は回復時間と呼ばれます。なぜなら、Sawtoothが収穫するたびに、平均して以前のハイポイントに回復するのに今度は時間がかかるからです。スケーラブルな輻輳制御は、Sawtoothには必要ありませんが、スケーラブルな混雑コントロールと共存する必要があります。
For instance, for DCTCP [RFC8257], TCP Prague [PRAGUE-CC] [PragueLinux], and the L4S variant of SCReAM [SCReAM-L4S] [RFC8298], the average recovery time is always half a round trip (or half a reference round trip), whatever the flow rate.
たとえば、DCTCP [RFC8257]、TCP Prague [Prague-CC] [Praguelinux]、およびScream [Scream-L4S] [RFC8298]のL4Sバリアントの場合、平均回復時間は常に半分の丸い旅行（または半分の参照旅行です。往復）、流量が何であれ。
As with all transport behaviours, a detailed specification (probably an Experimental RFC) is expected for each congestion control, following the guidelines for specifying new congestion control algorithms in [RFC5033]. In addition, it is expected that these L4S-specific matters will be documented, specifically the timescale over which the proportionality is averaged and the control of burstiness. The recovery time requirement above is worded as a "SHOULD" rather than a "MUST" to allow reasonable flexibility for such implementations.
すべての輸送行動と同様に、[RFC5033]で新しい混雑制御アルゴリズムを指定するためのガイドラインに従って、各輻輳制御に詳細な仕様（おそらく実験RFC）が予想されます。さらに、これらのL4S固有の問題は、特に比例性が平均化されているタイムスケールと破裂の制御を文書化することが予想されます。上記の回復時間の要件は、そのような実装の合理的な柔軟性を可能にするために、「必要」ではなく「必要」として表現されています。
The condition 'all other factors being equal' allows the recovery time to be different for different round-trip times, as long as it does not increase with flow rate for any particular RTT.
「他のすべての要因が等しい」条件により、特定のRTTの流量とともに増加しない限り、回復時間は異なる往復時間で異なることができます。
Saying that the recovery time remains roughly invariant is equivalent to saying that the number of ECN CE marks per round trip remains invariant as flow rate scales, all other factors being equal. For instance, an average recovery time of half of 1 RTT is equivalent to 2 ECN marks per round trip. For those familiar with steady-state congestion response functions, it is also equivalent to say that the congestion window is inversely proportional to the proportion of bytes in packets marked with the CE codepoint (see Section 2 of [PI2]).
回復時間はほぼ不変のままであると言うことは、往復あたりの頻度のマークの数は流量スケールとして不変のままであり、他のすべての要因が等しいと言うことと同等です。たとえば、1 RTTの半分の平均回復時間は、往復あたり2つのECNマークに相当します。定常状態の輻輳応答関数に精通している人にとっては、CEDopointでマークされたパケットのバイトの割合に逆数が反比例していると言うことも同等です（[PI2]のセクション2を参照）。
In order to coexist safely with other Internet traffic, a Scalable congestion control is not allowed to tag its packets with the ECT(1) codepoint unless it complies with the following numbered requirements and recommendations:
他のインターネットトラフィックと安全に共存するために、スケーラブルな混雑制御は、次の番号の要件と推奨事項に準拠しない限り、そのパケットにECT（1）CodePointでタグ付けすることは許可されていません。
1. A Scalable congestion control MUST be capable of being replaced by a Classic congestion control (by application and/or by administrative control). If a Classic congestion control is activated, it will not tag its packets with the ECT(1) codepoint (see Appendix A.1.3 for rationale).
1. スケーラブルな輻輳制御は、古典的な混雑制御に置き換えることができなければなりません（アプリケーションおよび/または管理制御によって）。古典的な輻輳制御がアクティブになっている場合、そのパケットにECT（1）コードポイントでタグ付けされません（根拠については付録A.1.3を参照）。
2. As well as responding to ECN markings, a Scalable congestion control MUST react to packet loss in a way that will coexist safely with Classic congestion controls such as standard Reno [RFC5681], as required by [RFC5033] (see Appendix A.1.4 for rationale).
2. ECNマーキングに応答するだけでなく、スケーラブルな混雑制御は、[RFC5033]で要求されているように、標準RENO [RFC5681]などの古典的な混雑コントロールと安全に共存する方法でパケット損失に反応する必要があります（合理的なものについては付録A.1.4を参照してください）。
3. In uncontrolled environments, monitoring MUST be implemented to support detection of problems with an ECN-capable AQM at the path bottleneck that appears not to support L4S and that might be in a shared queue. Such monitoring SHOULD be applied to live traffic that is using Scalable congestion control. Alternatively, monitoring need not be applied to live traffic, if monitoring with test traffic has been arranged to cover the paths that live traffic takes through uncontrolled environments.
3. 制御されていない環境では、L4Sをサポートしておらず、共有キューにある可能性があると思われるパスボトルネックでのECN対応AQMの問題の検出をサポートするために監視を実装する必要があります。このような監視は、スケーラブルな混雑制御を使用しているライブトラフィックに適用する必要があります。あるいは、ライブトラフィックを備えた監視が制御されていない環境を通って取るパスをカバーするように整理されている場合、ライブトラフィックに監視を適用する必要はありません。
A function to detect the above problems with an ECN-capable AQM MUST also be implemented and used. The detection function SHOULD be capable of making the congestion control adapt its ECN-marking response in real time to coexist safely with Classic congestion controls such as standard Reno [RFC5681], as required by [RFC5033]. This could be complemented by more detailed offline detection of potential problems. If only offline detection is used and potential problems with such an AQM are detected on certain paths, the Scalable congestion control MUST be replaced by a Classic congestion control, at least for the problem paths.
ECN対応のAQMで上記の問題を検出する関数も実装および使用する必要があります。検出関数は、[RFC5033]で要求されるように、標準RENO [RFC5681]などの古典的な混雑コントロールと安全に共存するために、渋滞制御にECNマーク応答をリアルタイムで適応させることができる必要があります。これは、潜在的な問題のより詳細なオフライン検出によって補完される可能性があります。オフライン検出のみが使用され、そのようなAQMの潜在的な問題が特定のパスで検出される場合、少なくとも問題パスについては、スケーラブルな輻輳制御を古典的な混雑制御に置き換える必要があります。
See Section 4.3.1, Appendix A.1.5, and the L4S operational guidance [L4SOPS] for rationale and explanation.
理論的根拠と説明については、セクション4.3.1、付録A.1.5、およびL4S運用ガイダンス[L4SOPS]を参照してください。
Note that a Scalable congestion control is not expected to change to setting ECT(0) while it transiently adapts to coexist with Classic congestion controls, whereas a replacement congestion control that solely behaves in the Classic way will set ECT(0).
スケーラブルな混雑制御は、ECT（0）の設定に変更されないことに注意してください。一時的に古典的な混雑コントロールと共存するように適応しますが、古典的な方法でのみ動作する交換用輻輳制御はECT（0）を設定します。
4. In the range between the minimum likely RTT and typical RTTs expected in the intended deployment scenario, a Scalable congestion control MUST converge towards a rate that is as independent of RTT as is possible without compromising stability or utilization (see Appendix A.1.6 for rationale).
4. 意図した展開シナリオで予想される最小RTTと典型的なRTTの間の範囲では、スケーラブルな輻輳制御は、安定性や利用を妥協することなく、可能な限りRTTに依存しないレートに収束する必要があります（根拠については付録A.1.6を参照）。
5. A Scalable congestion control SHOULD remain responsive to congestion when typical RTTs over the public Internet are significantly smaller because they are no longer inflated by queuing delay. It would be preferable for the minimum window of a Scalable congestion control to be lower than 1 segment rather than use the timeout approach described for TCP in Section 6.1.2 of the ECN spec [RFC3168] (or an equivalent for other transports). However, a lower minimum is not set as a formal requirement for L4S experiments (see Appendix A.1.7 for rationale).
5. スケーラブルな輻輳制御は、公共のインターネット上の典型的なRTTがキューイングの遅延によって膨らまないため、大幅に小さくなる場合、混雑に反応する必要があります。ECN仕様[RFC3168]のセクション6.1.2（または他の輸送機に相当）で説明されているタイムアウトアプローチを使用するよりも、スケーラブル輻輳制御の最小ウィンドウが1セグメント未満になることをお望みです。ただし、L4S実験の正式な要件として低い最小値は設定されていません（根拠については付録A.1.7を参照）。
6. A Scalable congestion control's loss detection SHOULD be resilient to reordering over an adaptive time interval that scales with throughput and adapts to reordering (as in Recent ACK (RACK) [RFC8985]), as opposed to counting only in fixed units of packets (as in the 3 Duplicate ACK (DupACK) rule of NewReno [RFC5681] [RFC6675], which is not scalable). As data rates increase (e.g., due to new and/or improved technology), congestion controls that detect loss by counting in units of packets become more likely to incorrectly treat reordering events as congestion-caused loss events (see Appendix A.1.8 for further rationale). This requirement does not apply to congestion controls that are solely used in controlled environments where the network introduces hardly any reordering.
6. スケーラブルな混雑コントロールの損失検出は、スループットとスケーリングし、並べ替えに適応する適応時間間隔を並べ替えるのに回復力がある必要があります（最近のACK（RACK）[RFC8985]のように）。Newreno [RFC5681] [RFC6675]の3つの重複ACK（DUPACK）ルール。これはスケーラブルではありません）。データレートが増加するにつれて（例：新規および/または改善されたテクノロジーのため）、パケットの単位をカウントすることで損失を検出する混雑制御は、繰り返しのイベントを混雑の損失イベントとして誤って処理する可能性が高くなります（さらに詳細については、付録A.1.8を参照してください根拠）。この要件は、ネットワークが並べ替えをほとんど導入しない制御環境でのみ使用される混雑制御には適用されません。
7. A Scalable congestion control is expected to limit the queue caused by bursts of packets. It would not seem necessary to set the limit any lower than 10% of the minimum RTT expected in a typical deployment (e.g., additional queuing of roughly 250 us for the public Internet). This would be converted to a number of packets by multiplying by the current average packet rate. Then, the queue caused by each burst at the bottleneck link would not exceed 250 us (under the worst-case assumption that the flow is filling the capacity). No normative requirement to limit bursts is given here, and until there is more industry experience from the L4S experiment, it is not even known whether one is needed -- it seems to be in an L4S sender's self-interest to limit bursts.
7. スケーラブルな混雑制御は、パケットのバーストによって引き起こされるキューを制限すると予想されます。典型的な展開で予想される最小RTTの10％未満の制限を設定する必要はないようです（たとえば、パブリックインターネットの約250米国の追加のキューイング）。これは、現在の平均パケットレートを乗算することにより、多くのパケットに変換されます。次に、Bottleneckリンクの各バーストによって引き起こされるキューは、250米国を超えません（流れが容量を埋めているという最悪の仮定の下）。ここでバーストを制限するための規範的要件はありません。L4S実験から業界の経験が増えるまで、必要であるかどうかさえ知られていない - バーストを制限するためにL4S送信者の自己利益にあるようです。
Each sender in a session can use a Scalable congestion control independently of the congestion control used by the receiver(s) when they send data. Therefore, there might be ECT(1) packets in one direction and ECT(0) or Not-ECT in the other.
セッションの各送信者は、データを送信する際に受信機が使用する混雑制御とは無関係にスケーラブルな輻輳制御を使用できます。したがって、一方の方向とect（0）または他の方向にはect（1）パケットがあるかもしれません。
Later, this document discusses the conditions for mixing other "'Safe' Unresponsive Traffic" (e.g., DNS, Lightweight Directory Access Protocol (LDAP), NTP, voice, and game sync packets) with L4S traffic; see Section 5.4.1.1. To be clear, although such traffic can share the same queue as L4S traffic, it is not appropriate for the sender to tag it as ECT(1), except in the (unlikely) case that it satisfies the above conditions.
その後、このドキュメントでは、他の「安全な」無反応のトラフィックを混合する条件について説明します（例：DNS、軽量ディレクトリアクセスプロトコル（LDAP）、NTP、音声、ゲーム同期パケット）とL4Sトラフィックについて説明します。セクション5.4.1.1を参照してください。明確にするために、そのようなトラフィックはL4Sトラフィックと同じキューを共有できますが、上記の条件を満たすことを（ありそうもない）場合を除き、送信者がそれをECT（1）としてタグ付けすることは適切ではありません。
[RFC3168] requires the congestion responses to a CE-marked packet and a dropped packet to be the same. [RFC8311] is a Standards Track update to [RFC3168] that is intended to enable experimentation with ECN, including the L4S experiment. [RFC8311] allows an experimental congestion control's response to a CE-marked packet to differ from the response to a dropped packet, provided that the differences are documented in an Experimental RFC, such as the present document.
[RFC3168]では、CEマークされたパケットに対する混雑応答と、ドロップされたパケットが同じにする必要があります。[RFC8311]は、L4S実験を含むECNの実験を可能にすることを目的とした[RFC3168]の標準トラックアップデートです。[RFC8311]により、現在のドキュメントなどの実験RFCで違いが文書化されていれば、CEマークされたパケットに対する実験的な混雑制御の応答がドロップされたパケットへの応答とは異なることができます。
BCP 124 [RFC4774] gives guidance to protocol designers, when specifying alternative semantics for the IP-ECN field. [RFC8311] explained that it did not need to update the best current practice in BCP 124 in order to relax the 'equivalence with drop' requirement because, although BCP 124 quotes the same requirement from [RFC3168], the BCP does not impose requirements based on it. BCP 124 [RFC4774] describes three options for incremental deployment, with Option 3 (in Section 4.3 of BCP 124 [RFC4774]) best matching the L4S case. Option 3's requirement for end-nodes is that they respond to CE marks "in a way that is friendly to flows using IETF-conformant congestion control." This echoes other general congestion control requirements in the RFC Series, for example, [RFC5033] states that "...congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect" and [RFC8085], which concerns UDP congestion control, states that "Bulk-transfer applications that choose not to implement TFRC or TCP-like windowing SHOULD implement a congestion control scheme that results in bandwidth (capacity) use that competes fairly with TCP within an order of magnitude."
BCP 124 [RFC4774]は、IP-ECNフィールドの代替セマンティクスを指定する際に、プロトコル設計者にガイダンスを提供します。[RFC8311]は、BCP 124が[RFC3168]から同じ要件を引用しているが、BCPは要件に基づいた要件を課していないため、「ドロップとの等価」要件を緩和するために、BCP 124の最良の現在のプラクティスを更新する必要はないと説明しました。その上。BCP 124 [RFC4774]は、L4Sケースに最適なオプション3（BCP 124 [RFC4774]のセクション4.3）で、増分展開の3つのオプションを説明しています。オプション3のエンドノードの要件は、CEマークに「IETFコンバースの混雑制御を使用して流れるのに友好的な方法」に応答することです。これは、RFCシリーズの他の一般的な混雑制御要件を反映しています。たとえば、[RFC5033]は、「...標準の混雑制御を使用してトラフィックに大きな悪影響を与える渋滞コントローラーが疑われる可能性がある」と述べています。混雑制御は、「TFRCまたはTCP様ウィンドウを実装しないことを選択したバルク移動アプリケーションは、帯域幅（容量）使用をもたらす混雑制御スキームを実装する必要があると述べています。
The normative Item 3 in Section 4.3 above (which concerns L4S response to congestion from a Classic ECN AQM) aims to ensure that these 'coexistence' requirements are satisfied, but it makes some compromises. This subsection highlights and justifies those compromises, and Appendix A.1.5 and the L4S operational guidance [L4SOPS] give detailed analysis, examples, and references (the normative text in that bullet takes precedence if any informative elaboration leads to ambiguity). The approach is based on an assessment of the risk of harm, which is a combination of the prevalence of the conditions necessary for harm to occur, and the potential severity of the harm if they do.
上記のセクション4.3の規範項目3（古典的なECN AQMからの混雑に対するL4Sの応答に関するL4Sの応答）は、これらの「共存」要件が満たされることを保証することを目的としていますが、いくつかの妥協点が生じます。このサブセクションは、これらの妥協点を強調して正当化し、付録A.1.5とL4S運用ガイダンス[L4SOPS]は、詳細な分析、例、および参照（その弾丸の規範的なテキストが、あいまいさにつながる場合に優先される場合）を提供します。このアプローチは、危害のリスクの評価に基づいています。これは、害が発生するために必要な条件の有病率と、害の潜在的な重症度の組み合わせです。
Prevalence: There are three cases:
有病率：3つのケースがあります。
* Drop Tail: Coexistence between L4S and Classic flows is not in doubt where the bottleneck does not support any form of ECN, which has remained by far the most prevalent case since the ECN spec [RFC3168] was published in 2001.
* ドロップテール：L4Sとクラシックフローの共存は疑いの余地がありません。ボトルネックがECNのいかなる形態もサポートしていません。これは、ECN仕様[RFC3168]が2001年に公開されて以来、最も一般的なケースであり続けています。
* L4S: Coexistence is not in doubt if the bottleneck supports L4S.
* L4S：ボトルネックがL4をサポートしているかどうかは疑いの余地がありません。
* Classic ECN: The compromises centre around cases where the bottleneck supports Classic ECN [RFC3168] but not L4S. But it depends on which sub-case:
* 古典的なECN：妥協点は、ボトルネックがL4Sではなく古典的なECN [RFC3168]をサポートする場合を中心に中心です。しかし、それはどのサブケースに依存します：
- Shared Queue with Classic ECN: At the time of writing, the members of the Transport Working Group are not aware of any current deployments of single-queue Classic ECN bottlenecks in the Internet. Nonetheless, at the scale of the Internet, rarity need not imply small numbers nor that there will be rarity in the future.
- 古典的なECNと共有キュー：執筆時点で、トランスポートワーキンググループのメンバーは、インターネットでの単一の古典的なECNボトルネックの現在の展開を認識していません。それにもかかわらず、インターネットの規模では、希少性は少数を暗示する必要はなく、将来的には希少性があることを意味する必要はありません。
- Per-Flow Queues with Classic ECN: Most AQMs with per-flow queuing deployed from 2012 onwards had Classic ECN enabled by default, specifically FQ-CoDel [RFC8290] and COBALT [COBALT]. But the compromises only apply to the second of two further sub-cases:
- クラシックECNを使用したフローごとのキュー：2012年以降に展開されたフローごとのキューイングを備えたほとんどのAQMSには、デフォルトでクラシックECNが有効になり、特にFQコデル[RFC8290]およびコバルト[コバルト]がありました。しかし、妥協点は、さらに2つのサブケースの2番目にのみ当てはまります。
o With per-flow queuing, coexistence between Classic and L4S flows is not normally a problem, because different flows are not meant to be in the same queue (BCP 124 [RFC4774] did not foresee the introduction of per-flow queuing, which appeared as a potential isolation technique some eight years after the BCP was published).
o フローごとのキューイングでは、クラシックフローとL4Sフローの共存は通常問題ではありません。これは、異なるフローが同じキューにあることを意図していないため（BCP 124 [RFC4774]、流量ごとのキューイングの導入を予見しなかったため、BCPが公開されてから約8年後に潜在的な分離技術が発表されました）。
o However, the isolation between L4S and Classic flows is not perfect in cases where the hashes of flow identifiers (IDs) collide or where multiple flows within a Layer 3 VPN are encapsulated within one flow ID.
o ただし、L4Sとクラシックフローの間の分離は、フロー識別子（ID）のハッシュが衝突したり、レイヤー3 VPN内の複数のフローが1つのフローID内でカプセル化されている場合には完全ではありません。
To summarize, the coexistence problem is confined to cases of imperfect flow isolation in an FQ or in potential cases where a Classic ECN AQM has been deployed in a shared queue (see the L4S operational guidance [L4SOPS] for further details including recent surveys attempting to quantify prevalence). Further, if one of these cases does occur, the coexistence problem does not arise unless sources of Classic and L4S flows are simultaneously sharing the same bottleneck queue (e.g., different applications in the same household), and flows of each type have to be large enough to coincide for long enough for any throughput imbalance to have developed. Therefore, how often the coexistence problem arises in practice is listed in Section 7 as an open question that L4S experiments will need to answer.
要約すると、共存の問題は、FQまたは潜在的なECN AQMが共有キューに展開されている潜在的な場合の不完全な流れの分離の場合に限定されます（L4S運用ガイダンス[L4SOP]を参照してください。有病率を定量化します）。さらに、これらのケースのいずれかが発生した場合、クラシックフローとL4Sフローのソースが同じボトルネックキュー（同じ世帯の異なるアプリケーション）を同時に共有し、各タイプのフローを大きくする必要がある場合を除き、共存の問題は発生しません。スループットの不均衡が発展するのに十分な長さで一致するのに十分です。したがって、L4S実験が答える必要があるという未解決の質問として、実際に共存の問題が実際にどのくらいの頻度でリストされていますか。
Severity: Where long-running L4S and Classic flows coincide in a shared queue, testing of one L4S congestion control (TCP Prague) has found that the imbalance in average throughput between an L4S and a Classic flow can reach 25:1 in favour of L4S in the worst case [ecn-fallback]. However, when capacity is most scarce, the Classic flow gets a higher proportion of the link, for instance, over a 4 Mb/s link the throughput ratio is below ~10:1 over paths with a base RTT below 100 ms, and it falls below ~5:1 for base RTTs below 20 ms.
重大度：長期にわたるL4Sとクラシックフローが共有キューに一致する場合、1つのL4S混雑制御（TCPプラハ）のテストにより、L4Sとクラシックフローの間の平均スループットの不均衡がL4Sを支持して25：1に達する可能性があることがわかりました。最悪の場合[ECN-Fallback]。ただし、容量が最も少ない場合、古典的なフローはリンクの割合が高くなります。たとえば、4 MB/sのリンクを超えると、スループット比は100ミリ秒未満のベースRTTのパスで〜10：1未満です。20ミリ秒未満のベースRTTの場合、〜5：1を下回ります。
These throughput ratios can clearly fall well outside current RFC guidance on coexistence. However, the tendency towards leaving a greater share for Classic flows at lower link rate and the very limited prevalence of the conditions necessary for harm to occur led to the possibility of allowing the RFC requirements to be compromised, albeit briefly:
これらのスループット比は、共存に関する現在のRFCガイダンスの外側に明らかに大きく下がる可能性があります。ただし、クラシックフローのシェアをより低いリンクレートでより多くのシェアを残す傾向があり、危害が発生するために必要な条件の非常に限られた普及により、RFC要件を簡単に侵害する可能性があります。
* The recommended approach is still to detect and adapt to a Classic ECN AQM in real time, which is fully consistent with all the RFCs on coexistence. In other words, the "SHOULD"s in Item 3 of Section 4.3 above expect the sender to implement something similar to the proof-of-concept code that detects the presence of a Classic ECN AQM and falls back to a Classic congestion response within a few round trips [ecn-fallback]. However, although this code reliably detects a Classic ECN AQM, the current code can also wrongly categorize an L4S AQM as Classic, most often in cases when link rate is low or RTT is high. Although this is the safe way round, and although implementers are expected to be able to improve on this proof of concept, concerns have been raised that implementers might lose faith in such detection and disable it.
* 推奨されるアプローチは、まだ古典的なECN AQMをリアルタイムで検出して適応させることです。これは、共存に関するすべてのRFCと完全に一致しています。言い換えれば、上記のセクション4.3の項目3の「severs」は、送信者が古典的なECN AQMの存在を検出し、概念の証明コードに類似したものを実装し、概念的なcomeの応答に戻ることを期待しています。いくつかの往復[ECN-Fallback]。ただし、このコードは古典的なECN AQMを確実に検出しますが、現在のコードはL4S AQMをクラシックとして誤って分類することもできます。これは、リンクレートが低いかRTTが高い場合には、ほとんどの場合、古典的です。これは安全な方法であり、実装者はこの概念の証明を改善できることが期待されていますが、実装者はそのような検出に対する信頼を失い、それを無効にする可能性があるという懸念が提起されています。
* Item 3 in Section 4.3 above therefore allows a compromise where coexistence could briefly diverge from the requirements in the RFC Series, but mandatory monitoring is required in order to detect such cases and trigger remedial action. This approach tolerates a brief divergence from the RFCs given the likely low prevalence and given harm here means a flow progresses more slowly than it would otherwise, but it does progress. The L4S operational guidance [L4SOPS] outlines a range of example remedial actions that include alterations to either the sender or the network. However, the final normative requirement in Item 3 of Section 4.3 above places ultimate responsibility for remedial action on the sender. If coexistence problems with a Classic ECN AQM are detected (implying they have not been resolved by the network), it states that the sender "MUST" revert to a Classic congestion control.
* したがって、上記のセクション4.3の項目3では、共存がRFCシリーズの要件から一時的に分岐できる妥協が可能になりますが、そのようなケースを検出して是正措置を引き起こすためには必須の監視が必要です。このアプローチは、低い有病率の可能性が低く、ここでの害が与えられることを考えると、RFCSからの短い相違を容認します。L4S運用ガイダンス[L4SOPS]は、送信者またはネットワークの変更を含む一連の是正措置の範囲の概要を説明しています。ただし、上記のセクション4.3の項目3の最終的な規範的要件は、送信者に対する是正措置に対する究極の責任を負います。古典的なECN AQMとの共存の問題が検出された場合（それらがネットワークによって解決されていないことを暗示している）、送信者は「従来の輻輳制御」に戻す必要があると述べています。
[L4SOPS] also gives example ways in which L4S congestion controls can be rolled out initially in lower-risk scenarios.
[L4SOPS]は、L4Sの混雑コントロールを最初にリスクの低いシナリオで展開できる方法の例を示しています。
Section 5.2 below specifies that an L4S AQM is expected to signal L4S ECN immediately, to avoid introducing delay due to filtering or smoothing. This contrasts with a Classic AQM, which filters out variations in the queue before signalling ECN marking or drop. In the L4S architecture [RFC9330], responsibility for smoothing out these variations shifts to the sender's congestion control.
以下のセクション5.2では、L4S AQMがL4S ECNをすぐに信号にすることが予想されることを指定し、フィルタリングまたはスムージングによる遅延の導入を避けます。これは、ECNマーキングまたはドロップを信号する前にキューのバリエーションを除去するクラシックAQMとは対照的です。L4Sアーキテクチャ[RFC9330]では、これらのバリエーションを滑らかにする責任は、送信者の混雑制御に移行します。
This shift of responsibility has the advantage that each sender can smooth variations over a timescale proportionate to its own RTT. Whereas, in the Classic approach, the network doesn't know the RTTs of any of the flows, so it has to smooth out variations for a worst-case RTT to ensure stability. For all the typical flows with shorter RTTs than the worst-case, this makes congestion control unnecessarily sluggish.
この責任の変化には、各送信者が独自のRTTに比例したタイムスケールよりもスムーズな変動をスムーズにできるという利点があります。一方、古典的なアプローチでは、ネットワークはフローのRTTを知らないため、安定性を確保するには、最悪のRTTのバリエーションをスムーズにする必要があります。最悪のケースよりも短いRTTを備えたすべての典型的なフローについて、これにより、混雑制御は不必要に遅くなります。
This also gives an L4S sender the choice not to smooth, depending on its context (start-up, congestion avoidance, etc.). Therefore, this document places no requirement on an L4S congestion control to smooth out variations in any particular way. Implementers are encouraged to openly publish the approach they take to smoothing as well as results and experience they gain during the L4S experiment.
これにより、L4S送信者は、コンテキスト（起動、混雑回避など）に応じて、スムーズにしないように選択できます。したがって、このドキュメントは、特定の方法でバリエーションを滑らかにするために、L4Sの混雑制御に要件を課さない。実装者は、L4S実験中に得られる結果と経験と同様に、スムージングに取り組むアプローチを公開することをお勧めします。
A network node that implements the L4S service:
L4Sサービスを実装するネットワークノード：
* MUST classify arriving ECT(1) packets for L4S treatment, unless overridden by another classifier (e.g., see Section 5.4.1.2).
* 別の分類子によってオーバーライドされない限り、L4S治療のために到着ECT（1）パケットを分類する必要があります（たとえば、セクション5.4.1.2を参照）。
* MUST classify arriving CE packets for L4S treatment as well, unless overridden by another classifier or unless the exception referred to next applies.
* 別の分類子によって上書きされない限り、または次に言及されている例外が適用されない限り、L4S治療のために到着するCEパケットも分類する必要があります。
CE packets might have originated as ECT(1) or ECT(0), but the above rule to classify them as if they originated as ECT(1) is the safe choice (see Appendix B for rationale). The exception is where some flow-aware in-network mechanism happens to be available for distinguishing CE packets that originated as ECT(0), as described in Section 5.3, but there is no implication that such a mechanism is necessary.
CEパケットはECT（1）またはECT（0）として発信された可能性がありますが、上記のルールはECT（1）として発信されるかのように分類することが安全な選択です（根拠については付録Bを参照）。例外は、セクション5.3で説明されているように、ECT（0）として発生したCEパケットを区別するために、フロー認識のネットワークメカニズムがたまたま利用可能である場合ですが、そのようなメカニズムが必要であるという意味はありません。
An L4S AQM treatment follows similar codepoint transition rules to those in [RFC3168]. Specifically, the ECT(1) codepoint MUST NOT be changed to any codepoint other than CE, and CE MUST NOT be changed to any other codepoint. An ECT(1) packet is classified as 'ECN-capable', and if congestion increases, an L4S AQM algorithm will increasingly mark the IP-ECN field as CE, otherwise forwarding packets unchanged as ECT(1). Necessary conditions for an L4S marking treatment are defined in Section 5.2.
L4S AQM治療は、[RFC3168]のCodePoint遷移規則に同様のコードポイント遷移規則に従っています。具体的には、ECT（1）CodePointをCE以外のCodePointに変更してはなりません。CEを他のCodePointに変更してはなりません。ECT（1）パケットは「ECN対応」に分類され、輻輳が増加すると、L4S AQMアルゴリズムがIP-ECNフィールドをCEとしてますますマークするようになります。L4Sマーキング処理に必要な条件は、セクション5.2で定義されています。
Under persistent overload, an L4S marking treatment MUST begin applying drop to L4S traffic until the overload episode has subsided, as recommended for all AQM methods in Section 4.2.1 of [RFC7567], which follows the similar advice in Section 7 of [RFC3168]. During overload, it MUST apply the same drop probability to L4S traffic as it would to Classic traffic.
持続的な過負荷の下では、L4Sマーキング処理は、[RFC7567]のセクション4.2.1のすべてのAQMメソッドに推奨されるように、[RFC3168]のセクション7の同様のアドバイスに従うように、過負荷エピソードが沈静化するまでL4Sトラフィックにドロップを適用し始める必要があります。。過負荷中、L4Sトラフィックに同じドロップ確率をクラシックトラフィックに適用する必要があります。
Where an L4S AQM is transport-aware, this requirement could be satisfied by using drop in only the most overloaded individual per-flow AQMs. In a DualQ with flow-aware queue protection (e.g., [DOCSIS-QPROT]), this could be achieved by redirecting packets in those flows contributing most to the overload out of the L4S queue so that they are subjected to drop in the Classic queue.
L4S AQMが輸送認識である場合、この要件は、最も過負荷のある個々の流量AQMのみをドロップすることで満たすことができます。フローアウェアキュー保護を備えたdualq（[docsis-qprot]など）では、L4Sキューの過負荷に最も寄与するフローのパケットをリダイレクトすることで実現できます。。
For backward compatibility in uncontrolled environments, a network node that implements the L4S treatment MUST also implement an AQM treatment for the Classic service as defined in Section 1.2. This Classic AQM treatment need not mark ECT(0) packets, but if it does, see Section 5.2 for the strengths of the markings relative to drop. It MUST classify arriving ECT(0) and Not-ECT packets for treatment by this Classic AQM (for the DualQ Coupled AQM; see the extensive discussion on classification in Sections 2.3 and 2.5.1.1 of [RFC9332]).
制御されていない環境での後方互換性の場合、L4S処理を実装するネットワークノードは、セクション1.2で定義されているように、古典的なサービスのAQM処理も実装する必要があります。この古典的なAQM治療は、ECT（0）パケットをマークする必要はありませんが、もしそうなら、ドロップに対するマーキングの強度については、セクション5.2を参照してください。この古典的なAQMによる到着ECT（0）と治療のための非接続パケットを分類する必要があります（dualq結合されたAQMの場合。
In case unforeseen problems arise with the L4S experiment, it MUST be possible to configure an L4S implementation to disable the L4S treatment. Once disabled, ECT(1) packets MUST be treated as if they were Not-ECT.
L4S実験で予期せぬ問題が発生した場合、L4S治療を無効にするためにL4S実装を構成することが可能である必要があります。無効になったら、ECT（1）パケットは、それがないかのように扱う必要があります。
The relative strengths of L4S CE and drop are irrelevant where AQMs are implemented in separate queues per application-flow, which are then explicitly scheduled (e.g., with an FQ scheduler as in FQ-CoDel [RFC8290]). Nonetheless, the relationship between them needs to be defined for the coupling between L4S and Classic congestion signals in a DualQ Coupled AQM [RFC9332], as indicated below.
L4S CEとドロップの相対強度は、AQMSがアプリケーションフローごとに個別のキューに実装されている場合、明示的にスケジュールされる場合は無関係です（たとえば、FQコデル[RFC8290]のようにFQスケジューラがあります）。それにもかかわらず、それらの間の関係は、以下に示すように、dualq結合されたAQM [RFC9332]のL4Sと古典的なうっ血信号の結合に対して定義する必要があります。
Unless an AQM node schedules application flows explicitly, the likelihood that the AQM drops a Not-ECT Classic packet (p_C) MUST be roughly proportional to the square of the likelihood that it would have marked it if it had been an L4S packet (p_L). That is:
AQMノードがアプリケーションをスケジュールしない限り、AQMが非extクラシックパケット（P_C）をドロップする可能性は、L4Sパケット（P_L）であった場合、それがマークした可能性の正方形にほぼ比例しなければなりません。。あれは：
p_C ~= (p_L / k)^2
The constant of proportionality (k) does not have to be standardized for interoperability, but a value of 2 is RECOMMENDED. The term 'likelihood' is used above to allow for marking and dropping to be either probabilistic or deterministic.
比例定数（k）は相互運用性のために標準化する必要はありませんが、2の値が推奨されます。「尤度」という用語は、マークとドロップを確率的または決定論的にするために上記で使用されます。
This formula ensures that Scalable and Classic flows will converge to roughly equal congestion windows, for the worst case of Reno congestion control. This is because the congestion windows of Scalable and Classic congestion controls are inversely proportional to p_L and sqrt(p_C), respectively. So squaring p_C in the above formula counterbalances the square root that characterizes Reno-friendly flows.
このフォーミュラは、リノの混雑制御の最悪の場合、スケーラブルでクラシックなフローがほぼ等しい輻輳窓に収束することを保証します。これは、スケーラブルと古典的な混雑コントロールの輻輳窓が、それぞれP_LとSQRT（P_C）に反比例するためです。したがって、上記のフォーミュラのP_Cを正方形にして、リノに優しいフローを特徴付ける平方根を相殺します。
Note that, contrary to [RFC3168], an AQM implementing the L4S and Classic treatments does not mark an ECT(1) packet under the same conditions that it would have dropped a Not-ECT packet, as allowed by [RFC8311], which updates [RFC3168]. However, if it marks ECT(0) packets, it does so under the same conditions that it would have dropped a Not-ECT packet [RFC3168].
[RFC3168]に反して、L4Sと古典的な治療法を実装するAQMは、[RFC8311]で許可されているように、非接続パケットをドロップしたのと同じ条件でECT（1）パケットをマークしないことに注意してください。[RFC3168]。ただし、ECT（0）パケットをマークする場合、それは同じ条件下で、非接続パケット[RFC3168]を削除したとします。
Also, in the L4S architecture [RFC9330], the sender, not the network, is responsible for smoothing out variations in the queue. So an L4S AQM MUST signal congestion as soon as possible. Then, an L4S sender generally interprets CE marking as an unsmoothed signal.
また、L4Sアーキテクチャ[RFC9330]では、ネットワークではなく送信者がキューのバリエーションを滑らせる責任があります。したがって、L4S AQMは混雑をできるだけ早く通知する必要があります。次に、L4S送信者は一般に、CEマークを不緩和信号として解釈します。
This requirement does not prevent an L4S AQM from mixing in additional congestion signals that are smoothed, such as the signals from a Classic smoothed AQM that are coupled with unsmoothed L4S signals in the coupled DualQ [RFC9332], but only as long as the onset of congestion can be signalled immediately and can be interpreted by the sender as if it has been signalled immediately, which is important for interoperability
この要件は、L4S AQMが、結合したdualQ [RFC9332]の不滑着L4S信号と組み合わされた古典的な平滑化されたAQMのシグナル[RFC9332]のような、スムーズな追加のうっ血信号で混合することを妨げませんが、輻輳はすぐに信号を受けることができ、送信者がすぐに信号を送られたかのように解釈することができます。これは相互運用性にとって重要です
To implement L4S packet classification, a network node does not need to identify transport-layer flows. Nonetheless, if an L4S network node classifies packets by their transport-layer flow ID and their ECN field, and if all the ECT packets in a flow have been ECT(0), the node MAY classify any CE packets in the same flow as if they were Classic ECT(0) packets. In all other cases, a network node MUST classify all CE packets as if they were ECT(1) packets. Examples of such other cases are: i) if no ECT packets have yet been identified in a flow; ii) if it is not desirable for a network node to identify transport-layer flows; or iii) if some ECT packets in a flow have been ECT(1) (this advice will need to be verified as part of L4S experiments).
L4Sパケット分類を実装するには、ネットワークノードを輸送層のフローを識別する必要はありません。それにもかかわらず、L4Sネットワークノードが輸送層フローIDとECNフィールドによってパケットを分類し、フロー内のすべてのECTパケットがECT（0）である場合、ノードは同じフローのCEパケットを分類する可能性がある場合、それらは古典的なECT（0）パケットでした。他のすべての場合、ネットワークノードは、すべてのCEパケットをECT（1）パケットであるかのように分類する必要があります。そのような他のケースの例は次のとおりです。i）FlowでECTパケットがまだ識別されていない場合。ii）ネットワークノードが輸送層の流れを識別することが望ましくない場合。またはiii）フロー内の一部のECTパケットがECT（1）である場合（このアドバイスはL4S実験の一部として検証する必要があります）。
The examples in this section concern how additional identifiers might complement the L4S identifier to classify packets between class-based queues. Firstly, Section 5.4.1 considers two queues, L4S and Classic, as in the DualQ Coupled AQM [RFC9332], either alone (Section 5.4.1.1) or within a larger queuing hierarchy (Section 5.4.1.2). Then, Section 5.4.2 considers schemes that might combine per-flow 5-tuples with other identifiers.
このセクションの例は、追加の識別子がL4S識別子を補完して、クラスベースのキュー間でパケットを分類する方法に関するものです。まず、セクション5.4.1は、DualQ結合されたAQM [RFC9332]のように、2つのキュー、L4とクラシックを考慮します[RFC9332]（セクション5.4.1.1）またはより大きなキューイング階層内（セクション5.4.1.2）内で。次に、セクション5.4.2では、フローごとの5タプルと他の識別子を組み合わせたスキームを考慮します。
In a typical case for the public Internet, a network element that implements L4S in a shared queue might want to classify some low-rate but unresponsive traffic (e.g., DNS, LDAP, NTP, voice, and game sync packets) into the low-latency queue to mix with L4S traffic. In this case, it would not be appropriate to call the queue an L4S queue, because it is shared by L4S and non-L4S traffic. Instead, it will be called the low-latency or L queue. The L queue then offers two different treatments:
パブリックインターネットの典型的なケースでは、共有キューにL4を実装するネットワーク要素は、低料金で反応しないトラフィック（DNS、LDAP、NTP、音声、ゲーム同期パケットなど）を低いものに分類することをお勧めします。L4Sトラフィックと混合するレイテンシキュー。この場合、L4Sと非L4Sトラフィックで共有されているため、キューをL4Sキューと呼ぶことは適切ではありません。代わりに、低遅延またはlキューと呼ばれます。Lキューは2つの異なる治療を提供します。
* the L4S treatment, which is a combination of the L4S AQM treatment and a priority scheduling treatment, and
* L4S治療は、L4S AQM治療と優先スケジューリング治療の組み合わせであり、
* the low-latency treatment, which is solely the priority scheduling treatment, without ECN marking by the AQM.
* AQMによるECNマークなしの優先スケジューリング治療のみである低遅延治療。
To identify packets for just the scheduling treatment, it would be inappropriate to use the L4S ECT(1) identifier, because such traffic is unresponsive to ECN marking. Examples of relevant non-ECN identifiers are:
スケジューリング処理のみのパケットを特定するには、L4S ECT（1）識別子を使用することは不適切です。そのようなトラフィックはECNマーキングに反応しないためです。関連する非ECN識別子の例は次のとおりです。
* address ranges of specific applications or hosts configured to be, or known to be, safe, e.g., hard-coded Internet of Things (IoT) devices sending low-intensity traffic;
* アドレス範囲は、安全であると知られている、または既知の特定のアプリケーションまたはホストの範囲、たとえば、強度トラフィックを送信するハードコーディングされたモノのインターネット（IoT）デバイスなど。
* certain low data-volume applications or protocols (e.g., ARP and DNS); and
* 特定の低データ式アプリケーションまたはプロトコル（ARPおよびDNSなど）;と
* specific Diffserv codepoints that indicate traffic with limited burstiness such as the EF [RFC3246], VOICE-ADMIT [RFC5865], or proposed Non-Queue-Building (NQB) [NQB-PHB] service classes or equivalent Local-use DSCPs (see [L4S-DIFFSERV]).
* EF [RFC3246]、ボイスアドミット[RFC5865]、または提案されている非キュービルディング（NQB）[NQB-PHB]サービスクラスまたは同等のローカル使用DSCPSなどの破裂が限られているトラフィックを示す特定のDiffServ CodePoints（[参照]l4s-diffserv]）。
To be clear, classifying into the L queue based on application-layer identification (e.g., DNS) is an example of a local optimization, not a recommendation. Applications will not be able to rely on such unsolicited optimization. A more reliable approach would be for the sender to set an appropriate IP-layer identifier, such as one of the above Diffserv codepoints.
明確にするために、アプリケーション層識別（DNSなど）に基づいてLキューに分類することは、局所的最適化の例であり、推奨ではありません。アプリケーションは、このような未承諾の最適化に依存することはできません。より信頼性の高いアプローチは、送信者が上記のDiffServ CodePointのいずれかのような適切なIP層識別子を設定することです。
In summary, a network element that implements L4S in a shared queue MAY classify additional types of packets into the L queue based on identifiers other than the IP-ECN field, but the types SHOULD be 'safe' to mix with L4S traffic, where 'safe' is explained in Section 5.4.1.1.1.
要約すると、共有キューにL4Sを実装するネットワーク要素は、IP-ECNフィールド以外の識別子に基づいて追加のタイプのパケットをLキューに分類することができますが、タイプはL4Sトラフィックと混合するために「安全」でなければなりません。セクション5.4.1.1.1で説明されています。
A packet that carries one of these non-ECN identifiers to classify it into the L queue would not be subject to the L4S ECN-marking treatment, unless it also carried an ECT(1) or CE codepoint. The specification of an L4S AQM MUST define the behaviour for packets with unexpected combinations of codepoints, e.g., a non-ECN-based classifier for the L queue but with ECT(0) in the IP-ECN field (for examples with appropriate behaviours, see Section 2.5.1.1 of the DualQ spec [RFC9332]).
これらの非ECN識別子のいずれかを搭載してLキューに分類するパケットは、ECT（1）またはCE CodePointも運ばない限り、L4S ECNマーク処理の対象とはなりません。L4S AQMの仕様は、コードポイントの予期しない組み合わせ、たとえばLキューの非ECNベースの分類器であるが、IP-ECNフィールドのECT（0）を持つパケットの動作を定義する必要があります（適切な動作の例については、DUALQ仕様のセクション2.5.1.1 [RFC9332]）を参照してください。
For clarity, non-ECN identifiers, such as the examples itemized above, might be used by some network operators who believe they identify non-L4S traffic that would be safe to mix with L4S traffic. They are not alternative ways for a host to indicate that it is sending L4S packets. Only the ECT(1) ECN codepoint indicates to a network element that a host is sending L4S packets (and CE indicates that it could have originated as ECT(1)). Specifically, ECT(1) indicates that the host claims its behaviour satisfies the prerequisite transport requirements in Section 4.
明確にするために、上記の項目などのECN非識別子は、L4Sトラフィックと安全な非L4Sトラフィックを識別すると考えている一部のネットワークオペレーターが使用する場合があります。それらは、ホストがL4Sパケットを送信していることを示す代替方法ではありません。ECT（1）ECN CodePointのみが、ホストがL4Sパケットを送信していることをネットワーク要素に示します（およびCEは、ECT（1）として発生した可能性があることを示します）。具体的には、ECT（1）は、ホストがその動作がセクション4の前提条件輸送要件を満たすと主張することを示しています。
In order to include non-L4S packets in the L queue, a network node MUST NOT change Not-ECT or ECT(0) in the IP-ECN field into an L4S identifier. This ensures that these codepoints survive for any potential use later on the network path. If a non-compliant or malicious network node did swap ECT(0) to ECT(1), the packet could subsequently be ECN-marked by a downstream L4S AQM, but the sender would respond to congestion indications thinking it had sent a Classic packet. This could result in the flow yielding excessively to other L4S flows sharing the downstream bottleneck.
Lキューに非L4Sパケットを含めるために、ネットワークノードは、IP-ECNフィールドのNot-ectまたはECT（0）をL4S識別子に変更してはなりません。これにより、これらのコードポイントは、ネットワークパスの後で使用する可能性のある潜在的な使用のために生き残ることが保証されます。非準拠または悪意のあるネットワークノードがECT（0）をECT（1）に交換した場合、パケットはその後下流のL4S AQMによってECNマークを付けることができますが、送信者は古典的なパケットを送信したと考えてうっ血の兆候に応答します。。これにより、フローが他のL4Sフローに過度に降伏し、下流のボトルネックを共有する可能性があります。
The above section requires unresponsive traffic to be 'safe' to mix with L4S traffic. Ideally, this means that the sender never sends any sequence of packets at a rate that exceeds the available capacity of the bottleneck link. However, typically an unresponsive transport does not even know the bottleneck capacity of the path, let alone its available capacity. Nonetheless, an application can be considered safe enough if it paces packets out (not necessarily with absolute regularity) such that its maximum instantaneous rate from packet to packet stays well below a typical broadband access rate.
上記のセクションでは、L4Sトラフィックと混合するために「安全」であるために無反応のトラフィックが必要です。理想的には、これは、送信者がボトルネックリンクの利用可能な容量を超えるレートでパケットのシーケンスを送信しないことを意味します。ただし、通常、反応しない輸送は、利用可能な容量は言うまでもなく、パスのボトルネック容量さえ知らない。それにもかかわらず、パケットからパケットからパケットまでの最大瞬間レートが典型的なブロードバンドアクセスレートをはるかに下回るように、パケットをパケットアウト（必ずしも絶対規則性とは限らない）ペースをペースアウトする場合、アプリケーションは十分に安全であると見なすことができます。
This is a vague but useful definition, because many low-latency applications of interest, such as DNS, voice, game sync packets, RPC, ACKs, and keep-alives, could match this description.
これは、DNS、音声、ゲーム同期パケット、RPC、ACK、KEEP-Alivesなどの関心の低い低下アプリケーションがこの説明と一致する可能性があるため、あいまいでありながら有用な定義です。
Low-rate streams, such as voice and game sync packets, might not use continuously adapting ECN-based congestion control, but they ought to at least use a 'circuit-breaker' style of congestion response [RFC8083]. If the volume of traffic from unresponsive applications is high enough to overload the link, this will at least protect the capacity available to responsive applications. However, queuing delay in the L queue would probably then rise to the typically higher level targeted by a Classic (drop-based) AQM. If a network operator considers that such self-restraint is not enough, it might want to police the L queue (see Section 8.2 of the L4S architecture [RFC9330]).
音声やゲーム同期パケットなどの低料金のストリームは、ECNベースの混雑制御を継続的に適応させることはできませんが、少なくとも「サーキットブレーカー」スタイルの混雑応答を使用する必要があります[RFC8083]。反応しないアプリケーションからのトラフィックの量がリンクを過負荷するのに十分高い場合、これにより、少なくとも応答性の高いアプリケーションが利用できる容量が保護されます。ただし、Lキューのキューイングの遅延は、おそらく、クラシック（ドロップベースの）AQMによって標的となる通常より高いレベルに上昇するでしょう。ネットワークオペレーターがそのような自己抑制では十分ではないと考えている場合、Lキューを警察したいかもしれません（L4Sアーキテクチャのセクション8.2 [RFC9330]を参照）。
To extend the above example, an operator might want to exclude some traffic from the L4S treatment for a policy reason, e.g., security (traffic from malicious sources) or commercial (e.g., the operator may wish to initially confine the benefits of L4S to business customers).
上記の例を拡張するために、オペレーターは、ポリシーの理由、例えばセキュリティ（悪意のある情報源からのトラフィック）またはコマーシャル（例えば、オペレーターがL4Sの利点をビジネスに限定することを望む場合がある場合、L4S治療からのトラフィックを除外したい場合があります。顧客）。
In this exclusion case, the classifier MUST classify on the relevant locally used identifiers (e.g., source addresses) before classifying the non-matching traffic on the end-to-end L4S ECN identifier.
この除外の場合、分類器は、エンドツーエンドのL4S ECN識別子の非一致トラフィックを分類する前に、関連するローカルに使用される識別子（例：ソースアドレス）に分類する必要があります。
A network node MUST NOT alter the end-to-end L4S ECN identifier from L4S to Classic, because an operator decision to exclude certain traffic from L4S treatment is local-only. The end-to-end L4S identifier then survives for other operators to use, or indeed, they can apply their own policy, independently based on their own choice of locally used identifiers. This approach also allows any operator to remove its locally applied exclusions in future, e.g., if it wishes to widen the benefit of the L4S treatment to all its customers. If a non-compliant or malicious network node did swap ECT(1) to ECT(0), the packet could subsequently be ECN-marked by a downstream Classic ECN AQM. L4S senders are required to detect and handle such treatment (see Item 3 in Section 4.3), but that does not make this swap OK, because such detection is not known to be perfect or immediate.
ネットワークノードは、L4S治療から特定のトラフィックを除外するというオペレーターの決定はローカルのみであるため、エンドツーエンドのL4S ECN識別子をL4Sからクラシックに変更してはなりません。エンドツーエンドのL4S識別子は、他の演算子が使用するために生き残り、実際には、現地で使用されている識別子の選択に基づいて独立して独自のポリシーを適用できます。また、このアプローチにより、すべての顧客にL4S治療の利点を拡大したい場合、すべてのオペレーターが将来、将来のローカルに適用された除外を削除することもできます。非準拠または悪意のあるネットワークノードがECT（1）をECT（0）に交換した場合、その後、下流のクラシックECN AQMによってパケットをマークすることができます。L4S送信者は、そのような治療を検出および処理するために必要です（セクション4.3の項目3を参照）が、このような検出が完全または即時であることが知られていないため、このスワップはOKになりません。
A network node that supports L4S but excludes certain packets carrying the L4S identifier from L4S treatment MUST still apply marking or dropping that is compatible with an L4S congestion response. For instance, it could either drop such packets with the same likelihood as Classic packets or ECN-mark them with a likelihood appropriate to L4S traffic (e.g., the coupled probability in a DualQ Coupled AQM) but aiming for the Classic delay target. It MUST NOT ECN-mark such packets with a Classic marking probability, which could confuse the sender.
L4Sをサポートするが、L4S治療からL4S識別子を運ぶ特定のパケットを除外するネットワークノードは、L4S輻輳応答と互換性のあるマーキングまたはドロップを適用する必要があります。たとえば、古典的なパケットと同じ可能性でそのようなパケットをドロップするか、L4Sトラフィックに適した可能性（例えば、DualQ結合されたAQMの結合確率）でそれらをマークしますが、古典的な遅延ターゲットを目指しています。このようなパケットを、センダーを混乱させる可能性のある古典的なマーキング確率でそのようなパケットをマークしてはなりません。
L4S concerns low latency, which it can provide for all traffic without differentiation and without _necessarily_ affecting bandwidth allocation. Diffserv provides for differentiation of both bandwidth and low latency, but its control of latency depends on its control of bandwidth. L4S and Diffserv can be combined if a network operator wants to control bandwidth allocation but also wants to provide low latency, i.e., for any amount of traffic within one of these allocations of bandwidth (rather than only providing low latency by limiting bandwidth) [L4S-DIFFSERV].
L4Sは低遅延に関するものであり、帯域幅の割り当てに影響を与えることなく、差別化なしにすべてのトラフィックを提供できます。diffservは、帯域幅と低レイテンシの両方の区別を提供しますが、その潜時の制御は帯域幅の制御に依存します。ネットワークオペレーターが帯域幅の割り当てを制御したいだけでなく、帯域幅のこれらの割り当てのいずれか内でのトラフィックの量を低下させたい場合（帯域幅を制限するだけではなく）[L4Sも提供したい場合、L4とDIFFSERVを組み合わせることができます。-diffserv]。
The DualQ examples so far have been framed in the context of providing the default Best Effort Per-Hop Behaviour (PHB) using two queues -- a low-latency (L) queue and a Classic (C) queue. This single DualQ structure is expected to be the most common and useful arrangement. But, more generally, an operator might choose to control bandwidth allocation through a hierarchy of Diffserv PHBs at a node and to offer one (or more) of these PHBs using a pair of queues for a low latency and a Classic variant of the PHB.
これまでのDualQの例は、2つのキュー（L）キューとクラシック（C）キューの2つのキューを使用して、デフォルトのベストエフェクト（PHB）を提供するというコンテキストで組み立てられています。この単一のDualQ構造は、最も一般的で有用な配置であると予想されます。しかし、より一般的には、オペレーターは、ノードでのDiffserv PHBの階層を介して帯域幅の割り当てを制御し、低遅延とPHBの古典的なバリアントのペアを使用して、これらのPHBの1つ（またはそれ以上）を提供することを選択する場合があります。
In the first case, if we assume that a network element provides no PHBs except the DualQ, if a packet carries ECT(1) or CE, the network element would classify it for the L4S treatment irrespective of its DSCP. And, if a packet carried (for example) the EF DSCP, the network element could classify it into the L queue irrespective of its ECN codepoint. However, where the DualQ is in a hierarchy of other PHBs, the classifier would classify some traffic into other PHBs based on DSCP before classifying between the low-latency and Classic queues (based on ECT(1), CE, and perhaps also the EF DSCP or other identifiers as in the above example). [L4S-DIFFSERV] gives a number of examples of such arrangements to address various requirements.
最初のケースでは、ネットワーク要素がDUALQ以外のPHBを提供しないと仮定した場合、パケットがECT（1）またはCEを運ぶ場合、ネットワーク要素はDSCPに関係なくL4S処理のためにそれを分類します。また、パケットが（たとえば）EF DSCPを携帯している場合、ネットワーク要素はECNコードポイントに関係なく、それをLキューに分類できます。ただし、DualQが他のPHBの階層にある場合、分類器は、低遅延と古典的なキューを分類する前に、DSCPに基づいて他のPHBにいくつかのトラフィックを分類します（ECT（1）、CE、およびおそらくEFにも基づきます上記の例のようにDSCPまたはその他の識別子）。[L4S-Diffserv]は、さまざまな要件に対処するためのそのような取り決めの多くの例を示しています。
[L4S-DIFFSERV] describes how an operator might use L4S to offer low latency as well as Diffserv for bandwidth differentiation. It identifies two main types of approach, which can be combined: the operator might split certain Diffserv PHBs between L4S and a corresponding Classic service. Or it might split the L4S and/or the Classic service into multiple Diffserv PHBs. In either of these cases, a packet would have to be classified on its Diffserv and ECN codepoints.
[L4S-Diffserv]は、オペレーターがL4Sを使用して低遅延を提供する方法と、帯域幅の分化のためにDiffservを提供する方法を説明しています。組み合わせることができる2つの主要なタイプのアプローチを識別します。演算子は、L4Sと対応するクラシックサービス間で特定のDiffServ PHBを分割する場合があります。または、L4Sおよび/またはクラシックサービスを複数のDiffServ PHBに分割する場合があります。これらのいずれかの場合、パケットはそのdiffservおよびECNコードポイントに分類する必要があります。
In summary, there are numerous ways in which the L4S ECN identifier (ECT(1) and CE) could be combined with other identifiers to achieve particular objectives. The following categorization articulates those that are valid, but it is not necessarily exhaustive. Those tagged as 'Recommended-standard-use' could be set by the sending host or a network. Those tagged as 'Local-use' would only be set by a network:
要約すると、L4S ECN識別子（ECT（1）およびCE）を他の識別子と組み合わせて、特定の目的を達成する方法は数多くあります。以下の分類は有効なものを明確にしますが、必ずしも網羅的ではありません。「推奨標準使用」としてタグ付けされたものは、送信ホストまたはネットワークによって設定できます。「ローカル使用」としてタグ付けされたものは、ネットワークによってのみ設定されます。
1. Identifiers Complementing the L4S Identifier
1. L4S識別子を補完する識別子
a. Including More Traffic in the L Queue
a. Lキューにもっとトラフィックを含めます
(could use Recommended-standard-use or Local-use identifiers)
（推奨される標準化または現地使用識別子を使用できます）
b. Excluding Certain Traffic from the L Queue
b. Lキューからの特定のトラフィックを除外します
(Local-use only)
（現地でのみ）
2. Identifiers to Place L4S Classification in a PHB Hierarchy
2. L4S分類をPHB階層に配置する識別子
(could use Recommended-standard-use or Local-use identifiers)
（推奨される標準化または現地使用識別子を使用できます）
a. PHBs before L4S ECN Classification
a. L4S ECN分類前のPHB
b. PHBs after L4S ECN Classification
b. L4S ECN分類後のPHB
At a node with per-flow queuing (e.g., FQ-CoDel [RFC8290]), the L4S identifier could complement the transport-layer flow ID as a further level of flow granularity (i.e., Not-ECT and ECT(0) queued separately from ECT(1) and CE packets). In Appendix B, the "Risk of reordering Classic CE packets within a flow" discusses the resulting ambiguity if packets originally set to ECT(0) are marked CE by an upstream AQM before they arrive at a node that classifies CE as L4S. It argues that the risk of reordering is vanishingly small, and the consequence of such a low level of reordering is minimal.
流量あたりのキューイング（FQコデル[RFC8290]など）を備えたノードでは、L4S識別子は、輸送層の流れIDをさらにレベルのフロー粒度（すなわち、not-ectとect（0）が別々にキューに囲まれています。ECT（1）およびCEパケットから）。付録Bでは、「フロー内で古典的なCEパケットを並べ替えるリスク」は、元々ECT（0）に設定されたパケットがCEが上流のAQMによってCEとマークされた場合、CEをL4Sに分類するノードに到達する前にCEがマークされた場合、結果として得られるあいまいさについて説明します。並べ替えのリスクは消えてしまい、そのような低レベルの並べ替えの結果は最小限であると主張しています。
Alternatively, it could be assumed that it is not in a flow's own interest to mix Classic and L4S identifiers. Then, the AQM could use the IP-ECN field to switch itself between a Classic and an L4S AQM behaviour within one per-flow queue. For instance, for ECN-capable packets, the AQM might consist of a simple marking threshold, and an L4S ECN identifier might simply select a shallower threshold than a Classic ECN identifier would.
あるいは、クラシックとL4Sの識別子を混合することは、フロー自身の関心事ではないと想定することができます。次に、AQMはIP-ECNフィールドを使用して、1つのフローキュー内でクラシックとL4S AQMの動作を切り替えることができます。たとえば、ECN対応パケットの場合、AQMは単純なマーキングしきい値で構成され、L4S ECN識別子は、古典的なECN識別子よりも浅いしきい値を選択するだけです。
As well as senders needing to limit packet bursts (Section 4.3), links need to limit the degree of burstiness they introduce. In both cases (senders and links), this is a trade-off, because batch-handling of packets is done for good reason, e.g., for processing efficiency or to make efficient use of medium acquisition delay. Some take the attitude that there is no point reducing burst delay at the sender below that introduced by links (or vice versa). However, delay reduction proceeds by cutting down 'the longest pole in the tent', which turns the spotlight on the next longest, and so on.
パケットバーストを制限する必要がある送信者（セクション4.3）に加えて、リンクは導入するバーストの程度を制限する必要があります。どちらの場合も（送信者とリンク）、これはトレードオフです。これは、パケットのバッチ処理が正当な理由で行われるため、たとえば処理効率や中程度の取得遅延を効率的に使用するためです。一部の人は、リンクによって導入された（またはその逆）以下の送信者でバースト遅延を減らすことができないという態度をとる人もいます。ただし、遅延削減は、「テントの中で最も長いポール」を削減することで進行します。
This document does not set any quantified requirements for links to limit burst delay, primarily because link technologies are outside the remit of L4S specifications. Nonetheless, the following two subsections outline opportunities for addressing bursty links in the process of L4S implementation and deployment.
このドキュメントでは、主にリンクテクノロジーがL4S仕様の送金外であるため、バースト遅延を制限するためにリンクの定量化要件を設定しません。それにもかかわらず、次の2つのサブセクションは、L4Sの実装と展開のプロセスでバーストリンクに対処するための機会を概説します。
It would not make sense to implement an L4S AQM that feeds into a particular link technology without also reviewing opportunities to reduce any form of burst delay introduced by that link technology. This would at least limit the bursts that the link would otherwise introduce into the onward traffic, which would cause jumpy feedback to the sender as well as potential extra queuing delay downstream. This document does not presume to even give guidance on an appropriate target for such burst delay until there is more industry experience of L4S. However, as suggested in Section 4.3, it would not seem necessary to limit bursts lower than roughly 10% of the minimum base RTT expected in the typical deployment scenario (e.g., 250 us burst duration for links within the public Internet).
そのリンクテクノロジーによって導入されたあらゆる形態のバースト遅延を減らす機会をレビューすることなく、特定のリンクテクノロジーにフィードするL4S AQMを実装することは意味がありません。これにより、リンクがそれ以外の場合は以前のトラフィックに導入するバーストが少なくとも制限され、これにより、送信者への冗談のフィードバックが発生し、潜在的な余分なキューイング遅延が下流になります。このドキュメントは、L4Sの業界経験が増えるまで、このようなバースト遅延の適切な目標に関するガイダンスを提供することさえ想定していません。ただし、セクション4.3で示唆されているように、典型的な展開シナリオで予想される最小ベースRTTの約10％よりも低いバーストを制限する必要はないように思われます（たとえば、パブリックインターネット内のリンクの250米国のバースト期間）。
The initial scope of the L4S experiment is to deploy L4S AQMs at bottlenecks and L4S congestion controls at senders. This is expected to highlight interactions with the most bursty upstream links and lead operators to tune down the burstiness of those links in their networks that are configurable or, failing that, to have to compromise on the delay target of some L4S AQMs. It might also require specific redesign work relevant to the most problematic link types. Such knock-on effects of initial L4S deployment would all be a part of the learning from the L4S experiment.
L4S実験の初期範囲は、ボトルネックにL4S AQMSを展開し、L4S混雑コントロールを送信者に展開することです。これは、最も爆発的なアップストリームリンクとの相互作用を強調し、演算子をリードして、構成可能なネットワーク内のリンクの破裂を調整するか、一部のL4S AQMの遅延ターゲットを妥協する必要があるために、それを失敗させることが期待されています。また、最も問題のあるリンクタイプに関連する特定の再設計作業が必要になる場合があります。初期L4S展開のこのようなノックオン効果はすべて、L4S実験からの学習の一部になります。
The details of such link changes are beyond the scope of the present document. Nonetheless, where L4S technology is being implemented on an outgoing interface of a device, it would make sense to consider opportunities for reducing bursts arriving at other incoming interfaces. For instance, where an L4S AQM is implemented to feed into the upstream WAN interface of a home gateway, there would be opportunities to alter the Wi-Fi profiles sent out of any Wi-Fi interfaces from the same device, in order to mitigate incoming bursts of aggregated Wi-Fi frames from other Wi-Fi stations.
このようなリンクの変更の詳細は、現在のドキュメントの範囲を超えています。それにもかかわらず、L4Sテクノロジーがデバイスの発信インターフェイスに実装されている場合、他の着信インターフェイスに到達するバーストを減らす機会を考慮することは理にかなっています。たとえば、L4S AQMがホームゲートウェイのアップストリームWANインターフェイスにフィードするために実装されている場合、同じデバイスからWi-Fiインターフェイスから送信されたWi-Fiプロファイルを変更する機会があります。他のWi-Fiステーションからの集約されたWi-Fiフレームのバースト。
The L4S identifier is expected to work through and within any tunnel without modification, as long as the tunnel propagates the ECN field in any of the ways that have been defined since the first variant in the year 2001 [RFC3168]. L4S will also work with (but does not rely on) any of the more recent updates to ECN propagation in [RFC4301], [RFC6040], or [ECN-SHIM]. However, it is likely that some tunnels still do not implement ECN propagation at all. In these cases, L4S will work through such tunnels, but within them the outer header of L4S traffic will appear as Classic.
L4S識別子は、2001年の最初のバリアント[RFC3168]以降に定義されている方法でトンネルがECNフィールドを伝播する限り、変更なしでトンネル内で動作することが予想されます。L4Sは、[RFC4301]、[RFC6040]、または[ECN-SHIM]のECN伝播に対する最近の更新のいずれかで動作します（ただしません）。ただし、一部のトンネルはまだECN伝播をまったく実装していない可能性があります。これらの場合、L4はそのようなトンネルを通り抜けますが、その中でL4Sトラフィックの外側ヘッダーはクラシックとして表示されます。
AQMs are typically implemented where an IP-layer buffer feeds into a lower layer, so they are agnostic to link-layer encapsulations. Where a bottleneck link is not IP-aware, the L4S identifier is still expected to work within any lower-layer encapsulation without modification, as long it propagates the IP-ECN field as defined for the link technology, for example, for MPLS [RFC5129] or Transparent Interconnection of Lots of Links (TRILL) [TRILL-ECN-SUPPORT]. In some of these cases, e.g., Layer 3 Ethernet switches, the AQM accesses the IP-layer header within the outer encapsulation, so again the L4S identifier is expected to work without modification. Nonetheless, the programme to define ECN for other lower layers is still in progress [ECN-ENCAP].
AQMSは通常、IP層バッファーが下層に供給される場合に実装されているため、リンク層のカプセルに不可知論されます。ボトルネックリンクがIP認識ではない場合、L4S識別子は、修正なしで低層カプセル化内で機能することが予想されます。]または多くのリンク（Trill）[Trill-Ecn-Support]の透明な相互接続。これらのケースのいくつか、例えばレイヤー3イーサネットスイッチでは、AQMが外側のカプセル化内のIP層ヘッダーにアクセスするため、L4S識別子は変更なしで動作すると予想されます。それにもかかわらず、他の下層層のECNを定義するプログラムはまだ進行中です[ECN-ENCAP]。
If a mix of L4S and Classic packets is sent into the same security association (SA) of a VPN, and if the VPN egress is employing the optional anti-replay feature, it could inappropriately discard Classic packets (or discard the records in Classic packets) by mistaking their greater queuing delay for a replay attack (see "Dropped Packets for Tunnels with Replay Protection Enabled" in [Heist21] for the potential performance impact). This known problem is common to both IPsec [RFC4301] and DTLS [RFC9147] VPNs, given they use similar anti-replay window mechanisms. The mechanism used can only check for replay within its window, so if the window is smaller than the degree of reordering, it can only assume there might be a replay attack and discard all the packets behind the trailing edge of the window. The specifications of IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] suggest that an implementer scales the size of the anti-replay window with interface speed, and DTLS v1.3 [RFC9147] states that "The receiver SHOULD pick a window large enough to handle any plausible reordering, which depends on the data rate." However, in practice, the size of a VPN's anti-replay window is not always scaled appropriately.
L4とクラシックパケットの組み合わせがVPNの同じセキュリティ協会（SA）に送信され、VPN出口がオプションのアンチレプレイ機能を使用している場合、クラシックパケットを不適切に廃棄する（またはクラシックパケットのレコードを破棄する可能性があります）リプレイ攻撃のためにより大きなキューイング遅延を間違えることにより（潜在的なパフォーマンスの影響については、[heist21]の「リプレイ保護を有効にしたトンネルのドロップされたパケット」を参照）。この既知の問題は、同様のアンチレプレイウィンドウメカニズムを使用すると、IPSEC [RFC4301]とDTLS [RFC9147] VPNの両方に共通しています。使用されるメカニズムは、ウィンドウ内のリプレイのみをチェックできます。したがって、ウィンドウが再注文の程度よりも小さい場合、リプレイ攻撃があると仮定し、ウィンドウの後ろの端の後ろのすべてのパケットを破棄する可能性があります。IPSEC認証ヘッダー（AH）[RFC4302]の仕様とセキュリティペイロード（ESP）[RFC4303]のカプセル化は、インターフェイス速度でアンチレプレイウィンドウのサイズをスケーリングすることを示唆しています。レシーバーは、データレートに依存するもっともらしい並べ替えを処理するのに十分な大きさのウィンドウを選択する必要があります。」ただし、実際には、VPNのアンチレプレイウィンドウのサイズが常に適切に拡張されるとは限りません。
If a VPN carrying traffic participating in the L4S experiment experiences inappropriate replay detection, the foremost remedy would be to ensure that the egress is configured to comply with the above window-sizing requirements.
L4S実験に参加しているトラフィックを運ぶVPNが不適切なリプレイ検出を経験した場合、最も重要な救済策は、出口が上記のウィンドウサイズの要件に準拠するように構成されていることを確認することです。
If an implementation of a VPN egress does not support a sufficiently large anti-replay window, e.g., due to hardware limitations, one of the temporary alternatives listed in order of preference below might be feasible instead:
VPN出口の実装が十分に大きなアンチレプレイウィンドウをサポートしていない場合、たとえば、ハードウェアの制限により、以下の好みの順にリストされている一時的な代替品の1つが代わりに実行可能になる可能性があります。
* If the VPN can be configured to classify packets into different SAs indexed by DSCP, apply the appropriate locally defined DSCPs to Classic and L4S packets. The DSCPs could be applied by the network (based on the least-significant bit of the IP-ECN field), or by the sending host. Such DSCPs would only need to survive as far as the VPN ingress.
* VPNをDSCPによってインデックス付けされた異なるSASにパケットを分類するように構成できる場合は、適切なローカルで定義されたDSCPをクラシックパケットとL4Sパケットに適用します。DSCPは、ネットワーク（IP-ECNフィールドの最も重要でないビットに基づいて）または送信ホストによって適用できます。このようなDSCPは、VPNイングレスまで生き残るだけでいいでしょう。
* If the above is not possible and it is necessary to use L4S, either of the following might be appropriate as a last resort:
* 上記が不可能で、L4を使用する必要がある場合、次のいずれかのいずれかが最後の手段として適切かもしれません。
- disable anti-replay protection at the VPN egress, after considering the security implications (it is mandatory to allow the anti-replay facility to be disabled in both IPsec and DTLS), or
- セキュリティへの影響を検討した後、VPN出口でアンチレプレイ保護を無効にします（IPSECとDTLの両方でアンチレプレイ施設を無効にすることを許可することは必須です）、または
- configure the tunnel ingress not to propagate ECN to the outer, which would lose the benefits of L4S and Classic ECN over the VPN.
- ECNを外側に伝播しないようにトンネルの侵入を構成します。
Modification to VPN implementations is outside the present scope, which is why this section has so far focused on reconfiguration. Although this document does not define any requirements for VPN implementations, determining whether there is a need for such requirements could be one aspect of L4S experimentation.
VPN実装の変更は現在の範囲外であるため、このセクションはこれまで再構成に焦点を合わせてきました。このドキュメントでは、VPN実装の要件を定義していませんが、そのような要件が必要かどうかを判断することは、L4S実験の1つの側面になる可能性があります。
This section describes open questions that L4S experiments ought to focus on. This section also documents outstanding open issues that will need to be investigated as part of L4S experimentation, given they could not be fully resolved during the working group phase. It also lists metrics that will need to be monitored during experiments (summarizing text elsewhere in L4S documents) and finally lists some potential future directions that researchers might wish to investigate.
このセクションでは、L4Sの実験が焦点を当てるべきであるという未解決の質問について説明します。また、このセクションでは、ワーキンググループフェーズ中に完全に解決できないため、L4S実験の一部として調査する必要がある顕著なオープンな問題も記録しています。また、実験中に監視する必要があるメトリック（L4Sドキュメントの他の場所でテキストの要約）をリストし、最終的に研究者が調査したい可能性のある潜在的な将来の方向性をリストします。
In addition to this section, i) the DualQ spec [RFC9332] sets operational and management requirements for experiments with DualQ Coupled AQMs, and ii) general operational and management requirements for experiments with L4S congestion controls are given in Sections 4 and 5 above, e.g., coexistence and scaling requirements and incremental deployment arrangements.
このセクションに加えて、i）DualQ仕様[RFC9332]は、DUALQ結合AQMSを使用した実験の運用および管理要件を設定し、ii）L4S輻輳制御を使用した実験の一般的な運用および管理要件は、上記のセクション4および5に示されています。、共存とスケーリングの要件と増分展開の取り決め。
The specification of each Scalable congestion control will need to include protocol-specific requirements for configuration and monitoring performance during experiments. Appendix A of [RFC5706] provides a helpful checklist.
各スケーラブルな輻輳制御の仕様には、実験中の構成および監視パフォーマンスのためのプロトコル固有の要件を含める必要があります。[RFC5706]の付録Aは、役立つチェックリストを提供します。
L4S experiments would be expected to answer the following questions:
L4S実験は、次の質問に答えることが期待されます。
* Have all the parts of L4S been deployed, and if so, what proportion of paths support it?
* L4のすべての部分が展開されていますが、もしそうなら、どのパスの割合がそれをサポートしていますか？
- What types of L4S AQMs were deployed, e.g., FQ, coupled DualQ, uncoupled DualQ, other? And how prevalent was each?
- どのような種類のL4S AQMが展開されました。たとえば、FQ、結合Dualq、couplued Dualqなど、他のものは何ですか？そして、それぞれがどの程度流行していましたか？
- Are the signalling patterns emitted by the deployed AQMs in any way different from those expected when the Prague requirements for endpoints were written?
- エンドポイントのプラハの要件が記述されたときに、展開されたAQMSによって放出されるシグナリングパターンは、予想されるものとは何らかの形で異なりますか？
* Does use of L4S over the Internet result in a significantly improved user experience?
* インターネット上でL4を使用すると、ユーザーエクスペリエンスが大幅に改善されますか？
* Has L4S enabled novel interactive applications?
* L4Sは新しいインタラクティブアプリケーションを有効にしましたか？
* Did use of L4S over the Internet result in improvements to the following metrics:
* インターネットでL4を使用したことにより、次のメトリックが改善されました。
- queue delay (mean and 99th percentile) under various loads;
- さまざまな負荷の下でキュー遅延（平均および99パーセンタイル）。
- utilization;
- 利用;
- starvation / fairness; and
- 飢star /公平性;と
- scaling range of flow rates and RTTs?
- 流量とRTTのスケーリング範囲？
* How dependent was the performance of L4S service on the bottleneck bandwidth or the path RTT?
* L4Sサービスのパフォーマンスは、ボトルネックの帯域幅またはパスRTTでどの程度依存していましたか？
* How much do bursty links in the Internet affect L4S performance (see "Underutilization with Bursty Links" in [Heist21]) and how prevalent are they? How much limitation of burstiness from upstream links was needed and/or was realized -- both at senders and at links, especially radio links -- or how much did L4S target delay have to be increased to accommodate the bursts (see Item 7 in Section 4.3 and see Section 5.5.2)?
* インターネット内の爆発的なリンクは、L4Sのパフォーマンスにどの程度影響します（[Heist21]の「Bursty Linksを使用している」を参照）、それらはどれほど一般的ですか？上流のリンクからの破裂の制限が必要であるか、および/または実現されたのは、送信者とリンク、特に無線リンクの両方で、またはバーストに対応するためにL4Sのターゲット遅延をどれだけ増やす必要があるかを増やす必要がありました（セクションの項目7を参照してください4.3およびセクション5.5.2を参照）？
* Is the initial experiment with mis-identified bursty traffic at high RTT (see "Underutilization with Bursty Traffic" in [Heist21]) indicative of similar problems at lower RTTs, and if so, how effective is the suggested remedy in Appendix A.1 of the DualQ spec [RFC9332] (or possible other remedies)?
* 高いRTTでの誤認されたバーストトラフィックの初期実験（[HEIST21]の「HEIST21]の爆発的なトラフィックを使用していない」を参照）を低いRTTで同様の問題を示しています。dualq spec [rfc9332]（または他の救済策の可能性）？
* Was per-flow queue protection typically (un)necessary?
* フローごとのキュー保護は通常（UN）必要でしたか？
- How well did overload protection or queue protection work?
- 過負荷保護またはキュー保護はどの程度うまく機能しましたか？
* How well did L4S flows coexist with Classic flows when sharing a bottleneck?
* L4Sフローは、ボトルネックを共有するときに古典的なフローと共存しましたか？
- How frequently did problems arise?
- どのくらいの頻度で問題が発生しましたか？
- What caused any coexistence problems, and were any problems due to single-queue Classic ECN AQMs (this assumes single-queue Classic ECN AQMs can be distinguished from FQ ones)?
- 共存の問題を引き起こした理由は何ですか？シングルキューの古典的なECN AQMSによる問題はありませんでした（これは、シングルキューの古典的なECN AQMがFQのものと区別できると仮定します）。
* How prevalent were problems with the L4S service due to tunnels/ encapsulations that do not support ECN decapsulation?
* ECN脱カプセル化をサポートしていないトンネル/カプセル化によるL4Sサービスの問題はどれほど一般的でしたか？
* How easy was it to implement a fully compliant L4S congestion control, over various different transport protocols (TCP, QUIC, RMCAT, etc.)?
* さまざまな輸送プロトコル（TCP、QUIC、RMCATなど）にわたって、完全に準拠したL4S混雑制御を実装するのはどれほど簡単でしたか？
Monitoring for harm to other traffic, specifically bandwidth starvation or excess queuing delay, will need to be conducted alongside all early L4S experiments. It is hard, if not impossible, for an individual flow to measure its impact on other traffic. So such monitoring will need to be conducted using bespoke monitoring across flows and/or across classes of traffic.
他のトラフィックへの害の監視、特に帯域幅の飢vまたは過剰なキューイング遅延は、すべての初期L4S実験とともに実施する必要があります。個々の流れが他のトラフィックへの影響を測定することは、不可能ではないにしても困難です。したがって、このような監視は、流れやトラフィックのクラス間でオーダーメイドの監視を使用して実施する必要があります。
* What is the best way forward to deal with L4S over single-queue Classic ECN AQM bottlenecks, given current problems with misdetecting L4S AQMs as Classic ECN AQMs? See the L4S operational guidance [L4SOPS].
* L4S AQMをクラシックECN AQMと誤解することに関する現在の問題を考慮して、シングルキュークラシックECN AQMボトルネックを介してL4を扱うための最良の方法は何ですか？L4S運用ガイダンス[L4SOPS]を参照してください。
* Fixing the poor interaction between current L4S congestion controls and CoDel with only Classic ECN support during flow startup. Originally, this was due to a bug in the initialization of the congestion average in the Linux implementation of TCP Prague. That was quickly fixed, which removed the main performance impact, but further improvement would be useful (by modifying either CoDel or Scalable congestion controls, or both).
* 流れの起動中に、現在のL4S混雑コントロールとCodelの間の貧弱な相互作用を修正することで、Codelsは古典的なECNサポートのみを使用します。もともと、これは、TCPプラハのLinux実装における混雑平均の初期化のバグによるものでした。これはすぐに修正され、主なパフォーマンスの影響が削除されましたが、さらなる改善が役立ちます（コードルまたはスケーラブルな輻輳制御、またはその両方を変更することで）。
Researchers might find that L4S opens up the following interesting areas for investigation:
研究者は、L4Sが調査のために次の興味深い領域を開くことに気付くかもしれません。
* potential for faster convergence time and tracking of available capacity;
* 収束時間を速くし、利用可能な容量の追跡の可能性。
* potential for improvements to particular link technologies and cross-layer interactions with them;
* 特定のリンクテクノロジーの改善とそれらとの交差層相互作用の可能性。
* potential for using virtual queues, e.g., to further reduce latency jitter or to leave headroom for capacity variation in radio networks;
* 仮想キューを使用する可能性、たとえば、レイテンシジッターをさらに削減したり、無線ネットワークの容量のバリエーションのためにヘッドルームを離れる可能性。
* development and specification of reverse path congestion control using L4S building blocks (e.g., AccECN or QUIC);
* L4Sビルディングブロックを使用した逆パス輻輳制御の開発と仕様（例：AccecnまたはQuic）;
* once queuing delay is cut down, what becomes the 'second-longest pole in the tent' (other than the speed of light)?
* キューイングの遅延が削減されると、「テントで2番目に長いポール」（光の速度以外）になるものは何ですか？
* novel alternatives to the existing set of L4S AQMs; and
* L4S AQMSの既存のセットの新しい代替品。と
* novel applications enabled by L4S.
* L4によって有効になった新しいアプリケーション。
The semantics of the 01 codepoint of the ECN field of the IP header are specified by this Experimental RFC. The process for an Experimental RFC to assign this codepoint in the IP header (v4 and v6) is documented in Proposed Standard [RFC8311], which updates the Proposed Standard [RFC3168].
IPヘッダーのECNフィールドの01コードポイントのセマンティクスは、この実験RFCによって指定されています。実験的なRFCがこのコードポイントをIPヘッダー（V4およびV6）に割り当てるプロセスは、提案された標準[RFC8311]に文書化されており、提案された標準[RFC3168]を更新します。
IANA has updated the 01 entry in the "ECN Field (Bits 6-7)" registry (see <https://www.iana.org/assignments/dscp-registry/>) as follows:
IANAは、「ECNフィールド（ビット6-7）」レジストリの01エントリを更新しました（<https://www.iana.org/assignments/dscp-registry/>を参照）：
+========+=====================+=======================+
| Binary | Keyword | Reference |
+========+=====================+=======================+
| 01 | ECT(1) (ECN-Capable | [RFC8311] [RFC Errata |
| | Transport(1))[1] | 5399] RFC 9331 |
+--------+---------------------+-----------------------+
Table 1: ECN Field (Bits 6-7) Registry
表1：ECNフィールド（ビット6-7）レジストリ
[1] ECT(1) is for experimental use only [RFC8311], Section 4.2
[1] ECT（1）は、実験用のみ[RFC8311]、セクション4.2
Approaches to assure the integrity of signals using the new identifier are introduced in Appendix C.1. See the security considerations in the L4S architecture [RFC9330] for further discussion of misuse of the identifier, as well as extensive discussion of policing rate and latency in regard to L4S.
新しい識別子を使用した信号の整合性を保証するアプローチは、付録C.1に紹介されています。識別子の誤用についてのさらなる議論、およびL4Sに関する警察速度と潜時の広範な議論については、L4Sアーキテクチャ[RFC9330]のセキュリティに関する考慮事項を参照してください。
Defining ECT(1) as the L4S identifier introduces a difference between the effects of ECT(0) and ECT(1) that [RFC3168] previously defined as distinct but with equivalent effect. For L4S ECN, a network node is still required not to swap one to the other, even if the network operator chooses to locally apply the treatment associated with the opposite codepoint (see Sections 5.4.1.1 and 5.4.1.2). These sections also describe the potential effects if a non-compliant or malicious network node does swap one to the other. The present specification does not change the effects of other unexpected transitions of the IP-ECN field, which are still as described in Section 18 of [RFC3168].
L4S識別子としてECT（1）を定義すると、以前に明確であるが同等の効果があると定義されていたECT（0）とECT（1）の効果の違いを導入します。L4S ECNの場合、ネットワークオペレーターが反対のコードポイントに関連する治療をローカルに適用することを選択した場合でも、ネットワークノードは片方に交換しないように必要です（セクション5.4.1.1および5.4.1.2を参照）。これらのセクションでは、非準拠または悪意のあるネットワークノードが一方を他方に交換する場合の潜在的な影響についても説明します。現在の仕様では、[RFC3168]のセクション18で説明されているように、IP-ECNフィールドの他の予期しない遷移の効果を変更しません。
If the anti-replay window of a VPN egress is too small, it will mistake deliberate delay differences as a replay attack and discard higher-delay packets (e.g., Classic) carried within the same security association (SA) as low-delay packets (e.g., L4S). Section 6.2 recommends that VPNs used in L4S experiments are configured with a sufficiently large anti-replay window, as required by the relevant specifications. It also discusses other alternatives.
VPN出口のアンチレプレイウィンドウが小さすぎる場合、意図的な遅延差をリプレイ攻撃と間違え、低遅延パケット（SA）内で運ばれる高層パケット（クラシック）を破棄します（クラシック）（クラシック）たとえば、L4S）。セクション6.2では、L4S実験で使用されるVPNは、関連する仕様で要求されるように、十分に大きなレプレイウィンドウで構成されることを推奨しています。また、他の代替案についても説明します。
If a user taking part in the L4S experiment sets up a VPN without being aware of the above advice, and if the user allows anyone to send traffic into their VPN, they would open up a DoS vulnerability in which an attacker could induce the VPN's anti-replay mechanism to discard enough of the user's Classic (C) traffic (if they are receiving any) to cause a significant rate reduction. While the user is actively downloading C traffic, the attacker sends C traffic into the VPN to fill the remainder of the bottleneck link, then sends intermittent L4S packets to maximize the chance of exceeding the VPN's replay window. The user can prevent this attack by following the recommendations in Section 6.2.
L4S実験に参加しているユーザーが、上記のアドバイスを認識せずにVPNを設定し、ユーザーが誰でもVPNにトラフィックを送信できる場合、攻撃者がVPNのアンチを誘導できるDOSの脆弱性を開きます。 - ユーザーのクラシック（c）トラフィックを十分に廃棄するためのレプレイメカニズム（c）トラフィック（それらが受け取っている場合）は、大幅なレート削減を引き起こします。ユーザーがCトラフィックを積極的にダウンロードしている間、攻撃者はcトラフィックをVPNに送信してボトルネックリンクの残りの部分を埋め、断続的なL4Sパケットを送信して、VPNのリプレイウィンドウを超える可能性を最大化します。ユーザーは、セクション6.2の推奨事項に従ってこの攻撃を防ぐことができます。
The recommendation to detect loss in time units prevents the ACK-splitting attacks described in [Savage-TCP].
時間単位の損失を検出するための推奨事項は、[Savage-TCP]に記載されているACK分割攻撃を防ぎます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、DOI 10.17487/RFC3168、2001年9月、<https：// www。rfc-editor.org/info/rfc3168>。
[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>。
[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>。
[A2DTCP] Zhang, T., Wang, J., Huang, J., Huang, Y., Chen, J., and Y. Pan, "Adaptive-Acceleration Data Center TCP", IEEE Transactions on Computers, Volume 64, Issue 6, pp. 1522-1533, DOI 10.1109/TC.2014.2345393, June 2015, <https://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=6871352>.
[A2DTCP] Zhang、T.、Wang、J.、Huang、J.、Huang、Y.、Chen、J。、およびY. Pan、「Adaptive-Acceleration Data Center TCP」、IEEE Transactions on Computers、Volume 64、第6号、pp。1522-1533、doi 10.1109/tc.2014.2345393、2015年6月、<https://ieeexplore.ieee.org/xpl/ articledetails.jsp？arnumber = 6871352>。
[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>。
[Ahmed19] Ahmed, A.S., "Extending TCP for Low Round Trip Delay", Master's Thesis, University of Oslo, August 2019, <https://www.duo.uio.no/handle/10852/70966>.
[Ahmed19] Ahmed、A.S。、「低往復遅延のためのTCPの拡張」、修士論文、オスロ大学、2019年8月、<https://www.duo.uio.no/handle/10852/70966>。
[Alizadeh-stability] Alizadeh, M., Javanmard, A., and B. Prabhakar, "Analysis of DCTCP: Stability, Convergence, and Fairness", SIGMETRICS '11: Proceedings of the ACM SIGMETRICS Joint International Conference on Measurement and Modeling of Computer Systems, pp. 73-84, DOI 10.1145/1993744.1993753, June 2011, <https://dl.acm.org/doi/10.1145/1993744.1993753>.
[Alizadeh安定性] Alizadeh、M.、Javanmard、A。、およびB. Prabhakar、「DCTCPの分析：安定性、収束、公平性」、Sigmetrics '11：ACM Sigmetrics共同国際会議の議事録測定とモデリングの測定とモデリングの議事録コンピューターシステム、pp。73-84、DOI 10.1145/1993744.1993753、2011年6月、<https://dl.acm.org/doi/10.1145/1993744.1993753>。
[ARED01] Floyd, S., Gummadi, R., and S. Shenker, "Adaptive RED: An Algorithm for Increasing the Robustness of RED's Active Queue Management", ACIRI Technical Report 301, August 2001, <https://www.icsi.berkeley.edu/icsi/node/2032>.
[ARED01] Floyd、S.、Gummadi、R。、およびS. Shenker、「適応レッド：Redのアクティブキュー管理の堅牢性を高めるためのアルゴリズム」、Aciri Technical Report 301、2001年8月、<https：// www。Icsi.berkeley.edu/icsi/node/2032>。
[BBR-CC] Cardwell, N., Cheng, Y., Hassas Yeganeh, S., Swett, I., and V. Jacobson, "BBR Congestion Control", Work in Progress, Internet-Draft, draft-cardwell-iccrg-bbr-congestion-control-02, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>.
[BBR-CC] Cardwell、N.、Cheng、Y.、Hassas Yeganeh、S.、Swett、I。、およびV. Jacobson、「BBR輻輳制御」、作業中、インターネットドラフト、Draft-Cardwell-Iccrg-bbr-congestion-control-02、2022年3月7日、<https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control-02>。
[BBRv2] "TCP BBR v2 Alpha/Preview Release", commit 17700ca, June 2022, <https://github.com/google/bbr>.
[BBRV2]「TCP BBR V2 ALPHA/プレビューリリース」、Commit 17700CA、2022年6月、<https://github.com/google/bbr>。
[Bufferbloat] The Bufferbloat community, "Bufferbloat", <https://bufferbloat.net/>.
[bufferbloat] bufferbloatコミュニティ、「bufferbloat」、<https://bufferbloat.net/>。
[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>。
[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, 3 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月3日、<https://datatracker.ietf.org/doc/html/draft-sridharan-tcpm-ctcp-02>。
[DCttH19] De Schepper, K., Bondarenko, O., Tilmans, O., and B. Briscoe, "'Data Centre to the Home': Ultra-Low Latency for All", Updated RITE project Technical Report, July 2019, <https://bobbriscoe.net/projects/latency/ dctth_journal_draft20190726.pdf>.
[dctth19] de Schepper、K.、Bondarenko、O.、Tilmans、O.、およびB. Briscoe、「 'Data Center to the Home'：すべてのための超低レイテンシ」、更新されたRite Project Technical Report、2019年7月、<https://bobbriscoe.net/projects/latency/ dctth_journal_draft20190726.pdf>。
[DOCSIS-QPROT] 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-qprot] 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>。
[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++] Bagnulo, M. and B. Briscoe, "ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets", Work in Progress, Internet-Draft, draft-ietf-tcpm-generalized-ecn-10, 27 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-10>.
[ECN] Bagnulo、M。and B. Briscoe、「ECN：TCP制御パケットに明示的な混雑通知（ECN）の追加」、作業中の作業、インターネットドラフト、ドラフト-ITF-TCPMジェネラル化ECN-10、7月27日2022、<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-10>。
[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-ECADERINES-17、11 112022年7月、<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>。
[ecn-fallback] Briscoe, B. and A. Ahmed, "TCP Prague Fall-back on Detection of a Classic ECN AQM", Technical Report: TR-BB-2019-002, DOI 10.48550/arXiv.1911.00710, February 2021, <https://arxiv.org/abs/1911.00710>.
[ECN-Fallback] Briscoe、B。およびA. Ahmed、「TCP Prague Fall Back of a Classic ECN AQM」、テクニカルレポート：TR-BB-2019-002、DOI 10.48550/arxiv.1911.00710、2021年2月、<https://arxiv.org/abs/1911.00710>。
[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>。
[Heist21] "L4S Tests", commit e21cd91, August 2021, <https://github.com/heistp/l4s-tests>.
[Heist21] "L4Sテスト"、E21CD91を2021年8月、<https://github.com/heistp/l4s-tests>。
[L4S-DIFFSERV] Briscoe, B., "Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services", Work in Progress, Internet-Draft, draft-briscoe-tsvwg-l4s-diffserv-02, 1 November 2018, <https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>.
[L4S-Diffserv] Briscoe、B。、「低遅延、低損失、スケーラブルスループット（L4S）および差別化サービスの相互作用」、進行中の作業、インターネットドラフト、ドラフトブリスコー-TVWG-L4S-DiffServ-02、12018年11月、<https://datatracker.ietf.org/doc/html/draft-briscoe-tsvwg-l4s-diffserv-02>。
[L4Seval22] De Schepper, K., Albisser, O., Tilmans, O., and B. Briscoe, "Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for All", Preprint submitted to IEEE/ACM Transactions on Networking, DOI 10.48550/arXiv.2209.01078, September 2022, <https://arxiv.org/abs/2209.01078>.
[L4Seval22] De Schepper、K.、Albisser、O.、Tilmans、O.、およびB. Briscoe、「デュアルキュー結合AQM：すべてのために非常に低いキューイング遅延遅延」、ネットワーキングでIEEE/ACMトランザクションに提出されたプレリント、DOI10.48550/arxiv.2209.01078、2022年9月、<https://arxiv.org/abs/2209.01078>。
[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>。
[LinuxPacedChirping] Misund, J. and B. Briscoe, "Paced Chirping - Rethinking TCP start-up", Proceedings of Linux Netdev 0x13, March 2019, <https://legacy.netdevconf.info/0x13/ session.html?talk-chirp>.
[LinuxPacedChirping] Misund、J。およびB. Briscoe、「Paced Chirping -Rethinking TCP Starting」、Linux Netdev 0x13、2019年3月の議事-chirp>。
[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>。
[PI2] De Schepper, K., Bondarenko, O., Tsang, I., and B. Briscoe, "PI^2: A Linearized AQM for both Classic and Scalable TCP", Proceedings of ACM CoNEXT 2016, pp. 105-119, DOI 10.1145/2999572.2999578, December 2016, <https://dl.acm.org/citation.cfm?doid=2999572.2999578>.
[PI2] De Schepper、K.、Bondarenko、O.、Tsang、I。、およびB. Briscoe、「Pi^2：ACM Conext 2016の議事録、Pi^2の線形AQM」、pp。105-119、DOI 10.1145/2999572.2999578、2016年12月、<https://dl.acm.org/citation.cfm?doid=2999572.299578>。
[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. Ahmed, "Implementing the 'TCP Prague' Requirements for L4S", Proceedings of Linux Netdev 0x13, March 2019, <https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>.
[Praguelinux] Briscoe、B.、De Schepper、K.、Albisser、O.、Misund、J.、Tilmans、O.、Khlewind、M.、A。Ahmed、「L4の「TCPプラハ」要件の実装」、Linux NetDev 0x13の議事録、2019年3月、<https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s>。
[QV] Briscoe, B. and P. Hurtig, "Report on Prototype Development and Evaluation of Network and Interaction Techniques", RITE Technical Report, Deliverable 2.3, Appendix C.2: "Up to Speed with Queue View", September 2015, <https://riteproject.files.wordpress.com/2015/12/ rite-deliverable-2-3.pdf>.
[QV] Briscoe、B。and P. Hurtig、「ネットワークおよび相互作用技術のプロトタイプの開発と評価に関する報告」、Rite Technical Report、Apferyable 2.3、付録C.2：「キュービューとの速度まで」、2015年9月、<https://riteproject.files.wordpress.com/2015/12/ rite-deliverable-2-3.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>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの分化サービスフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487/RFC2474、1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[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>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487/RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487/RFC4302、2005年12月、<https://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）をカプセル化するIP」、RFC 4303、DOI 10.17487/RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。
[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>。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, <https://www.rfc-editor.org/info/rfc4341>.
[RFC4341] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（DCCP）混雑制御ID 2：TCP様渋滞制御」、RFC 4341、DOI 10.17487/RFC4341、2006年3月、<HTTPS：//www.rfc-editor.org/info/rfc4341>。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, <https://www.rfc-editor.org/info/rfc4342>.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「データグラムの混雑制御プロトコル（DCCP）混雑制御IDのプロファイル：TCPフレンドリーレートコントロール（TFRC）」、RFC 4342、DOI 10.17487/RFC43422222222222422、2006年3月、<https://www.rfc-editor.org/info/rfc4342>。
[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>。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5129] Davie、B.、Briscoe、B。、およびJ. Tay、「MPLSの明示的な混雑マーキング」、RFC 5129、DOI 10.17487/RFC5129、2008年1月、<https://www.rfc-ed.org/g/情報/RFC5129>。
[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>。
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. Ramakrishnan, "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, DOI 10.17487/RFC5562, June 2009, <https://www.rfc-editor.org/info/rfc5562>.
[RFC5562] Kuzmanovic、A.、Mondal、A.、Floyd、S。、およびK. Ramakrishnan、「TCPのSyn/ACKパケットに明示的な混雑通知（ECN）機能を追加」、RFC 5562、DOI 10.17487/RFC5562、2009年6月、<https://www.rfc-editor.org/info/rfc5562>。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, DOI 10.17487/RFC5622, August 2009, <https://www.rfc-editor.org/info/rfc5622>.
[RFC5622] Floyd、S。およびE. Kohler、「データグラムの混雑制御プロトコルのプロファイル（DCCP）混雑ID 4：TCPフレンドリーレートコントロール（TFRC-SP）、RFC 5622、DOI 10.17487/RFC5622、8月、8月2009、<https://www.rfc-editor.org/info/rfc5622>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.、およびE. Blanton、「TCP混雑制御」、RFC 5681、DOI 10.17487/RFC5681、2009年9月、<https://www.rfc-editor.org/info/RFC5681>。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <https://www.rfc-editor.org/info/rfc5706>.
[RFC5706] Harrington、D。、「新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン」、RFC 5706、DOI 10.17487/RFC5706、2009年11月、<https：//www.rfc-editor.org/fo/rfc5706>。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <https://www.rfc-editor.org/info/rfc5865>.
[RFC5865] Baker、F.、Polk、J。、およびM. Dolly、「容量採用トラフィックの差別化されたサービスコードポイント（DSCP）」、RFC 5865、DOI 10.17487/RFC5865、2010年5月、<https：//www.rfc-editor.org/info/rfc5865>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「TCP認証オプション」、RFC 5925、DOI 10.17487/RFC5925、2010年6月、<https://www.rfc-editor.org/info/rfc5925>。
[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>
[RFC6077] Papadimitriou, D., Ed., Welzl, M., Scharf, M., and B. Briscoe, "Open Research Issues in Internet Congestion Control", RFC 6077, DOI 10.17487/RFC6077, February 2011, <https://www.rfc-editor.org/info/rfc6077>.
[RFC6077] Papadimitriou、D.、Ed。、Welzl、M.、Scharf、M.、およびB. Briscoe、「インターネット混雑制御におけるオープン研究の問題」、RFC 6077、DOI 10.17487/RFC6077、2011年2月、<https：//www.rfc-editor.org/info/rfc6077>。
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, <https://www.rfc-editor.org/info/rfc6660>.
[RFC6660] Briscoe、B.、Moncaster、T。、およびM. Menth、「単一のDiffserv CodePoint（DSCP）を使用してIPヘッダーの3つの前の通知（PCN）状態をコードする」、RFC 6660、DOI 10.17487/RFC666000、2012年7月、<https://www.rfc-editor.org/info/rfc660>。
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.
[RFC6675] Blanton、E.、Allman、M.、Wang、L.、Jarvinen、I.、Kojo、M.、Y。nishida、「TCPの選択的承認（SACK）に基づく保守的な損失回復アルゴリズム」RFC 6675、DOI 10.17487/RFC6675、2012年8月、<https://www.rfc-editor.org/info/rfc6675>。
[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>
[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>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C。and V. Singh、「マルチメディア混雑制御：ユニキャストRTPセッション用のサーキットブレーカー」、RFC 8083、DOI 10.17487/RFC8083、2017年3月、<https：//www.rfc-editor.org/info/RFC8083>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] Eggert、L.、Fairhurst、G.、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487/RFC8085、2017年3月、<https://www.rfc-editor.org/info/rfc8085>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8257] Bensley、S.、Thaler、D.、Balasubramanian、P.、Eggert、L。、およびG. Judd、「データセンターTCP（DCTCP）：TCP 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>。
[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>
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.
[RFC9001] Thomson、M.、ed。and S. Turner、ed。、「TLSを使用してQUICを確保する」、RFC 9001、DOI 10.17487/RFC9001、2021年5月、<https://www.rfc-editor.org/info/rfc9001>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, <https://www.rfc-editor.org/info/rfc9330>.
[RFC9330] Briscoe、B.、Ed。、De Schepper、K.、Bagnulo、M.、およびG. White、「低遅延、低損失、スケーラブルなスループット（L4S）インターネットサービス：アーキテクチャ」、RFC 9330、DOI10.17487/rfc9330、2023年1月、<https://www.rfc-editor.org/info/rfc9330>。
[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>。
[Savage-TCP] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM SIGCOMM Computer Communication Review, Volume 29, Issue 5, pp. 7178, DOI 10.1145/505696.505704, October 1999, <https://dl.acm.org/doi/abs/10.1145/505696.505704>.
[Savage-TCP] Savage、S.、Cardwell、N.、Wetherall、D。、およびT. Anderson、「不正行為レシーバーによるTCP混雑制御」、ACM Sigcomm Computer Communication Review、Volume 29、Issue 5、pp。7178、DOI 10.1145/505696.505704、1999年10月、<https://dl.acm.org/doi/abs/10.1145/505696.505704>。
[SCReAM-L4S] "SCReAM", commit 140e292, November 2022, <https://github.com/EricssonResearch/scream>.
[Scream-l4s] "Scream"、commit 140e292、2022年11月、<https://github.com/ericssonresearch/scream>。
[SCTP-ECN] Stewart, R., Txen, 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>.
[SCTP-ECN] Stewart、R.、Txen、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>。
[sub-mss-prob] Briscoe, B. and K. De Schepper, "Scaling TCP's Congestion Window for Small Round Trip Times", BT Technical Report: TR-TUB8-2015-002, DOI 10.48550/arXiv.1904.07598, May 2015, <https://arxiv.org/abs/1904.07598>.
[Sub-MSS-Prob] Briscoe、B。およびK. de Schepper、「小さな往復時間のTCPの混雑ウィンドウのスケーリング」、BTテクニカルレポート：TR-TUB8-2015-002、DOI 10.48550/arxiv.1904.07598、2015年5月、<https://arxiv.org/abs/1904.07598>。
[TCP-CA] Jacobson, V. and M. J. Karels, "Congestion Avoidance and Control", Laurence Berkeley Labs Technical Report, November 1988, <https://ee.lbl.gov/papers/congavoid.pdf>.
[TCP-CA]ジェイコブソン、V。およびM. J.カレル、「混雑の回避と制御」、ローレンス・バークレー・ラボのテクニカルレポート、1988年11月、<https://ee.lbl.gov/papers/congavoid.pdf>。
[TCPPrague] Briscoe, B., "Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague", message to the tcpPrague mailing list, July 2015, <https://www.ietf.org/mail-archive/web/tcpprague/current/msg00001.html>.
[Tcpprague] Briscoe、B。、「注：DCTCP Evolution 'Bar Bof'：2015年7月21日、17：40、プラハ」、TCPPRAGUEメーリングリストへのメッセージ、2015年7月、<https://www.ietf.org/mail-archive/web/tcpprague/current/msg00001.html>。
[TRILL-ECN-SUPPORT] Eastlake 3rd, D. and B. Briscoe, "TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support", Work in Progress, Internet-Draft, draft-ietf-trill-ecn-support-07, 25 February 2018, <https://datatracker.ietf.org/doc/html/ draft-ietf-trill-ecn-support-07>.
[Trill-Ecn-Support] Eastlake 3rd、D。and B. briscoe、「Trill（多くのリンクの透明な相互接続）：ECN（明示的な混雑通知）サポート」、進行中の作業、インターネットドラフト、ドラフト-IT-ITSF-TRILL-ecn-support-07、2018年2月25日、<https://datatracker.ietf.org/doc/html/ draft-ietf-trill-ecn-support-07>。
[VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, "One more bit is enough", SIGCOMM '05: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 37-48, DOI 10.1145/1080091.1080098, August 2005, <https://doi.acm.org/10.1145/1080091.1080098>.
[VCP] Xia、Y.、Subramanian、L.、Stoica、I。、およびS. Kalyanaraman、「もう1つは十分です」、Sigcomm '05：2005年のアプリケーション、技術、建築、およびプロトコルに関する2005年の会議の議事録Computer Communications、pp。37-48、DOI 10.1145/1080091.1080098、2005年8月、<https://doi.acm.org/10.1145/1080091.1080098>。
This appendix is informative, not normative. It gives a list of modifications to current Scalable congestion controls so that they can be deployed over the public Internet and coexist safely with existing traffic. The list complements the normative requirements in Section 4 that a sender has to comply with before it can set the L4S identifier in packets it sends into the Internet. As well as rationale for safety improvements (the requirements in Section 4), this appendix also includes preferable performance improvements (optimizations).
この付録は有益であり、規範的ではありません。現在のスケーラブルな輻輳制御の修正のリストを提供して、公開インターネット上に展開し、既存のトラフィックと安全に共存できるようにします。このリストは、送信者がインターネットに送信するパケットにL4S識別子を設定する前に、送信者が従わなければならないセクション4の規範的要件を補完します。安全改善の理論的根拠（セクション4の要件）に加えて、この付録には好ましいパフォーマンスの改善（最適化）も含まれています。
The requirements and recommendations in Section 4 have become known as the 'Prague L4S Requirements', because they were originally identified at an ad hoc meeting during IETF 94 in Prague [TCPPrague]. They were originally called the 'TCP Prague Requirements', but they are not solely applicable to TCP, so the name and wording has been generalized for all transport protocols, and the name 'TCP Prague' is now used for a specific implementation of the requirements.
セクション4の要件と推奨事項は、「プラハL4S要件」として知られるようになりました。これは、プラハ[TCPPRAGUE]のIETF 94でのアドホックミーティングで元々特定されたためです。それらはもともと「TCPプラハの要件」と呼ばれていましたが、TCPにのみ適用できないため、名前と言葉遣いはすべての輸送プロトコルに一般化されており、「TCP Prague」という名前が要件の特定の実装に使用されています。。
At the time of writing, DCTCP [RFC8257] is the most widely used Scalable transport protocol. In its current form, DCTCP is specified to be deployable only in controlled environments. Deploying it in the public Internet would lead to a number of issues, from both the safety and the performance perspective. The modifications and additional mechanisms listed in this section will be necessary for its deployment over the global Internet. Where an example is needed, DCTCP is used as a base, but the requirements in Section 4 apply equally to other Scalable congestion controls, covering adaptive real-time media, etc., not just capacity-seeking behaviours.
執筆時点で、DCTCP [RFC8257]は、最も広く使用されているスケーラブルトランスポートプロトコルです。現在の形式では、DCTCPは制御された環境でのみ展開できるように指定されています。パブリックインターネットに展開すると、安全性とパフォーマンスの観点から、多くの問題が発生します。このセクションにリストされている変更と追加のメカニズムは、グローバルなインターネット上の展開に必要です。例が必要な場合、DCTCPはベースとして使用されますが、セクション4の要件は、容量を求める行動だけでなく、適応性のあるリアルタイムメディアなどをカバーする他のスケーラブルな混雑コントロールに等しく適用されます。
Description: A Scalable congestion control needs to distinguish the packets it sends from those sent by Classic congestion controls (see the precise normative requirement wording in Section 4.1).
説明：スケーラブルな輻輳制御は、それが送信するパケットを古典的な混雑制御によって送られたものと区別する必要があります（セクション4.1の正確な規範的要件の言葉遣いを参照）。
Motivation: It needs to be possible for a network node to classify L4S packets without flow state into a queue that applies an L4S ECN-marking behaviour and isolates L4S packets from the queuing delay of Classic packets.
動機：ネットワークノードが、L4S ECNマーク動作を適用し、クラシックパケットのキューイング遅延からL4Sパケットを分離するキューにフロー状態のないL4Sパケットを分類することができる必要があります。
Description: The transport protocol for a Scalable congestion control needs to provide timely, accurate feedback about the extent of ECN marking experienced by all packets (see the precise normative requirement wording in Section 4.2).
説明：スケーラブルな混雑制御のための輸送プロトコルは、すべてのパケットが経験するECNマーキングの範囲についてタイムリーで正確なフィードバックを提供する必要があります（セクション4.2の正確な規範的要件の言葉遣いを参照）。
Motivation: Classic congestion controls only need feedback about the existence of a congestion episode within a round trip, not precisely how many packets were ECN-marked or dropped. Therefore, in 2001, when ECN feedback was added to TCP [RFC3168], it could not inform the sender of more than one ECN mark per RTT. Since then, requirements for more accurate ECN feedback in TCP have been defined in [RFC7560], and [ACCECN] specifies a change to the TCP protocol to satisfy these requirements. Most other transport protocols already satisfy this requirement (see Section 4.2).
動機：古典的な混雑コントロールでは、往復の中での混雑エピソードの存在に関するフィードバックのみが必要であり、正確にはECNマーク化またはドロップされたパケットの数ではありません。したがって、2001年にECNフィードバックがTCP [RFC3168]に追加されたとき、RTTごとに複数のECNマークを送信者に通知することはできませんでした。それ以来、TCPにおけるより正確なECNフィードバックの要件は[RFC7560]で定義されており、[accecn]はこれらの要件を満たすためにTCPプロトコルの変更を指定します。他のほとんどの輸送プロトコルはすでにこの要件を満たしています（セクション4.2を参照）。
Description: It needs to be possible to replace the implementation of a Scalable congestion control with a Classic control (see the precise normative requirement wording in Section 4.3, Paragraph 8, Item 1).
説明：スケーラブルな混雑制御の実装を古典的なコントロールに置き換えることができる必要があります（セクション4.3、パラグラフ8、アイテム1の正確な規範的要件の言葉遣いを参照）。
Motivation: L4S is an experimental protocol; therefore, it seems prudent to be able to disable it at source in case of insurmountable problems, perhaps due to some unexpected interaction on a particular sender; over a particular path or network; or with a particular receiver, or even ultimately an insurmountable problem with the experiment as a whole.
動機：L4Sは実験プロトコルです。したがって、おそらく特定の送信者との予期しない相互作用のために、克服できない問題が発生した場合に、ソースでそれを無効にすることができるのは賢明のようです。特定のパスまたはネットワーク上。または、特定のレシーバー、または最終的には実験全体の克服できない問題でさえあります。
Description: As well as responding to ECN markings in a scalable way, a Scalable congestion control needs to react to packet loss in a way that will coexist safely with a Reno congestion control [RFC5681] (see the precise normative requirement wording in Section 4.3, Paragraph 8, Item 2).
説明：ECNマーキングにスケーラブルな方法で応答するだけでなく、スケーラブルな輻輳制御は、リノの混雑制御[RFC5681]と安全に共存する方法でパケット損失に反応する必要があります（セクション4.3の正確な規範的要件の言葉遣いを参照してください。パラグラフ8、項目2）。
Motivation: Part of the safety conditions for deploying a Scalable congestion control on the public Internet is to make sure that it behaves properly when it builds a queue at a network bottleneck that has not been upgraded to support L4S. Packet loss can have many causes, but it usually has to be conservatively assumed that it is a sign of congestion. Therefore, on detecting packet loss, a Scalable congestion control will need to fall back to Classic congestion control behaviour. If it does not comply, it could starve Classic traffic.
動機：パブリックインターネットにスケーラブルな混雑制御を展開するための安全条件の一部は、L4Sをサポートするためにアップグレードされていないネットワークボトルネックでキューを構築するときに適切に動作することを確認することです。パケットの損失には多くの原因がありますが、通常は混雑の兆候であると控えめに想定する必要があります。したがって、パケットの損失を検出すると、スケーラブルな輻輳制御が古典的な混雑制御動作に戻る必要があります。従わない場合、古典的なトラフィックを飢えさせる可能性があります。
A Scalable congestion control can be used for different types of transport, e.g., for real-time media or for reliable transport like TCP. Therefore, the particular Classic congestion control behaviour to fall back on will need to be dependent on the specific congestion control implementation. In the particular case of DCTCP, the DCTCP specification [RFC8257] states that "A DCTCP sender MUST react to loss episodes in the same way as conventional TCP,...". To ensure any Scalable congestion control is safe to deploy over the public Internet, Item 2 of Section 4.3 in the present spec does not require precisely the same response as Reno TCP, but it does require a response that will coexist safely with Classic congestion controls like Reno.
スケーラブルな輻輳制御は、さまざまな種類の輸送に使用できます。たとえば、リアルタイムメディアやTCPのような信頼できる輸送に使用できます。したがって、後退する特定の古典的な混雑制御動作は、特定の輻輳制御の実装に依存する必要があります。DCTCPの特定のケースでは、DCTCP仕様[RFC8257]は、「DCTCP送信者は従来のTCPと同じ方法で損失エピソードに反応しなければならない」と述べています。スケーラブルな混雑制御がパブリックインターネット上に展開できることを確認するために、現在の仕様のセクション4.3の項目2では、Reno TCPとまったく同じ応答を必要としませんが、次のような古典的な混雑コントロールと安全に共存する応答が必要です。リノ。
Even though a bottleneck is L4S capable, it might still become overloaded and have to drop packets. In this case, the sender may receive a high proportion of packets marked with the CE codepoint and also experience loss. Current DCTCP implementations each react differently to this situation. One approach is to react only to the drop signal (e.g., by halving the cwnd); another approach is to react to both signals, which reduces cwnd by more than half. A compromise between these two has been proposed where the loss response is adjusted to result in a halving when combined with any ECN response earlier in the same round. We believe that further experimentation is needed to understand what is the best behaviour for the public Internet, which may or may not be one of these existing approaches.
ボトルネックはL4S対応ですが、それでも過負荷になり、パケットをドロップする必要がある場合があります。この場合、送信者は、CEコードポイントでマークされたパケットの大部分を受け取ることができ、損失も発生する場合があります。現在のDCTCP実装は、この状況とは異なる反応が異なります。1つのアプローチは、ドロップ信号のみに反応することです（たとえば、CWNDを半分にすることによって）。別のアプローチは、両方の信号に反応することであり、CWNDを半分以上削減します。これら2つの間の妥協案が提案されており、同じラウンドの早い段階でECN応答と組み合わせると、損失応答が調整されて半分になります。これらの既存のアプローチの1つである場合とそうでない場合があるパブリックインターネットにとって最良の行動を理解するには、さらなる実験が必要であると考えています。
Description: Monitoring has to be in place so that a non-L4S but ECN-capable AQM can be detected at path bottlenecks. This is in case such an AQM has been implemented in a shared queue, in which case any long-running Scalable flow would predominate over any simultaneous long-running Classic flow sharing the queue. The precise requirement wording in Section 4.3, Paragraph 8, Item 3 is written so that such a problem could be resolved either in real time or via administrative intervention.
説明：PATHボトルネックでは、非L4SがECN対応AQMを検出できるように、監視を整える必要があります。これは、そのようなAQMが共有キューに実装されている場合です。その場合、長期にわたるスケーラブルなフローは、キューを共有する同時長いクラシックフローよりも優勢になります。セクション4.3、パラグラフ8、アイテム3の正確な要件の文言は、そのような問題をリアルタイムまたは管理介入によって解決できるように書かれています。
Motivation: Similarly to the discussion in Appendix A.1.4, this requirement in Section 4.3 is a safety condition to ensure an L4S congestion control coexists well with Classic flows when it builds a queue at a shared network bottleneck that has not been upgraded to support L4S. Nonetheless, if necessary, it is considered reasonable to resolve such problems over management timescales (possibly involving human intervention) because:
動機：付録A.1.4の議論と同様に、セクション4.3のこの要件は、L4Sの混雑制御が、L4Sをサポートするためにアップグレードされていない共有ネットワークボトルネックでキューを構築するときに古典的なフローとうまく共存することを保証する安全条件です。。それにもかかわらず、必要に応じて、管理のタイムスケールよりもそのような問題を解決することは合理的であると考えられています（おそらく人間の介入を含む）。
* although a Classic flow can considerably reduce its throughput in the face of a competing Scalable flow, it still makes progress and does not starve;
* 古典的なフローは、競合するスケーラブルなフローに直面してスループットを大幅に減らすことができますが、それでも進歩し、飢えません。
* implementations of a Classic ECN AQM in a queue that is intended to be shared are believed to be rare; and
* 共有することを目的としたキュー内の古典的なECN AQMの実装は、まれであると考えられています。と
* detection of such AQMs is not always clear-cut; so focused out-of-band testing (or even contacting the relevant network operator) would improve certainty.
* このようなAQMSの検出は、必ずしもクリアカットではありません。そのため、焦点を絞った帯域外テスト（または関連するネットワークオペレーターに連絡することさえ）が確実性を改善するでしょう。
The relevant normative requirement (Section 4.3) is therefore divided into three stages: monitoring, detection, and action:
したがって、関連する規範的要件（セクション4.3）は、監視、検出、およびアクションの3つの段階に分けられます。
Monitoring: Monitoring involves collection of the measurement data to be analysed. Monitoring is expressed as a "MUST" for uncontrolled environments, although the placement of the monitoring function is left open. Whether monitoring has to be applied in real time is expressed as a "SHOULD". This allows for the possibility that the operator of an L4S sender (e.g., a Content Distribution Network (CDN)) might prefer to test out-of-band for signs of Classic ECN AQMs, perhaps to avoid continually consuming resources to monitor live traffic.
監視：監視には、分析する測定データの収集が含まれます。監視は、監視機能の配置は開いたままになっていますが、制御されていない環境の「必須」として表現されます。監視をリアルタイムで適用する必要があるかどうかは、「必要」として表現されます。これにより、L4S送信者のオペレーター（たとえば、コンテンツ配信ネットワーク（CDN））が、おそらくライブトラフィックを監視するためのリソースを継続的に消費することを避けるために、古典的なECN AQMの兆候について帯域外のテストを好む可能性があります。
Detection: Detection involves analysis of the monitored data to detect the likelihood of a Classic ECN AQM. Detection can either directly detect actual coexistence problems between flows or aim to identify AQM technologies that are likely to present coexistence problems, based on knowledge of AQMs deployed at the time. The requirements recommend that detection occurs live in real time. However, detection is allowed to be deferred (e.g., it might involve further testing targeted at candidate AQMs).
検出：検出には、監視されたデータの分析が含まれ、古典的なECN AQMの可能性を検出します。検出は、フロー間の実際の共存問題を直接検出するか、当時展開されていたAQMSの知識に基づいて、共存の問題を提示する可能性のあるAQMテクノロジーを特定することを目的とします。要件では、検出がリアルタイムで実現することを推奨しています。ただし、検出は延期されることが許可されています（たとえば、候補AQMSを対象とするさらなるテストが含まれる場合があります）。
Action: This involves the act of switching the sender to a Classic congestion control. This might occur in real time within the congestion control for the subsequent duration of a flow, or it might involve administrative action to switch to Classic congestion control for a specific interface or for a certain set of destination addresses.
アクション：これには、送信者を古典的な混雑制御に切り替える行為が含まれます。これは、その後のフローの期間中、混雑制御内でリアルタイムで発生する可能性があります。または、特定のインターフェイスまたは特定の一連の宛先アドレスの古典的な混雑制御に切り替えるための管理アクションが必要になる場合があります。
Instead of the sender taking action itself, the operator of the sender (e.g., a CDN) might prefer to ask the network operator to modify the Classic AQM's treatment of L4S packets; ensure L4S packets bypass the AQM; or upgrade the AQM to support L4S (see the L4S operational guidance [L4SOPS]). If L4S flows then no longer shared the Classic ECN AQM, they would obviously no longer detect it, and the requirement to act on it would no longer apply.
送信者がアクション自体を取得する代わりに、送信者のオペレーター（たとえば、CDN）は、ネットワークオペレーターにL4Sパケットの古典的なAQMの処理を変更するように依頼することを好むかもしれません。L4SパケットがAQMをバイパスすることを確認します。または、AQMをアップグレードしてL4Sをサポートします（L4S運用ガイダンス[L4SOPS]を参照）。L4SフローがクラシックECN AQMを共有しなくなった場合、それらは明らかにそれを検出しなくなり、それに基づいて行動する要件はもはや適用されません。
The whole set of normative requirements concerning Classic ECN AQMs in Section 4.3 is worded so that it does not apply in controlled environments, such as private networks or data-centre networks. CDN servers placed within an access ISP's network can be considered as a single controlled environment, but any onward networks served by the access network, including all the attached customer networks, would be unlikely to fall under the same degree of coordinated control. Monitoring is expressed as a "MUST" for these uncontrolled segments of paths (e.g., beyond the access ISP in a home network), because there is a possibility that there might be a shared queue Classic ECN AQM in that segment. Nonetheless, the intent of the wording is to only require occasional monitoring of these uncontrolled regions and not to burden CDN operators if monitoring never uncovers any potential problems.
セクション4.3の古典的なECN AQMに関する規範的要件のセット全体は、プライベートネットワークやデータセンターネットワークなどの制御された環境では適用されないように表現されています。Access ISPのネットワーク内に配置されたCDNサーバーは、単一の制御環境と見なすことができますが、Accessネットワークが提供するすべての添付の顧客ネットワークを含む以降のネットワークは、同じ程度の調整された制御に該当する可能性は低いでしょう。監視は、これらの制御されていないパスのセグメント（ホームネットワークのアクセスISPを超えて）の「必須」として表現されます。なぜなら、そのセグメントに共有キュークラシックECN AQMがある可能性があるからです。それにもかかわらず、文言の意図は、監視が潜在的な問題を明らかにしない場合、これらの制御されていない地域の時折監視を必要とすることであり、CDNオペレーターを負担しないことです。
More detailed discussion of all the above options and alternatives can be found in the L4S operational guidance [L4SOPS].
上記のすべてのオプションと代替案のより詳細な議論は、L4S運用ガイダンス[L4SOPS]に記載されています。
Having said all the above, the approach recommended in Section 4.3 is to monitor, detect, and act in real time on live traffic. A passive monitoring algorithm to detect a Classic ECN AQM at the bottleneck and fall back to Classic congestion control is described in an extensive technical report [ecn-fallback], which also provides a link to Linux source code and a large online visualization of its evaluation results. Very briefly, the algorithm primarily monitors RTT variation using the same algorithm that maintains the mean deviation of TCP's smoothed RTT, but it smooths over a duration of the order of a Classic sawtooth. The outcome is also conditioned on other metrics such as the presence of CE marking and congestion avoidance phase having stabilized. The report also identifies further work to improve the approach, for instance, improvements with low-capacity links and combining the measurements with a cache of what had been learned about a path in previous connections. The report also suggests alternative approaches.
上記のすべてを言った後、セクション4.3で推奨されるアプローチは、ライブトラフィックを監視、検出、およびリアルタイムで行動することです。ボトルネックで古典的なECN AQMを検出し、古典的な混雑制御に戻るパッシブ監視アルゴリズムは、広範なテクニカルレポート[ECN-Fallback]で説明されています。これは、Linuxソースコードへのリンクとその評価の大規模なオンライン視覚化も提供します結果。非常に簡単に言えば、アルゴリズムは主に、TCPの平滑化されたRTTの平均偏差を維持するのと同じアルゴリズムを使用してRTTの変動を監視しますが、古典的なノコギリの順序の期間にわたって滑らかになります。結果は、CEマーキングの存在や混雑回避段階の存在など、他のメトリックも安定しています。また、このレポートは、アプローチを改善するためのさらなる作業を特定しています。たとえば、低容量リンクによる改善、測定値を以前の接続でパスについて学んだことのキャッシュと組み合わせます。レポートはまた、代替アプローチを提案しています。
Although using passive measurements within live traffic (as above) can detect a Classic ECN AQM, it is much harder (perhaps impossible) to determine whether or not the AQM is in a shared queue. Nonetheless, this is much easier using active test traffic out-of-band because two flows can be used. Section 4 of the same report [ecn-fallback] describes a simple technique to detect a Classic ECN AQM and determine whether it is in a shared queue, which is summarized here.
ライブトラフィック内で（上記のように）パッシブ測定を使用すると、古典的なECN AQMを検出できますが、AQMが共有キューにあるかどうかを判断するのははるかに難しい（おそらく不可能）。それにもかかわらず、これは2つのフローを使用できるため、アクティブなテストトラフィックを使用してはるかに簡単です。同じレポート[ECN-Fallback]のセクション4では、古典的なECN AQMを検出し、共有キューにあるかどうかを判断する簡単な手法について説明します。これはここにまとめられています。
An L4S-enabled test server could be set up so that, when a test client accesses it, it serves a script that gets the client to open two parallel long-running flows. It could serve one with a Classic congestion control (C, that sets ECT(0)) and one with a Scalable CC (L, that sets ECT(1)). If neither flow induces any ECN marks, it can be presumed that the path does not contain a Classic ECN AQM. If either flow induces some ECN marks, the server could measure the relative flow rates and round-trip times of the two flows. Table 2 shows the AQM that can be inferred for various cases (presuming no more types of AQM behaviour than those known at the time of writing).
L4S対応のテストサーバーをセットアップできるように、テストクライアントがアクセスすると、クライアントに2つの並行した長期的なフローを開くようにするスクリプトを提供できます。古典的な混雑制御（C、ECT（0）を設定するC）、スケーラブルCC（L、ECT（1）を設定）を備えたものを備えたものを提供できます。どちらのフローもECNマークを誘導しない場合、パスには古典的なECN AQMが含まれていないと推定できます。いずれかのフローがいくつかのECNマークを誘導する場合、サーバーは2つのフローの相対流量と往復時間を測定できます。表2は、さまざまなケースで推測できるAQMを示しています（執筆時点で既知の場合よりもAQMの動作がこれ以上ないと仮定します）。
+========+=======+========================+
| Rate | RTT | Inferred AQM |
+========+=======+========================+
| L > C | L = C | Classic ECN AQM (FIFO) |
+--------+-------+------------------------+
| L = C | L = C | Classic ECN AQM (FQ) |
+--------+-------+------------------------+
| L = C | L < C | FQ-L4S AQM |
+--------+-------+------------------------+
| L ~= C | L < C | DualQ Coupled AQM |
+========+=======+========================+
| L = L4S; C = Classic |
+=========================================+
Table 2: Out-of-Band Testing with Two Parallel Flows
表2：2つの並列フローを備えたバンド外テスト
Finally, we motivate the recommendation in Section 4.3 that a Scalable congestion control is not expected to change to setting ECT(0) while it adapts its behaviour to coexist with Classic flows. This is because the sender needs to continue to check whether it made the right decision and switch back if it was wrong, or if a different link becomes the bottleneck:
最後に、セクション4.3の推奨事項を動機付けています。スケーラブルな輻輳制御は、ECT（0）の設定に変更されないと予想され、その動作は古典的なフローと共存するように適応します。これは、送信者が適切な決定を下し、間違っている場合、または別のリンクがボトルネックになるかどうかを確認し続ける必要があるためです。
* If, as recommended, the sender changes only its behaviour but not its codepoint to Classic, its codepoint will still be compatible with either an L4S or a Classic AQM. If the bottleneck does actually support both, it will still classify ECT(1) into the same L4S queue, where the sender can measure that switching to Classic behaviour was wrong so that it can switch back.
* 推奨されているように、送信者がその動作のみを変更したが、そのコードポイントをクラシックに変更しない場合、そのコードポイントは依然としてL4SまたはクラシックAQMと互換性があります。ボトルネックが実際に両方をサポートしている場合でも、ECT（1）を同じL4Sキューに分類します。この場合、送信者はクラシックな動作への切り替えが間違っているため、バックバックできるようにします。
* In contrast, if the sender changes both its behaviour and its codepoint to Classic, even if the bottleneck supports both, it will classify ECT(0) into the Classic queue, reinforcing the sender's incorrect decision so that it never switches back.
* 対照的に、送信者が動作とコードポイントの両方をクラシックに変更した場合、ボトルネックが両方をサポートしていても、ECT（0）をクラシックキューに分類し、送信者の誤った決定を強化して戻ってこないようにします。
* Also, not changing its codepoint avoids the risk of being flipped to a different path by a load balancer or multipath routing that hashes on the whole of the former Type-of-Service (ToS) byte (which is unfortunately still a common pathology).
* また、CodePointを変更しないと、以前のサービスタイプ（TOS）バイト全体をハッシュするロードバランサーまたはマルチパスルーティングによって異なるパスに反転するリスクが回避されます（残念ながら、まだ一般的な病理です）。
Note that if a flow is configured to _only_ use a Classic congestion control, it is then entirely appropriate not to use ECT(1).
フローが_only_に設定されている場合、古典的な輻輳制御を使用するようにすると、ECT（1）を使用しないことが完全に適切であることに注意してください。
Description: A Scalable congestion control needs to reduce RTT bias as much as possible at least over the low-to-typical range of RTTs that will interact in the intended deployment scenario (see the precise normative requirement wording in Section 4.3, Paragraph 8, Item 4).
説明：スケーラブルな混雑制御は、意図した展開シナリオで相互作用するRTTの低い範囲から典型的な低範囲のRTTバイアスをできるだけ減らす必要があります（セクション4.3、パラグラフ8、アイテムの正確な規範的要件の言葉遣いを参照してください。4）。
Motivation: The throughput of Classic congestion controls is known to be inversely proportional to RTT, so one would expect flows over very low RTT paths to nearly starve flows over larger RTTs. However, Classic congestion controls have never allowed a very low RTT path to exist because they induce a large queue. For instance, consider two paths with base RTT 1 ms and 100 ms. If a Classic congestion control induces a 100 ms queue, it turns these RTTs into 101 ms and 200 ms, leading to a throughput ratio of about 2:1. Whereas if a Scalable congestion control induces only a 1 ms queue, the ratio is 2:101, leading to a throughput ratio of about 50:1.
動機：古典的な混雑コントロールのスループットはRTTに反比例することが知られているため、RTTパスが非常に低いRTTの流れは、より大きなRTTを介してほぼ飢えていると予想されます。ただし、古典的な混雑コントロールは、大きなキューを誘導するため、非常に低いRTTパスが存在することはありませんでした。たとえば、ベースRTT 1ミリ秒と100ミリ秒の2つのパスを検討してください。古典的な混雑制御が100ミリ秒のキューを誘導すると、これらのRTTを101 msと200 msに変え、スループット比は約2：1になります。一方、スケーラブルな混雑制御が1 msのキューのみを誘導する場合、比率は2：101であり、スループット比は約50：1になります。
Therefore, with very small queues, long RTT flows will essentially starve, unless Scalable congestion controls comply with the requirement in Section 4.3.
したがって、非常に小さなキューでは、スケーラブルな輻輳制御がセクション4.3の要件に準拠していない限り、長いRTTフローが本質的に飢えます。
Over higher than typical RTTs, L4S flows can use the same RTT bias as in current Classic congestion controls and still work satisfactorily. So there is no additional requirement in Section 4.3 for high RTT L4S flows to remove RTT bias -- they can, but they don't have to.
典型的なRTTよりも高いほど、L4Sフローは、現在の古典的な混雑コントロールと同じRTTバイアスを使用でき、それでも十分に機能します。したがって、RTTバイアスを除去するための高いRTT L4Sフローのセクション4.3には追加の要件はありませんが、できますが、必要はありません。
One way for a Scalable congestion control to satisfy these requirements is to make its additive increase behave as if it were a standard Reno flow but over a larger RTT by using a virtual RTT (rtt_virt) that is a function of the actual RTT (rtt). Example functions might be:
これらの要件を満たすためのスケーラブルな輻輳制御の1つの方法は、標準的なリノフローであるかのように加法の増加を動作させることですが、実際のRTT（RTT）の関数である仮想RTT（RTT_VIRT）を使用することにより、より大きなRTTを超えることです。。機能の例は次のとおりです。
rtt_virt = max(rtt, 25 ms)
rtt_virt = max（rtt、25 ms）
rtt_virt = rtt + 10 ms
rtt_virt = rtt 10 ms
These example functions are chosen so that, as the actual RTT reduces from high to low, the virtual RTT reduces less (see [PRAGUE-CC] for details).
これらの例関数は、実際のRTTが高から低くなると、仮想RTTの減少を減らすように選択されます（詳細については[Prague-CC]を参照）。
However, short RTT flows can more rapidly respond to changes in available capacity, whether due to other flows arriving and departing or radio capacity varying. So it would be wrong to require short RTT flows to be as sluggish as long RTT flows, which would unnecessarily underutilize capacity and result in unnecessary overshoots and undershoots (instability). Therefore, rather than requiring strict RTT independence, the wording in Item 4 of Section 4.3 is "as independent of RTT as possible without compromising stability or utilization". This allows shorter RTT flows to exploit their agility advantage.
ただし、短いRTTフローは、他のフローが到着して出発するか、無線容量がさまざまであるかどうかにかかわらず、利用可能な容量の変化により迅速に応答する可能性があります。したがって、短いRTTフローが長いRTTフローと同じくらい遅くなるように要求することは間違っているでしょう。したがって、厳格なRTT独立性を要求するのではなく、セクション4.3の項目4の文言は、「安定性や利用を損なうことなく、可能な限りRTTに依存しない」ことです。これにより、より短いRTTフローが敏ility性の優位性を活用することができます。
Description: A Scalable congestion control needs to remain responsive to congestion when typical RTTs over the public Internet are significantly smaller because they are no longer inflated by queuing delay (see the precise normative requirement wording in Section 4.3, Paragraph 8, Item 5).
説明：スケーラブルな混雑制御は、公共インターネット上の典型的なRTTがキューイングの遅延によって膨らまないため、渋滞に応答する必要があります（セクション4.3、パラグラフ8、アイテム5の正確な規範的要件の言葉遣いを参照）。
Motivation: As currently specified, the minimum congestion window of ECN-capable TCP (and its derivatives) is expected to be 2 sender maximum segment sizes (SMSS), or 1 SMSS after a retransmission timeout. Once the congestion window reaches this minimum, if there is further ECN marking, TCP is meant to wait for a retransmission timeout before sending another segment (see Section 6.1.2 of the ECN spec [RFC3168]). In practice, most known window-based congestion control algorithms become unresponsive to ECN congestion signals at this point. No matter how much ECN marking, the congestion window no longer reduces. Instead, the sender's lack of any further congestion response forces the queue to grow, overriding any AQM and increasing queuing delay (making the window large enough to become responsive again). This can result in a stable but deeper queue, or it might drive the queue to loss, in which case the retransmission timeout mechanism acts as a backstop.
動機：現在指定されているように、ECN対応TCP（およびその誘導体）の最小輻輳ウィンドウは、再送信タイムアウト後の2つの送信者の最大セグメントサイズ（SMS）、または1つのSMSになると予想されます。輻輳ウィンドウがこの最小限に達すると、さらにECNマーキングがある場合、TCPは別のセグメントを送信する前に再送信タイムアウトを待つことを目的としています（ECN仕様のセクション6.1.2 [RFC3168]を参照）。実際には、ほとんどの既知のウィンドウベースの輻輳制御アルゴリズムは、この時点でECN混雑信号に反応しません。どれだけのECNマーキングであっても、混雑ウィンドウはもはや減少しません。代わりに、送信者がさらなる混雑反応がないため、キューが成長し、AQMをオーバーライドし、キューイングの遅延を増加させます（ウィンドウを再び応答するほど大きくします）。これにより、安定しているがより深いキューが発生する可能性があります。または、キューを損失に誘導する可能性があります。その場合、再送信タイムアウトメカニズムはバックストップとして機能します。
Most window-based congestion controls for other transport protocols have a similar minimum window, albeit when measured in bytes for those that use smaller packets.
他の輸送プロトコルのほとんどのウィンドウベースの混雑コントロールは、小さなパケットを使用するバイトでバイトで測定する場合は同様の最小ウィンドウを持っています。
L4S mechanisms significantly reduce queuing delay so, over the same path, the RTT becomes lower. Then, this problem becomes surprisingly common [sub-mss-prob]. This is because, for the same link capacity, smaller RTT implies a smaller window. For instance, consider a residential setting with an upstream broadband Internet access of 8 Mb/s, assuming a max segment size of 1500 B. Two upstream flows will each have the minimum window of 2 SMSS if the RTT is 6 ms or less, which is quite common when accessing a nearby data centre. So any more than two such parallel TCP flows will become unresponsive to ECN and increase queuing delay.
L4Sメカニズムはキューイング遅延を大幅に減らすため、同じ経路でRTTが低くなります。次に、この問題は驚くほど一般的になります[Sub-MSS-Prob]。これは、同じリンク容量の場合、より小さなRTTがより小さなウィンドウを意味するためです。たとえば、最大セグメントサイズの1500 Bを仮定して、8 MB/sの上流のブロードバンドインターネットアクセスを備えた住宅設定を検討してください。2つの上流のフローは、RTTが6ミリ秒以下の場合、それぞれ2つのSMSの最小ウィンドウがあります。近くのデータセンターにアクセスする場合、非常に一般的です。したがって、2つ以上の並列TCPフローがECNに反応しなくなり、キューイングの遅延が増加します。
Unless Scalable congestion controls address the requirement in Section 4.3 from the start, they will frequently become unresponsive to ECN, negating the low-latency benefit of L4S, for themselves and for others.
スケーラブルな輻輳制御が最初からセクション4.3の要件に対処しない限り、それらは頻繁にECNに反応しなくなり、L4の低下の利点、それ自体、および他の人にとっては無効になります。
That would seem to imply that Scalable congestion controllers ought to be required to be able work with a congestion window less than 1 SMSS. For instance, if an ECN-capable TCP gets an ECN mark when it is already sitting at a window of 1 SMSS, [RFC3168] requires it to defer sending for a retransmission timeout. A less drastic but more complex mechanism can maintain a congestion window less than 1 SMSS (significantly less if necessary), as described in [Ahmed19]. Other approaches are likely to be feasible.
それは、スケーラブルな混雑コントローラーが、1つのSMSS未満の輻輳ウィンドウで作業できるようにする必要があることを意味するように思われます。たとえば、ECN対応のTCPがすでに1つのSMSSのウィンドウに座っているときにECNマークを取得する場合、[RFC3168]は、再送信タイムアウトの送信を延期する必要があります。[AHMED19]に記載されているように、劇的ではないが複雑なメカニズムは、1つのSMSS未満（必要に応じて大幅に少ない）未満の混雑ウィンドウを維持できます。他のアプローチは実現可能である可能性があります。
However, the requirement in Section 4.3 is worded as a "SHOULD" because it is believed that the existence of a minimum window is not all bad. When competing with an unresponsive flow, a minimum window naturally protects the flow from starvation by at least keeping some data flowing.
ただし、セクション4.3の要件は、最小のウィンドウの存在がすべて悪いとは限らないと考えられているため、「必要な」と表現されています。反応しない流れと競合する場合、最小限の窓は、少なくともいくつかのデータを流し続けることにより、飢starからの流れを自然に保護します。
By stating the requirement to go lower than 1 SMSS as a "SHOULD", while the requirement in [RFC3168] still stands as well, we shall be able to watch the choices of minimum window evolve in different Scalable congestion controllers.
[rfc3168]の要件も依然として「必要」として1つ未満のSMSSを下げるという要件を述べることにより、さまざまなスケーラブルな輻輳コントローラーで最小窓の選択が進化するのを見ることができます。
Description: When detecting loss, a Scalable congestion control needs to be tolerant to reordering over an adaptive time interval, which scales with throughput, rather than counting only in fixed units of packets, which does not scale (see the precise normative requirement wording in Section 4.3, Paragraph 8, Item 6).
説明：損失を検出する場合、スケーラブルな混雑制御は、固定されたパケット単位のみでカウントするのではなく、スループットでスケーリングする適応時間間隔での並べ替えに寛容である必要があります（セクションの正確な規範的要件の言葉遣いを参照してください4.3、パラグラフ8、項目6）。
Motivation: A primary purpose of L4S is scalable throughput (it's in the name). Scalability in all dimensions is, of course, also a goal of all IETF technology. The inverse linear congestion response in Section 4.3 is necessary, but not sufficient, to solve the congestion control scalability problem identified in [RFC3649]. As well as maintaining frequent ECN signals as rate scales, it is also important to ensure that a potentially false perception of loss does not limit throughput scaling.
動機：L4Sの主な目的は、スケーラブルなスループットです（名前にあります）。すべての次元でのスケーラビリティは、もちろん、すべてのIETFテクノロジーの目標でもあります。セクション4.3の逆線形鬱血応答は、[RFC3649]で特定された輻輳制御スケーラビリティの問題を解決するために必要ではありませんが、十分ではありません。頻繁なECNシグナルをレートスケールとして維持するだけでなく、損失の潜在的に誤った認識がスループットスケーリングを制限しないことを確認することも重要です。
End systems cannot know whether a missing packet is due to loss or reordering, except in hindsight -- if it appears later. So they can only deem that there has been a loss if a gap in the sequence space has not been filled, either after a certain number of subsequent packets has arrived (e.g., the 3 DupACK rule of standard TCP congestion control [RFC5681]) or after a certain amount of time (e.g., the RACK approach [RFC8985]).
End Systemsは、後に表示される場合を除き、欠落しているパケットが損失または並べ替えによるものかどうかを知ることができません。そのため、特定の数の後続のパケットが到着した後、シーケンススペースのギャップが埋められていない場合にのみ損失があったと考えることができます（たとえば、標準TCP混雑制御の3つのデュパックルール[RFC5681]）または一定の時間の後（例：ラックアプローチ[RFC8985]）。
As we attempt to scale packet rate over the years:
長年にわたってパケットレートをスケーリングしようとするとき：
* Even if only _some_ sending hosts still deem that loss has occurred by counting reordered packets, _all_ networks will have to keep reducing the time over which they keep packets in order. If some link technologies keep the time within which reordering occurs roughly unchanged, then loss over these links, as perceived by these hosts, will appear to continually rise over the years.
* _ some_の送信ホストのみが、並べ替えられたパケットをカウントすることで損失が発生しているとみなしている場合でも、_all_ネットワークはパケットを整頓する時間を短縮し続ける必要があります。一部のリンクテクノロジーが、並べ替えがほぼ変化しない時間を維持している場合、これらのホストが知覚するように、これらのリンクに対する損失は、長年にわたって継続的に上昇するように見えます。
* In contrast, if all senders detect loss in units of time, the time over which the network has to keep packets in order stays roughly invariant.
* 対照的に、すべての送信者が時間単位の損失を検出した場合、ネットワークがパケットを維持しなければならない時間は、ほとんど不変のままです。
Therefore, hosts have an incentive to detect loss in time units (so as not to fool themselves too often into detecting losses when there are none). And for hosts that are changing their congestion control implementation to L4S, there is no downside to including time-based loss detection code in the change (loss recovery implemented in hardware is an exception, which is covered later). Therefore, requiring L4S hosts to detect loss in time-based units would not be a burden.
したがって、ホストには、時間単位の損失を検出するインセンティブがあります（頻繁に自分自身をだまさないように、何もない場合に損失を検出しないように）。また、混雑制御の実装をL4に変更しているホストの場合、変更に時間ベースの損失検出コードを含めるという欠点はありません（ハードウェアに実装された損失回復は例外であり、後でカバーされます）。したがって、時間ベースのユニットの損失を検出するためにL4Sホストを要求することは負担ではありません。
If the requirement in Section 4.3 were not placed on L4S hosts, even though it would be no burden on hosts to comply, all networks would face unnecessary uncertainty over whether some L4S hosts might be detecting loss by counting packets. Then, _all_ link technologies would have to unnecessarily keep reducing the time within which reordering occurs. That is not a problem for some link technologies, but it becomes increasingly challenging for other link technologies to continue to scale, particularly those relying on channel bonding for scaling, such as LTE, 5G, and Data Over Cable Service Interface Specification (DOCSIS).
セクション4.3の要件がL4Sホストに配置されていない場合、それはホストに準拠する負担ではないにもかかわらず、すべてのネットワークは、一部のL4Sホストがパケットをカウントすることで損失を検出しているかどうかについて不必要な不確実性に直面するでしょう。その後、_all_リンクテクノロジーは、並べ替えが発生する時間を不必要に短縮する必要があります。これは一部のリンクテクノロジーにとっては問題ではありませんが、他のリンクテクノロジーがスケーリングを続けることがますます困難になります。特に、LTE、5G、ケーブルサービスインターフェイス仕様（DOCSIS）のデータなどのスケーリングのためにチャネル結合に依存するものです。
Given Internet paths traverse many link technologies, any scaling limit for these more challenging access link technologies would become a scaling limit for the Internet as a whole.
インターネットパスが多くのリンクテクノロジーを横断することを考えると、これらのより挑戦的なアクセスリンクテクノロジーのスケーリング制限は、インターネット全体のスケーリング制限になります。
It might be asked how it helps to place this loss detection requirement only on L4S hosts, because networks will still face uncertainty over whether non-L4S flows are detecting loss by counting DupACKs. The answer is that those link technologies for which it is challenging to keep squeezing the reordering time will only need to do so for non-L4S traffic (which they can do because the L4S identifier is visible at the IP layer). Therefore, they can focus their processing and memory resources into scaling non-L4S (Classic) traffic. Then, the higher the proportion of L4S traffic, the less of a scaling challenge they will have.
ネットワークは、Dupackをカウントすることで非L4Sフローが損失を検出しているかどうかについてネットワークが依然として不確実性に直面するため、この損失検出要件をL4Sホストにのみ配置するのにどのように役立つかを尋ねられるかもしれません。答えは、並べ替え時間を絞り続けることが困難なリンクテクノロジーは、非L4Sトラフィックに対してのみ行う必要があるということです（L4S識別子がIPレイヤーで表示されるため、これができる）。したがって、彼らは処理とメモリリソースをスケーリング以外の非L4（クラシック）トラフィックに集中させることができます。その後、L4Sトラフィックの割合が高いほど、スケーリングの課題は少なくなります。
To summarize, there is no reason for L4S hosts not to be part of the solution instead of part of the problem.
要約すると、L4Sホストが問題の一部ではなくソリューションの一部ではない理由はありません。
Requirement ("MUST") or recommendation ("SHOULD")? As explained above, this is a subtle interoperability issue between hosts and networks, which seems to need a "MUST". Unless networks can be certain that all L4S hosts follow the time-based approach, they still have to cater for the worst case -- continually squeeze reordering into a smaller and smaller duration -- just for hosts that might be using the counting approach. However, it was decided to express this as a recommendation, using "SHOULD". The main justification was that networks can still be fairly certain that L4S hosts will follow this recommendation, because following it offers only gain and no pain.
要件（「必須」）または推奨事項（「必要」）？上で説明したように、これはホストとネットワークの間の微妙な相互運用性の問題であり、「必須」が必要と思われます。ネットワークは、すべてのL4ホストが時間ベースのアプローチに従うことを確信できない限り、最悪の場合に対応する必要があります - カウントアプローチを使用している可能性のあるホストのためだけに、並み並みを小さくて小さくします。ただし、これを「Suff」を使用して推奨として表現することが決定されました。主な正当性は、ネットワークがL4Sホストがこの推奨事項に従うことをかなり確実にすることができるということでした。
Details:
詳細：
The time spent recovering a loss is much more significant for short flows than long; therefore, a good compromise is to adapt the reordering window from a small fraction of the RTT at the start of a flow to a larger fraction of the RTT for flows that continue for many round trips.
損失を回復するのに費やす時間は、長いフローよりもはるかに重要です。したがって、良い妥協点は、フローの開始時のRTTのごく一部から、多くのラウンド旅行で続くフローのRTTの大部分に並べ替えるウィンドウを適応させることです。
This is broadly the approach adopted by RACK [RFC8985]. However, RACK starts with the 3 DupACK approach, because the RTT estimate is not necessarily stable. As long as the initial window is paced, such initial use of 3 DupACK counting would amount to time-based loss detection and therefore would satisfy the time-based loss detection recommendation of Section 4.3. This is because pacing of the initial window would ensure that 3 DupACKs early in the connection would be spread over a small fraction of the round trip.
これは、ラック[RFC8985]によって採用されるアプローチです。ただし、RTTの推定値が必ずしも安定していないため、ラックは3 Dupackアプローチから始まります。最初のウィンドウがペースを合わせている限り、3デュパックカウントのこのような初期使用は、時間ベースの損失検出に相当し、したがって、セクション4.3の時間ベースの損失検出推奨を満たします。これは、最初のウィンドウのペーシングにより、接続の早い段階で3つのデュパックが往復のごく一部に広がることを保証するためです。
As mentioned above, hardware implementations of loss recovery using DupACK counting exist (e.g., some implementations of Remote Direct Memory Access over Converged Ethernet version 2 (RoCEv2)). For low latency, these implementations can change their congestion control to implement L4S, because the congestion control (as distinct from loss recovery) is implemented in software. But they cannot easily satisfy this loss recovery requirement. However, it is believed they do not need to, because such implementations are believed to solely exist in controlled environments, where the network technology keeps reordering extremely low anyway. This is why controlled environments with hardly any reordering are excluded from the scope of the normative recommendation in Section 4.3.
上記のように、Dupackカウントを使用した損失回復のハードウェア実装が存在します（たとえば、収束したイーサネットバージョン2（ROCEV2）上のリモート直接メモリアクセスのいくつかの実装）。低遅延の場合、これらの実装は、輻輳制御がL4を実装するように変更してL4を実装する可能性があります。しかし、彼らはこの損失回収要件を簡単に満たすことはできません。ただし、そのような実装は、とにかくネットワークテクノロジーが非常に低い並べ替えを続けている制御された環境にのみ存在すると考えられているため、必要ではないと考えられています。これが、セクション4.3の規範的推奨の範囲から、並べ替えがほとんどない制御された環境が除外される理由です。
Detecting loss in time units also prevents the ACK-splitting attacks described in [Savage-TCP].
時間単位の損失を検出すると、[Savage-TCP]に記載されているACK分割攻撃も防ぎます。
Description: This item concerns TCP and its derivatives (e.g., SCTP) as well as RTP/RTCP [RFC6679]. The original specification of ECN for TCP precluded the use of ECN on control packets and retransmissions. Similarly, [RFC6679] precludes the use of ECT on RTCP datagrams, in case the path changes after it has been checked for ECN traversal. To improve performance, Scalable transport protocols ought to enable ECN at the IP layer in TCP control packets (SYN, SYN-ACK, pure ACKs, etc.) and in retransmitted packets. The same is true for other transports, e.g., SCTP and RTCP.
説明：この項目は、TCPとその誘導体（SCTPなど）、およびRTP/RTCP [RFC6679]に関するものです。TCPのECNの元の仕様により、制御パケットと再送信でのECNの使用が妨げられました。同様に、[RFC6679]は、ECNトラバーサルのチェック後にパスが変化した場合に備えて、RTCPデータグラムでのECTの使用を妨げます。パフォーマンスを向上させるために、スケーラブルなトランスポートプロトコルは、TCP制御パケット（Syn、Syn-ack、純粋なアクックなど）および再送信パケットのIPレイヤーでECNを有効にする必要があります。同じことが他のトランスポート、例えばSCTPやRTCPにも当てはまります。
Motivation (TCP): [RFC3168] prohibits the use of ECN on these types of TCP packets, based on a number of arguments. This means these packets are not protected from congestion loss by ECN, which considerably harms performance, particularly for short flows. ECN++ [ECN++] proposes experimental use of ECN on all types of TCP packets as long as AccECN feedback [ACCECN] is available (which itself satisfies the accurate feedback requirement in Section 4.2 for using a Scalable congestion control).
動機（TCP）：[RFC3168]は、多くの引数に基づいて、これらのタイプのTCPパケットでのECNの使用を禁止しています。これは、これらのパケットがECNによる混雑損失から保護されていないことを意味します。これは、特に短いフローの場合、パフォーマンスをかなり害します。ECN [ECN]は、ACCECNフィードバック[ACCECN]が利用可能になっている限り、あらゆるタイプのTCPパケットでECNの実験的使用を提案しています（スケーラブルな輻輳制御を使用するためにセクション4.2の正確なフィードバック要件を満たします）。
Motivation (RTCP): L4S experiments in general will need to observe the rule in the RTP ECN spec [RFC6679] that precludes ECT on RTCP datagrams. Nonetheless, as ECN usage becomes more widespread, it would be useful to conduct specific experiments with ECN-capable RTCP to gather data on whether such caution is necessary.
モチベーション（RTCP）：一般にL4S実験は、RTCPデータグラムのECTを排除するRTP ECN仕様[RFC6679]でルールを観察する必要があります。それにもかかわらず、ECNの使用がより広くなると、ECN対応RTCPを使用して特定の実験を実施して、そのような注意が必要かどうかに関するデータを収集することは有用です。
Description: It would improve performance if Scalable congestion controls did not limit their congestion window increase to the standard additive increase of 1 SMSS per round trip [RFC5681] during congestion avoidance. The same is true for derivatives of TCP congestion control, including similar approaches used for real-time media.
説明：スケーラブルな輻輳制御が、混雑回避中に往復あたりの1つのSMSS [RFC5681]の標準添加剤の増加に輻輳ウィンドウの増加を制限しなかった場合、パフォーマンスを改善します。同じことが、リアルタイムメディアに使用される同様のアプローチを含む、TCP混雑制御の誘導体にも当てはまります。
Motivation: As currently defined [RFC8257], DCTCP uses the conventional Reno additive increase in the congestion avoidance phase. When the available capacity suddenly increases (e.g., when another flow finishes or if radio capacity increases) it can take very many round trips to take advantage of the new capacity. TCP CUBIC [RFC8312] was designed to solve this problem, but as flow rates have continued to increase, the delay accelerating into available capacity has become prohibitive. See, for instance, the examples in Section 5.1 of the L4S architecture [RFC9330]. Even when out of its Reno-friendly mode, every 8 times scaling of CUBIC's flow rate leads to 2 times more acceleration delay.
モチベーション：現在定義されている[RFC8257]と、DCTCPは輻輳回避段階で従来のリノ添加剤の増加を使用しています。利用可能な容量が突然増加すると（たとえば、別のフローが終了したとき、または無線容量が増加する場合）、新しい容量を活用するには非常に多くの往復旅行が必要になります。TCP Cubic [RFC8312]はこの問題を解決するように設計されていましたが、流量が増加し続けるにつれて、利用可能な容量に加速する遅延が法外になりました。たとえば、L4Sアーキテクチャのセクション5.1の例[RFC9330]を参照してください。リノにやさしいモードがない場合でも、8倍のスケーリングをCubicの流量をスケーリングすると、2倍の加速遅延が発生します。
In the steady state, DCTCP induces about 2 ECN marks per round trip, so it is possible to quickly detect when these signals have disappeared and seek available capacity more rapidly, while minimizing the impact on other flows (Classic and Scalable) [LinuxPacedChirping]. Alternatively, approaches such as Adaptive-Acceleration Data Center TCP (A2DTCP) [A2DTCP]) have been proposed to address this problem in data centres, which might be deployable over the public Internet.
定常状態では、DCTCPは往復あたり約2つのECNマークを誘導するため、他のフロー（クラシックおよびスケーラブル）[LinuxPacedChirping]への影響を最小限に抑えながら、これらの信号がいつ消え、利用可能な容量をより迅速に検出することができます。あるいは、適応アクセラレーションデータセンターTCP（A2DTCP）[A2DTCP]）などのアプローチが、この問題に対処するために提案されています。
Description: It would improve performance if Scalable congestion controls converged (reached their steady-state share of the capacity) faster than Classic congestion controls or at least no slower. This affects the flow start behaviour of any L4S congestion control derived from a Classic transport that uses TCP slow start, including those for real-time media.
説明：スケーラブルな混雑コントロールが、古典的な混雑コントロールよりも速く収束した場合（容量の定常状態のシェアに達した）、または少なくとも遅い場合はパフォーマンスを改善します。これは、リアルタイムメディアを含むTCPスロースタートを使用する古典的なトランスポートから導出されたL4S混雑制御のフロースタート動作に影響します。
Motivation: As an example, a new DCTCP flow takes longer than a Classic congestion control to obtain its share of the capacity of the bottleneck when there are already ongoing flows using the bottleneck capacity. In a data-centre environment, DCTCP takes about 1.5 to 2 times longer to converge due to the much higher typical level of ECN marking that DCTCP background traffic induces, which causes new flows to exit slow start early [Alizadeh-stability]. In testing for use over the public Internet, the convergence time of DCTCP relative to a regular loss-based TCP slow start is even less favourable [LinuxPacedChirping] due to the shallow ECN-marking threshold needed for L4S. It is exacerbated by the typically greater mismatch between the link rate of the sending host and typical Internet access bottlenecks. This problem is detrimental in general but would particularly harm the performance of short flows relative to Classic congestion controls.
モチベーション：例として、新しいDCTCPフローは、ボトルネック容量を使用してすでに進行中のフローがある場合、ボトルネックの容量のシェアを得るために、古典的な混雑制御よりも長くかかります。データセンター環境では、DCTCPのバックグラウンドトラフィックが誘導するECNマークのはるかに高いレベルのECNマークのために、DCTCPは収束に約1.5〜2倍長くなり、新しいフローが早期に開始されるようになります[Alizadeh安定性]。パブリックインターネットで使用するためのテストでは、L4Sに必要な浅いECNマークのしきい値により、通常の損失ベースのTCPスロースタートと比較してDCTCPの収束時間はさらに有利ではありません[LinuxPacedChirping]。これは、送信ホストのリンクレートと典型的なインターネットアクセスボトルネックの間の通常の大きな不一致によって悪化します。この問題は一般的に有害ですが、特に古典的なうっ血コントロールと比較して短い流れのパフォーマンスに害を及ぼすでしょう。
This appendix is informative, not normative. As explained in Section 3, there is insufficient space in the IP header (v4 or v6) to fully accommodate every requirement. So the choice of L4S identifier involves trade-offs. This appendix records the pros and cons of the choice that was made.
この付録は有益であり、規範的ではありません。セクション3で説明したように、すべての要件に完全に対応するには、IPヘッダー（V4またはV6）に不十分なスペースがあります。したがって、L4S識別子の選択にはトレードオフが含まれます。この付録は、作成された選択の長所と短所を記録します。
Non-normative recap of the chosen codepoint scheme:
選択したコードポイントスキームの非規範的な要約：
Packets with ECT(1) and conditionally packets with CE signify L4S semantics as an alternative to the semantics of Classic ECN [RFC3168], specifically:
ECT（1）を備えたパケットとCEの条件付きパケットは、L4SセマンティクスをクラシックECN [RFC3168]のセマンティクスの代替として示します。
- The ECT(1) codepoint signifies that the packet was sent by an L4S-capable sender.
- ECT（1）CodePointは、パケットがL4S対応の送信者によって送信されたことを意味します。
- Given the shortage of codepoints, both the L4S and Classic ECN sides of an AQM have to use the same CE codepoint to indicate that a packet has experienced congestion. If a packet that had already been marked CE in an upstream buffer arrived at a subsequent AQM, this AQM would then have to guess whether to classify CE packets as L4S or Classic ECN. Choosing the L4S treatment is a safer choice, because then a few Classic packets might arrive early rather than a few L4S packets arriving late.
- コードポイントの不足を考えると、AQMのL4S側と古典的なECN側の両方が同じCE CodePointを使用して、パケットが混雑を経験したことを示す必要があります。上流バッファーで既にマークされていたパケットがその後のAQMに到着した場合、このAQMはCEパケットをL4SまたはクラシックECNとして分類するかどうかを推測する必要があります。L4S処理を選択する方が安全な選択です。なぜなら、いくつかの古典的なパケットが遅れて到着する少数のL4Sパケットではなく、早めに到着する可能性があるからです。
- Additional information might be available if the classifier were transport-aware. Then, it could classify a CE packet for Classic ECN treatment if the most recent ECT packet in the same flow had been set to ECT(0). However, the L4S service ought not need transport-layer awareness.
- 分類器が輸送認識である場合、追加情報が利用可能になる場合があります。次に、同じフローの最新のECTパケットがECT（0）に設定されていた場合、古典的なECN処理のCEパケットを分類できます。ただし、L4Sサービスには輸送層の認識は必要ありません。
Cons:
短所：
Consumes the last ECN codepoint: The L4S service could potentially supersede the service provided by Classic ECN; therefore, using ECT(1) to identify L4S packets could ultimately mean that the ECT(0) codepoint was 'wasted' purely to distinguish one form of ECN from its successor.
最後のECNコードポイントを消費します。L4Sサービスは、クラシックECNが提供するサービスに取って代わる可能性があります。したがって、ECT（1）を使用してL4Sパケットを識別することは、最終的にECT（0）CodePointがECNの1つの形式を後継者と区別するために「無駄になった」ことを意味する可能性があります。
ECN hard in some lower layers: It is not always possible to support the equivalent of an IP-ECN field in an AQM acting in a buffer below the IP layer [ECN-ENCAP]. Then, depending on the lower-layer scheme, the L4S service might have to drop rather than mark frames even though they might encapsulate an ECN-capable packet.
いくつかの下層ではeCN：IPレイヤー[ECN-ENCAP]の下のバッファで作用するAQMでIP-ECNフィールドに相当するものをサポートすることは常に可能ではありません。次に、低層スキームに応じて、ECN対応パケットをカプセル化する可能性がある場合でも、L4Sサービスはマークフレームではなくドロップする必要があります。
Risk of reordering Classic CE packets within a flow: Classifying all CE packets into the L4S queue risks any CE packets that were originally ECT(0) being incorrectly classified as L4S. If there were delay in the Classic queue, these incorrectly classified CE packets would arrive early, which is a form of reordering. Reordering within a microflow can cause TCP senders (and senders of similar transports) to retransmit spuriously. However, the risk of spurious retransmissions would be extremely low for the following reasons:
フロー内で古典的なCEパケットを並べ替えるリスク：すべてのCEパケットをL4Sキューに分類すると、元々ECT（0）が誤ってL4Sとして分類されていたCEパケットがリスクされます。古典的なキューに遅延があった場合、これらの誤って分類されたCEパケットは早期に到着し、これは並べ替えの一形態です。マイクロフロー内での並べ替えにより、TCP送信者（および同様の輸送の送信者）がspuriveめたに再送信される可能性があります。ただし、次の理由により、偽りの再送信のリスクは非常に低くなります。
1. It is quite unusual to experience queuing at more than one bottleneck on the same path (the available capacities have to be identical).
1. 同じパスで複数のボトルネックでキューイングを体験することは非常に珍しいことです（利用可能な容量は同一でなければなりません）。
2. In only a subset of these unusual cases would the first bottleneck support Classic ECN marking and the second L4S ECN marking. This would be the only scenario where some ECT(0) packets could be CE marked by an AQM supporting Classic ECN while subsequently the remaining ECT(0) packets would experience further delay through the Classic side of a subsequent L4S DualQ AQM.
2. これらの異常なケースのサブセットのみで、最初のボトルネックは古典的なECNマーキングと2番目のL4S ECNマーキングをサポートします。これは、いくつかのECT（0）パケットが古典的なECNをサポートするAQMによってCEをマークする唯一のシナリオであり、その後、残りのECT（0）パケットは、その後のL4S DualQ AQMの古典的な側面を介してさらに遅延を発生させます。
3. Even then, when a few packets are delivered early, it takes very unusual conditions to cause a spurious retransmission, in contrast to when some packets are delivered late. The first bottleneck has to apply CE marks to at least N contiguous packets, and the second bottleneck has to inject an uninterrupted sequence of at least N of these packets between two packets earlier in the stream (where N is the reordering window that the transport protocol allows before it considers a packet is lost).
3. それでも、いくつかのパケットが早期に配信されると、いくつかのパケットが遅れて配信される場合とは対照的に、非常に珍しい条件が偽りの再送信を引き起こすのに必要です。最初のボトルネックは、少なくともN連続パケットにCEマークを適用する必要があり、2番目のボトルネックは、これらのパケットの少なくともnの途切れのないシーケンスをストリームの前の2つのパケットの間に注入する必要があります（ここで、nは輸送プロトコルの並べ替えウィンドウです。パケットが失われると考える前に許可されます）。
For example, consider N=3, and consider the sequence of packets 100, 101, 102, 103,... Imagine that packets 150, 151, 152 from later in the flow are injected as follows: 100, 150, 151, 101, 152, 102, 103,... If this were late reordering, even one packet arriving out of sequence would trigger a spurious retransmission, but there is no spurious retransmission here with early reordering, because packet 101 moves the cumulative ACK counter forward before 3 packets have arrived out of order. Later, when packets 148, 149, 153,... arrive, even though there is a 3-packet hole, there will be no problem, because the packets to fill the hole are already in the receive buffer.
たとえば、n = 3を考慮し、パケット100、101、102、103のシーケンスを考慮してください...フローの後半からパケット150、151、152が次のように注入されていると想像してください：100、150、151、101、152、102、103、...これが遅れた場合、シーケンスから到着する1つのパケットでさえ偽の再送信をトリガーしますが、パケット101は累積ACKカウンターを前に移動するため、早期の並べ替えで偽りの再送信はありません。3つのパケットが故障していません。その後、パケット148、149、153、...到着すると、3パケットの穴がありますが、穴を埋めるパケットがすでに受信バッファーにあるため、問題はありません。
4. Even with the current TCP recommendation of N=3 [RFC5681], spurious retransmissions will be unlikely for all the above reasons. As RACK [RFC8985] is becoming widely deployed, it tends to adapt its reordering window to a larger value of N, which will make the chance of a contiguous sequence of N early arrivals vanishingly small.
4. n = 3 [RFC5681]の現在のTCP推奨があっても、上記のすべての理由で偽りの再送信はありそうにありません。ラック[RFC8985]が広く展開されているため、並べ替えウィンドウをNのより大きな値に適応させる傾向があり、これにより、Nの早期到着が隣接する隣接するシーケンスが消えてしまう可能性が高くなります。
5. Even a run of 2 CE marks within a Classic ECN flow is unlikely, given FQ-CoDel is the only known widely deployed AQM that supports Classic ECN marking, and it takes great care to separate out flows and to space any markings evenly along each flow.
5. FQコデルが古典的なECNマーキングをサポートする広く展開されている唯一の既知のAQMであることを考えると、古典的なECNフロー内の2つのCEマークのランでさえありそうにありません。。
It is extremely unlikely that the above set of 5 eventualities that are each unusual in themselves would all happen simultaneously. But, even if they did, the consequences would hardly be dire: the odd spurious fast retransmission. Whenever the traffic source (a Classic congestion control) mistakes the reordering of a string of CE marks for a loss, one might think that it will reduce its congestion window as well as emitting a spurious retransmission. However, it would have already reduced its congestion window when the CE markings arrived early. If it is using ABE [RFC8511], it might reduce cwnd a little more for a loss than for a CE mark. But it will revert that reduction once it detects that the retransmission was spurious.
それぞれが珍しい5つの不測の事態の上記のセットがすべて同時に起こる可能性は非常に低いです。しかし、たとえ彼らがそうしていても、結果はほとんど悲惨ではありません。奇妙な偽りの速い再送信です。トラフィックソース（古典的な混雑制御）が、一連のCEマークの並べ替えを損失のために並べ替えると、渋滞ウィンドウを減らすだけでなく、偽りの再送信を放出すると考えるかもしれません。ただし、CEマーキングが早く到着したとき、すでに混雑ウィンドウを減らしていたでしょう。ABE [RFC8511]を使用している場合、CEマークよりも損失の方が少し減少する可能性があります。しかし、再送信が偽物であることを検出すると、その削減がその削減を取り戻します。
In conclusion, the impact of early reordering on spurious retransmissions due to CE being ambiguous will generally be vanishingly small.
結論として、CEがあいまいであるための偽りの再送信に対する早期の並べ替えの影響は、一般的には驚くほど小さくなります。
Insufficient anti-replay window in some pre-existing VPNs: If delay is reduced for a subset of the flows within a VPN, the anti-replay feature of some VPNs is known to potentially mistake the difference in delay for a replay attack. Section 6.2 recommends that the anti-replay window at the VPN egress is sufficiently sized, as required by the relevant specifications. However, in some VPN implementations, the maximum anti-replay window is insufficient to cater for a large delay difference at prevailing packet rates. Section 6.2 suggests alternative work-rounds for such cases, but end users using L4S over a VPN will need to be able to recognize the symptoms of this problem, in order to seek out these work-rounds.
既存のVPNで不十分なアンチレプレイウィンドウ：VPN内のフローのサブセットの遅延が減少した場合、一部のVPNのアンチレプレイ機能は、リプレイ攻撃の遅延の差を間違える可能性があることが知られています。セクション6.2では、関連する仕様で要求されるように、VPN出口のアンチレプレイウィンドウが十分にサイズになることを推奨しています。ただし、一部のVPN実装では、最大アンチレプレイウィンドウは、一般的なパケットレートで大きな遅延差に応えるには不十分です。セクション6.2は、そのような場合の代替作業ラウンドを示唆していますが、これらの作業ラウンドを探すために、VPNでL4Sを使用するエンドユーザーは、この問題の症状を認識できる必要があります。
Hard to distinguish Classic ECN AQM: With this scheme, when a source receives ECN feedback, it is not explicitly clear which type of AQM generated the CE markings. This is not a problem for Classic ECN sources that send ECT(0) packets, because an L4S AQM will recognize the ECT(0) packets as Classic and apply the appropriate Classic ECN-marking behaviour.
古典的なECN AQMを区別するのは難しい：このスキームでは、ソースがECNフィードバックを受信した場合、どのタイプのAQMがCEマークを生成したかは明示的に明示的ではありません。これは、ECT（0）パケットを送信する古典的なECNソースにとっては問題ではありません。L4SAQMはECT（0）パケットをクラシックとして認識し、適切なクラシックECNマーク動作を適用するためです。
However, in the absence of explicit disambiguation of the CE markings, an L4S source needs to use heuristic techniques to work out which type of congestion response to apply (see Appendix A.1.5). Otherwise, if long-running Classic flows are sharing a Classic ECN AQM bottleneck with long-running L4S flows, and the L4S flows apply an L4S response to the Classic CE signals, they would then outcompete the Classic flows. Experiments have shown that L4S flows can take about 20 times more capacity share than equivalent Classic flows. Nonetheless, as link capacity reduces (e.g., to 4 Mb/s), the inequality reduces. So Classic flows always make progress and are not starved.
ただし、CEマーキングの明示的な乱用がない場合、L4Sソースは、ヒューリスティックテクニックを使用して、どのタイプの混雑反応を適用するかを判断する必要があります（付録A.1.5を参照）。それ以外の場合、長期にわたる古典的なフローが長期にわたるL4Sフローを使用して古典的なECN AQMボトルネックを共有し、L4Sフローが古典的なCE信号にL4S応答を適用すると、古典的なフローを反映します。実験により、L4Sフローは、同等のクラシックフローよりも約20倍の容量シェアを獲得できることが示されています。それにもかかわらず、リンク容量が減少すると（例：4 MB/s）、不平等は減少します。したがって、古典的なフローは常に進歩し、飢えていません。
When L4S was first proposed (in 2015, 14 years after the Classic ECN spec [RFC3168] was published), it was believed that Classic ECN AQMs had failed to be deployed because research measurements had found little or no evidence of CE marking. In subsequent years, Classic ECN was included in FQ deployments; however, an FQ scheduler stops an L4S flow outcompeting Classic, because it enforces equality between flow rates. It is not known whether there have been any non-FQ deployments of Classic ECN AQMs in the subsequent years or whether there will be any in future.
L4Sが最初に提案されたとき（2015年、古典的なECN仕様[RFC3168]が公開されてから14年後）、研究測定ではCEマーキングの証拠がほとんどまたはまったく見つからなかったため、古典的なECN AQMSが展開されなかったと考えられていました。その後の数年間で、古典的なECNがFQ展開に含まれていました。ただし、FQスケジューラは、流量間の平等を強制するため、L4Sフローアウトコンピューティングクラシックを停止します。その後の年に古典的なECN AQMのfq以外の展開があったのか、それとも将来的に展開されるのかは不明です。
An algorithm for detecting a Classic ECN AQM as soon as a flow stabilizes after start-up has been proposed [ecn-fallback] (see Appendix A.1.5 for a brief summary). Testbed evaluations of v2 of the algorithm have shown detection is reasonably good for Classic ECN AQMs, in a wide range of circumstances. However, although it can correctly detect an L4S ECN AQM in many circumstances, it is often incorrect at low link capacities and/or high RTTs. Although this is the safe way round, there is a danger that it will discourage use of the algorithm.
スタートアップが提案された後にフローが安定するとすぐに、古典的なECN AQMを検出するためのアルゴリズム[ECN-Fallback]（簡単な要約については、付録A.1.5を参照）。アルゴリズムのV2のテストベッド評価により、検出は、広範な状況での古典的なECN AQMに合理的に適切であることが示されています。ただし、多くの状況でL4S ECN AQMを正しく検出することはできますが、低リンク容量や高RTTで間違っていることがよくあります。これは安全な方法ですが、アルゴリズムの使用を思いとどまらせる危険があります。
Non-L4S service for control packets: Solely for the case of TCP, the Classic ECN RFCs [RFC3168] and [RFC5562] require a sender to clear the IP-ECN field to Not-ECT on retransmissions and on certain control packets, specifically pure ACKs, window probes, and SYNs. When L4S packets are classified by the IP-ECN field, these TCP control packets would not be classified into an L4S queue and could therefore be delayed relative to the other packets in the flow. This would not cause reordering (because retransmissions are already out of order, and these control packets typically carry no data). However, it would make critical TCP control packets more vulnerable to loss and delay. To address this problem, ECN++ [ECN++] proposes an experiment in which all TCP control packets and retransmissions are ECN-capable as long as appropriate ECN feedback is available in each case.
制御パケットの非L4Sサービス：TCPの場合のみ、古典的なECN RFCS [RFC3168]および[RFC5562]は、送信者にIP-ECNフィールドをクリアするために送信者が再送信および特定のコントロールパケットをクリアする必要があります。Acks、Window Probes、およびSyns。L4SパケットがIP-ECNフィールドによって分類されると、これらのTCP制御パケットはL4Sキューに分類されず、したがって、フロー内の他のパケットに対して遅延する可能性があります。これは並べ替えを引き起こすことはありません（再送信はすでに故障しており、これらの制御パケットには通常データが含まれていないため）。ただし、重要なTCP制御パケットは、損失と遅延に対してより脆弱になります。この問題に対処するために、ECN [ECN]は、すべてのTCP制御パケットと再送信が、それぞれの場合に適切なECNフィードバックが利用可能である限りECN対応である実験を提案します。
Pros:
長所：
Should work end to end: The IP-ECN field generally propagates end to end across the Internet without being wiped or mangled, at least over fixed networks. Unlike the DSCP, the setting of the ECN field is at least meant to be forwarded unchanged by networks that do not support ECN.
端から端まで動作する必要があります：IP-ECNフィールドは一般に、少なくとも固定ネットワーク上で、拭いたり壊れたりすることなく、インターネット全体で端から端まで伝播します。DSCPとは異なり、ECNフィールドの設定は、少なくともECNをサポートしていないネットワークによって変更されずに転送されることを意図しています。
Should work in tunnels: The L4S identifiers work across and within any tunnel that propagates the IP-ECN field in any of the variant ways it has been defined since ECN-tunneling was first specified in the year 2001 [RFC3168]. However, it is likely that some tunnels still do not implement ECN propagation at all.
トンネルで動作する必要があります。L4S識別子は、ECNトンネルが2001年に最初に指定されたため定義されているバリアントのいずれかの方法でIP-ECNフィールドを伝播するトンネル全体および内部で動作します[RFC3168]。ただし、一部のトンネルはまだECN伝播をまったく実装していない可能性があります。
Should work for many link technologies: At most, but not all, path bottlenecks there is IP awareness, so that L4S AQMs can be located where the IP-ECN field can be manipulated. Bottlenecks at lower-layer nodes without IP awareness have to either use drop to signal congestion or have a specific congestion notification facility defined for that link technology, including propagation to and from IP-ECN. The programme to define these is progressing, and in each case so far, the scheme already defined for ECN inherently supports L4S as well (see Section 6.1).
多くのリンクテクノロジーで機能する必要があります。せいぜい、すべてではありませんが、パスボトルネックがIP認識があり、IP-ECNフィールドを操作できるL4S AQMSを配置できます。IP認識のない低層ノードでのボトルネックは、Dropを使用して混雑を示すか、IP-ECNとの伝播を含むそのリンクテクノロジー用に定義されている特定の混雑通知施設を持つ必要があります。これらを定義するプログラムは進行中であり、それぞれの場合において、これまでにECNのために既に定義されているスキームも本質的にL4をサポートしています（セクション6.1を参照）。
Could migrate to one codepoint: If all Classic ECN senders eventually evolve to use the L4S service, the ECT(0) codepoint could be reused for some future purpose but only once use of ECT(0) packets has reduced to zero, or near zero, which might never happen.
1つのコードポイントに移行できます。すべての古典的なECN送信者が最終的にL4Sサービスを使用するように進化した場合、ECT（0）CodePointは将来の目的で再利用できますが、ECT（0）パケットの使用はゼロまたはほぼゼロに減少しました。、決して起こらないかもしれません。
L4 not required: Being based on the IP-ECN field, this scheme does not need the network to access transport-layer flow IDs. Nonetheless, it does not preclude solutions that do.
L4不要：IP-ECNフィールドに基づいているため、このスキームは輸送層のフローIDにアクセスするためのネットワークを必要としません。それにもかかわらず、それはそうする解決策を排除しません。
Appendix C. Potential Competing Uses for the ECT(1) Codepoint
付録C. ECT（1）CodePointの潜在的な競合用途
The ECT(1) codepoint of the IP-ECN field has already been assigned once for the ECN nonce spec [RFC3540], which has now been categorized as Historic [RFC8311]. ECN is probably the only remaining field in the Internet Protocol that is common to IPv4 and IPv6 and still has potential to work end to end, with tunnels and with lower layers. Therefore, ECT(1) should not be reassigned to a different experimental use (L4S) without carefully assessing competing potential uses. These fall into the categories described below.
IP-ECNフィールドのECT（1）コードポイントは、現在歴史的[RFC8311]に分類されているECN NonCe Spec [RFC3540]にすでに1回割り当てられています。ECNは、おそらくIPv4およびIPv6に共通するインターネットプロトコル内の唯一の残りのフィールドであり、トンネルと低レイヤーを備えた端から端まで動作する可能性があります。したがって、ECT（1）は、競合する潜在的な使用を慎重に評価することなく、別の実験的使用（L4S）に再割り当てされるべきではありません。これらは、以下で説明するカテゴリに分類されます。
Receiving hosts can fool a sender into downloading faster by suppressing feedback of ECN marks (or of losses if retransmissions are not necessary or available otherwise).
受信ホストは、ECNマークのフィードバックを抑制することにより、送信者をだましてより速くダウンロードすることができます（または、再送信が必要である場合、またはそれ以外の場合は利用できない場合は損失の場合）。
The Historic ECN nonce spec [RFC3540] proposed that a TCP sender could set either ECT(0) or ECT(1) in each packet of a flow and remember the sequence it had set. If any packet was lost or congestion marked, the receiver would miss that bit of the sequence. An ECN nonce receiver had to feed back the least-significant bit of the sum, so it could not suppress feedback of a loss or mark without a 50-50 chance of guessing the sum incorrectly.
歴史的なECN Nonce Spec [RFC3540]は、TCP送信者がフローの各パケットにECT（0）またはECT（1）を設定し、設定したシーケンスを覚えていることを提案しました。パケットが紛失した場合、または輻輳がマークされた場合、受信者はそのビットのシーケンスを逃します。ECN NONCEレシーバーは、合計の合計を最も重要でないビットビットをフィードバックする必要があったため、合計を誤って推測することなく、損失またはマークのフィードバックを抑制することはできませんでした。
It is highly unlikely that ECT(1) will be needed as a nonce for integrity protection of congestion notifications in future. The ECN nonce spec [RFC3540] has been reclassified as Historic, partly because other ways (that do not consume a codepoint in the IP header) have been developed to protect feedback integrity of TCP and other transports [RFC8311]. For instance:
将来の混雑通知の整合性保護のための非CEとしてECT（1）が必要になる可能性は非常に低いです。ECN Nonce Spec [RFC3540]は、TCPおよび他の輸送のフィードバックの完全性を保護するために他の方法（IPヘッダーのコードポイントを消費しない）が開発されたため、歴史的として再分類されています[RFC8311]。例えば：
* The sender can test the integrity of a small random sample of the receiver's feedback by occasionally setting the IP-ECN field to a value normally only set by the network. Then, it can test whether the receiver's feedback faithfully reports what it expects (see Paragraph 2 of Section 20.2 of the ECN spec [RFC3168]. This works for loss, and it will work for the accurate ECN feedback [RFC7560] intended for L4S. Like the (Historic) ECN nonce spec, this technique does not protect against a misbehaving sender. But it allows a well-behaved sender to check that each receiver is correctly feeding back congestion notifications.
* 送信者は、受信機のフィードバックの小さなランダムサンプルの整合性をテストできます。これにより、通常はネットワークによってのみ設定された値にIP-ECNフィールドを設定することができます。次に、受信者のフィードバックが予想されることを忠実に報告するかどうかをテストできます（ECN仕様[RFC3168]のセクション20.2のパラグラフ2を参照してください。これは損失に対応し、L4Sを対象とした正確なECNフィードバック[RFC7560]に機能します。（歴史的な）ECN Nonce Specのように、この手法は不正行為の送信者から保護しません。しかし、行儀の良い送信者は、各受信者が混雑通知を正しく返していることを確認できます。
* A network can check that its ECN markings (or packet losses) have been passed correctly around the full feedback loop by auditing Congestion Exposure (ConEx) [RFC7713]. This assures that the integrity of congestion notifications and feedback messages must have both been preserved. ConEx information is also available anywhere along the network path, so it can be used to enforce a congestion response. Whether the receiver or a downstream network is suppressing congestion feedback or the sender is unresponsive to the feedback, or both, ConEx is intended to neutralize any advantage that any of these three parties would otherwise gain.
* ネットワークは、con輸送（Conex）[RFC7713]を監査することにより、ECNマーク（またはパケット損失）が完全なフィードバックループに正しく渡されていることを確認できます。これにより、混雑通知とフィードバックメッセージの整合性が両方とも保持されている必要があります。Conex情報は、ネットワークパス沿いのどこでも利用できるため、混雑反応を実施するために使用できます。受信者またはダウンストリームネットワークがうっ血フィードバックを抑制している場合でも、送信者がフィードバックに反応しない場合でも、Conexはこれらの3つの当事者のいずれかが獲得する利点を中和することを目的としています。
* Congestion feedback fields in transport-layer headers are immutable end to end and therefore amenable to end-to-end integrity protection. This preserves the integrity of a receiver's feedback messages to the sender, but it does not protect against misbehaving receivers or misbehaving senders. The TCP Authentication Option (TCP-AO) [RFC5925], QUIC's end-to-end protection [RFC9001], or end-to-end IPsec integrity protection [RFC4303] can be used to detect any tampering with congestion feedback (whether malicious or accidental), respectively, in TCP, QUIC, or any transport. TCP-AO covers the main TCP header and TCP options by default, but it is often too brittle to use on many end-to-end paths, where middleboxes can make verification fail in their attempts to improve performance or security, e.g., by resegmentation or shifting the sequence space.
* 輸送層ヘッダーの混雑フィードバックフィールドは、エンドからエンドまで不変であるため、エンドツーエンドの完全性保護に適しています。これにより、受信者のフィードバックメッセージの送信者への整合性が維持されますが、レシーバーの不正行為や誤動作の送信者を保護しません。TCP認証オプション（TCP-AO）[RFC5925]、QUICのエンドツーエンド保護[RFC9001]、またはエンドツーエンドのIPSEC整合性保護[RFC4303]を使用して、混雑フィードバックのタンパーを検出することができます（悪意のあるか、または悪意があるか、偶発的）、それぞれTCP、QUIC、または任意の輸送。TCP-AOはデフォルトでメインのTCPヘッダーとTCPオプションをカバーしていますが、多くのエンドツーエンドパスで使用するにはあまりにも脆弱です。ミドルボックスは、パフォーマンスやセキュリティを改善しようとする試みで検証を失敗させることができます。またはシーケンス空間をシフトします。
At the time of writing, it is becoming common to protect the integrity of transport feedback using QUIC. However, it is still not common to protect the integrity of the wider congestion feedback loop, whether based on loss or Classic ECN. If this position changes during the L4S experiment, one or more of the above techniques might need to be developed and deployed.
執筆時点では、QUICを使用して輸送フィードバックの完全性を保護することが一般的になっています。ただし、損失または古典的なECNに基づいていても、より広い輻輳フィードバックループの完全性を保護することは依然として一般的ではありません。L4S実験中にこの位置が変化する場合、上記の手法の1つ以上を開発して展開する必要がある場合があります。
Various researchers have proposed to use ECT(1) as a less severe congestion notification than CE, particularly to enable flows to fill available capacity more quickly after an idle period, when another flow departs or when a flow starts, e.g., the Variable-structure congestion Control Protocol (VCP) [VCP] and Queue View (QV) [QV].
さまざまな研究者がECT（1）をCEよりも深刻な輻輳通知として使用することを提案しています。特に、フローが別のフローが出発したとき、または流れが始まるときに、フローがより迅速に利用可能な容量を充填できるようにすることを提案しています。混雑制御プロトコル（VCP）[VCP]およびキュービュー（QV）[QV]。
Before assigning ECT(1) as an identifier for L4S, we must carefully consider whether it might be better to hold ECT(1) in reserve for future standardization of rapid flow acceleration, which is an important and enduring problem [RFC6077].
ECT（1）をL4Sの識別子として割り当てる前に、重要かつ永続的な問題である迅速な流れ加速の将来の標準化のためにECT（1）を保留する方が良いかどうかを慎重に検討する必要があります[RFC6077]。
Pre-Congestion Notification (PCN) is another scheme that assigns alternative semantics to the IP-ECN field. It uses ECT(1) to signify a less severe level of pre-congestion notification than CE [RFC6660]. However, the IP-ECN field only takes on the PCN semantics if packets carry a Diffserv codepoint defined to indicate PCN marking within a controlled environment. PCN is required to be applied solely to the outer header of a tunnel across the controlled region in order not to interfere with any end-to-end use of the ECN field. Therefore, a PCN region on the path would not interfere with the L4S service identifier defined in Section 2.
事前相合通知（PCN）は、IP-ECNフィールドに代替セマンティクスを割り当てる別のスキームです。ECT（1）を使用して、CE [RFC6660]よりも重度の低いレベルの事前通知を意味します。ただし、IP-ECNフィールドは、パケットが制御された環境内でPCNマークを示すように定義されたDiffServ CodePointを運ぶ場合にのみPCNセマンティクスを使用します。PCNは、ECNフィールドのエンドツーエンド使用を妨害しないために、制御された領域を横切るトンネルの外側ヘッダーにのみ適用する必要があります。したがって、パス上のPCN領域は、セクション2で定義されているL4Sサービス識別子を妨害しません。
Acknowledgements
謝辞
Thanks to Richard Scheffenegger, John Leslie, David Tht, Jonathan Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson, and Andrew McGregor for the discussions that led to this specification. Ing-jyh (Inton) Tsang was a contributor to the early draft versions of this document. Thanks to Mikael Abrahamsson, Lloyd Wood, Nicolas Kuhn, Greg White, Tom Henderson, David Black, Gorry Fairhurst, Brian Carpenter, Jake Holland, Rod Grimes, Richard Scheffenegger, Sebastian Moeller, Neal Cardwell, Praveen Balasubramanian, Reza Marandian Hagh, Pete Heist, Stuart Cheshire, Vidhi Goel, Mirja Khlewind, Ermin Sakic, and Martin Duke for providing help and reviewing this document. And thanks to Ingemar Johansson for reviewing and providing substantial text. Thanks also to the area reviewers: Valery Smyslov, Maria Ines Robles, Bernard Aboba, Lars Eggert, Roman Danyliw, and ric Vyncke. Thanks to Sebastian Moeller for identifying the interaction with VPN anti-replay and to Jonathan Morton for identifying the attack based on this. Particular thanks to tsvwg chairs Gorry Fairhurst, David Black, and Wes Eddy for patiently helping this and the other L4S documents through the IETF process. Appendix A, which lists the Prague L4S Requirements, is based on text authored by Marcelo Bagnulo Braun that was originally an appendix to [RFC9330]. That text was in turn based on the collective output of the attendees listed in the minutes of a 'bar BoF' on DCTCP Evolution during IETF 94 [TCPPrague].
リチャード・シェフェネッガー、ジョン・レスリー、デビッド・トート、ジョナサン・モートン、ゴリー・フェアハースト、マイケル・ウェルツル、ミカエル・アブラハムソン、アンドリュー・マクレガーに、この仕様につながった議論に感謝します。Ing-Jyh（Inton）Tsangは、このドキュメントの初期ドラフトバージョンの貢献者でした。ミカエル・アブラハムソン、ロイド・ウッド、ニコラス・クーン、グレッグ・ホワイト、トム・ヘンダーソン、デビッド・ブラック、ゴリー・フェアハースト、ブライアン・カーペンター、ジェイク・ホランド、ロッド・グライムズ、リチャード・シェフェンガー、セバスチャン・モーラー、ニール・カードウェル、プラヴェン・バラスブラマン、レザ・マランディアン・ハグ、ペット、スチュアート・チェシャー、ヴィディ・ゴエル、ミルジャ・クレウィンド、アーミン・サキッチ、およびマーティン・デュークを提供して、この文書をレビューしてくれました。そして、実質的なテキストをレビューして提供してくれたIngemar Johanssonに感謝します。地域のレビュアーにも感謝します：Valery Smyslov、Maria Ines Robles、Bernard Aboba、Lars Eggert、Roman Danyliw、Ric Vyncke。VPNアンチレプレイとの相互作用を特定してくれたSebastian Moellerと、これに基づいて攻撃を特定してくれたJonathan Mortonに感謝します。TSVWGの椅子Gorry Fairhurst、David Black、およびWes Eddyに、IETFプロセスを通じてこれと他のL4S文書を辛抱強く支援してくれたことに特に感謝します。プラハL4Sの要件をリストしている付録Aは、元々[RFC9330]の付録であったMarcelo Bagnulo Braunによって作成されたテキストに基づいています。そのテキストは、IETF 94 [TCPPRAGUE]中のDCTCP進化に関する「bar bof」の議事録にリストされている参加者の集合的な出力に基づいて順番に基づいています。
The authors' contributions 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 partly funded by the Research Council of Norway through the TimeIn project, CableLabs, and the Comcast Innovation Fund. The views expressed here are solely those of the authors.
著者の貢献は、還元インターネットトランスポートレイテンシ（Rite）プロジェクト（ICT-317700）を通じて、第7回のフレームワークプログラムの下で欧州共同体によって部分的に資金提供されていました。Koen de Schepperの貢献は、5成長とDaemon Eu H2020プロジェクトによっても部分的に資金提供されていました。ボブ・ブリスコーは、タイミンプロジェクト、ケーブルラブ、およびコムキャストイノベーション基金を通じて、ノルウェーの研究評議会によって部分的に資金提供されていました。ここで表明された見解は、著者の見解だけです。
Authors' Addresses
著者のアドレス
Koen De Schepper Nokia Bell Labs Antwerp Belgium Email: koen.de_schepper@nokia.com URI: https://www.bell-labs.com/about/researcher-profiles/ koende_schepper/
Koen de Schepper Nokia Bell Labs Antwerp Belgiumメール：koen.de_schepper@nokia.com Uri：https：//www.bell-labs.com/about/researcher-profiles/ koende_schepper/
Bob Briscoe (editor) Independent United Kingdom Email: ietf@bobbriscoe.net URI: https://bobbriscoe.net/
Bob Briscoe（編集者）独立した英国電子メール：ietf@bobbriscoe.net uri：https：//bobbriscoe.net/