[要約] 要約： RFC 8034は、DOCSISケーブルモデムのためのProportional Integral Controller Enhanced PIE（PIE）に基づくActive Queue Management（AQM）に関するものです。目的： このRFCの目的は、DOCSISケーブルモデムのパフォーマンスを向上させるために、AQMアルゴリズムであるPIEを使用する方法を提案することです。
Internet Engineering Task Force (IETF) G. White
Request for Comments: 8034 CableLabs
Category: Informational R. Pan
ISSN: 2070-1721 Cisco Systems
February 2017
Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems
データオーバーケーブルサービスインターフェイス仕様（DOCSIS）ケーブルモデム用の比例積分コントローラー拡張（PIE）に基づくアクティブキュー管理（AQM）
Abstract
概要
Cable modems based on Data-Over-Cable Service Interface Specifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.
データオーバーケーブルサービスインターフェイス仕様（DOCSIS）に基づくケーブルモデムは、世界中の1億人を超えるユーザーにブロードバンドインターネットアクセスを提供します。場合によっては、ケーブルモデム接続が、顧客とインターネット間のボトルネック（最低速度）リンクであることがあります。その結果、ケーブルモデムのバッファリングとバッファブロートの影響は、ユーザーエクスペリエンスに大きな影響を与える可能性があります。 CableLabs DOCSIS 3.1仕様は、ケーブルモデムがActive Queue Management（AQM）アルゴリズムをサポートするための要件を導入しています。これは、バルクスループットパフォーマンスを維持しながら、バッファリングが遅延の影響を受けやすいトラフィックに与える影響を軽減することを目的としています。さらに、CableLabs DOCSIS 3.0仕様も同様の要件を含むように修正されました。このドキュメントでは、DOCSIS 3.1ケーブルモデムで必要な「DOCSIS-PIE」アルゴリズムの説明を含め、DOCSIS機器に適用されるAQMの要件について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc8034.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8034で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of DOCSIS AQM Requirements . . . . . . . . . . . . . 3
3. The DOCSIS MAC Layer and Service Flows . . . . . . . . . . . 4
4. DOCSIS-PIE vs. PIE . . . . . . . . . . . . . . . . . . . . . 5
4.1. Latency Target . . . . . . . . . . . . . . . . . . . . . 5
4.2. Departure Rate Estimation . . . . . . . . . . . . . . . . 6
4.3. Enhanced Burst Protection . . . . . . . . . . . . . . . . 7
4.4. Expanded Auto-Tuning Range . . . . . . . . . . . . . . . 7
4.5. Trigger for Exponential Decay . . . . . . . . . . . . . . 8
4.6. Drop Probability Scaling . . . . . . . . . . . . . . . . 8
4.7. Support for Explicit Congestion Notification . . . . . . 8
5. Implementation Guidance . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. DOCSIS-PIE Algorithm Definition . . . . . . . . . . 11
A.1. DOCSIS-PIE AQM Constants and Variables . . . . . . . . . 11
A.1.1. Configuration Parameters . . . . . . . . . . . . . . 11
A.1.2. Constant Values . . . . . . . . . . . . . . . . . . . 11
A.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 12
A.1.4. Public/System Functions . . . . . . . . . . . . . . . 12
A.2. DOCSIS-PIE AQM Control Path . . . . . . . . . . . . . . . 13
A.3. DOCSIS-PIE AQM Data Path . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
A recent resurgence of interest in active queue management, arising from a recognition of the inadequacies of drop-tail queuing in the presence of loss-based congestion control algorithms, has resulted in the development of new algorithms that appear to provide very good congestion feedback to current TCP algorithms, while also having operational simplicity and low complexity. One of these algorithms has been selected as a requirement for cable modems built according to the DOCSIS 3.1 specification [DOCSIS_3.1]. The Data-Over-Cable Service Interface Specifications (DOCSIS) define the broadband technology deployed worldwide for Ethernet and IP service over hybrid fiber-coaxial cable systems. The most recent revision of the DOCSIS technology, version 3.1, was originally published in October 2013 and provides support for up to 10 Gbps downstream (toward the customer) and 1 Gbps upstream (from the customer) capacity over existing cable networks. Previous versions of the DOCSIS technology did not contain requirements for AQM. This document outlines the high-level AQM requirements for DOCSIS systems, discusses some of the salient features of the DOCSIS Media Access Control (MAC) layer, and describes the DOCSIS-PIE algorithm -- largely by comparing it to its progenitor, the PIE algorithm [RFC8033].
損失ベースの輻輳制御アルゴリズムが存在する場合のドロップテールキューイングの不適切性の認識から生じた、アクティブキュー管理への関心の最近の復活により、非常に優れた輻輳フィードバックを提供するように見える新しいアルゴリズムが開発されました。現在のTCPアルゴリズムは、操作も単純で、複雑度も低いです。これらのアルゴリズムの1つは、DOCSIS 3.1仕様[DOCSIS_3.1]に従って構築されたケーブルモデムの要件として選択されています。データオーバーケーブルサービスインターフェイス仕様（DOCSIS）は、ハイブリッドファイバー同軸ケーブルシステムを介したイーサネットおよびIPサービスのために世界中で展開されているブロードバンドテクノロジーを定義しています。 DOCSISテクノロジーの最新リビジョンであるバージョン3.1は、2013年10月に最初に公開され、既存のケーブルネットワーク上で最大10 Gbpsのダウンストリーム（お客様に向かって）および1 Gbpsのアップストリーム（お客様から）の容量をサポートします。以前のバージョンのDOCSISテクノロジーには、AQMの要件は含まれていませんでした。このドキュメントでは、DOCSISシステムの高レベルのAQM要件の概要を示し、DOCSISメディアアクセスコントロール（MAC）レイヤーの主要な機能のいくつかについて説明し、DOCSIS-PIEアルゴリズムについて説明します。これは主に、その先祖であるPIEアルゴリズムと比較することによって行われます。 [RFC8033]。
CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1] mandates that cable modems implement a specific variant of the Proportional Integral controller Enhanced (PIE) AQM algorithm [RFC8033]. This specific variant is provided for reference in Appendix A, and simulation results comparing it to drop-tail queuing and other AQM options are given in [CommMag] and [DOCSIS-AQM]. In addition, CableLabs' DOCSIS 3.0 specification [DOCSIS_3.0] has been amended to recommend that cable modems implement the same algorithm. Both specifications allow that cable modems can optionally implement additional algorithms that can then be selected for use by the operator via the modem's configuration file.
CableLabsのDOCSIS 3.1仕様[DOCSIS_3.1]は、ケーブルモデムがProportional Integral Controller Enhanced（PIE）AQMアルゴリズム[RFC8033]の特定のバリアントを実装することを義務付けています。この特定のバリアントは、付録Aで参照用に提供されており、ドロップテールキューイングおよび他のAQMオプションと比較したシミュレーション結果は、[CommMag]および[DOCSIS-AQM]で提供されています。さらに、CableLabsのDOCSIS 3.0仕様[DOCSIS_3.0]は、ケーブルモデムが同じアルゴリズムを実装することを推奨するように修正されました。どちらの仕様でも、ケーブルモデムはオプションで追加のアルゴリズムを実装でき、その後、モデムの構成ファイルを介してオペレーターが使用するために選択できます。
These requirements on the cable modem apply to upstream transmissions (i.e., from the customer to the Internet).
ケーブルモデムに関するこれらの要件は、アップストリーム伝送（つまり、顧客からインターネットへ）に適用されます。
Both specifications also include requirements (mandatory in DOCSIS 3.1 and recommended in DOCSIS 3.0) that the Cable Modem Termination System (CMTS) implement AQM for downstream traffic; however, no specific algorithm is defined for downstream use.
どちらの仕様にも、ケーブルモデムターミネーションシステム（CMTS）がダウンストリームトラフィックのAQMを実装するという要件（DOCSIS 3.1では必須、DOCSIS 3.0では推奨）が含まれています。ただし、ダウンストリームで使用するための特定のアルゴリズムは定義されていません。
The DOCSIS Media Access Control (sub-)layer provides tools for configuring differentiated Quality of Service (QoS) for different applications by the use of Packet Classifiers and Service Flows.
DOCSISメディアアクセスコントロール（サブ）レイヤーは、パケット分類子とサービスフローを使用して、さまざまなアプリケーションに対して差別化されたサービス品質（QoS）を構成するためのツールを提供します。
Each Service Flow has an associated QoS parameter set that defines the treatment of the packets that traverse the Service Flow. These parameters include, for example, Minimum Reserved Traffic Rate, Maximum Sustained Traffic Rate, Peak Traffic Rate, Maximum Traffic Burst, and Traffic Priority. Each upstream Service Flow corresponds to a queue in the cable modem, and each downstream Service Flow corresponds to a queue in the CMTS. The DOCSIS AQM requirements mandate that the CM and CMTS implement the AQM algorithm (and allow it to be disabled, if needed) on each Service Flow queue independently.
各サービスフローには、サービスフローを通過するパケットの処理を定義するQoSパラメータセットが関連付けられています。これらのパラメータには、たとえば、最小予約トラフィックレート、最大持続トラフィックレート、ピークトラフィックレート、最大トラフィックバースト、およびトラフィックプライオリティが含まれます。各アップストリームサービスフローはケーブルモデムのキューに対応し、各ダウンストリームサービスフローはCMTSのキューに対応します。 DOCSIS AQM要件では、CMとCMTSが各サービスフローキューに個別にAQMアルゴリズムを実装する（必要に応じて無効にすることができる）ことが義務付けられています。
Packet Classifiers can match packets based upon several fields in the packet/frame headers including the Ethernet header, IP header, and TCP/UDP header. Matched packets are then queued in the associated Service Flow queue.
パケット分類子は、イーサネットヘッダー、IPヘッダー、TCP / UDPヘッダーなど、パケット/フレームヘッダーのいくつかのフィールドに基づいてパケットを照合できます。一致したパケットは、関連するサービスフローキューに入れられます。
Each cable modem can be configured with multiple Packet Classifiers and Service Flows. The maximum number of such entities that a cable modem supports is an implementation decision for the manufacturer, but modems typically support 16 or 32 upstream Service Flows and at least that many Packet Classifiers. Similarly, the CMTS supports multiple downstream Service Flows and multiple Packet Classifiers per cable modem.
各ケーブルモデムは、複数のパケット分類子とサービスフローで構成できます。ケーブルモデムがサポートするそのようなエンティティの最大数は、製造元の実装決定ですが、モデムは通常、16または32のアップストリームサービスフローと、少なくともその数のパケット分類子をサポートします。同様に、CMTSはケーブルモデムごとに複数のダウンストリームサービスフローと複数のパケット分類子をサポートします。
It is typical that upstream and downstream Service Flows used for broadband Internet access are configured with a Maximum Sustained Traffic Rate. This QoS parameter rate-shapes the traffic onto the DOCSIS link and is the main parameter that defines the service offering. Additionally, it is common that upstream and downstream Service Flows are configured with a Maximum Traffic Burst and a Peak Traffic Rate. These parameters allow the service to burst at a higher (sometimes significantly higher) rate than is defined in the Maximum Sustained Traffic Rate for the amount of bytes configured in Maximum Traffic Burst, as long as the long-term average data rate remains at or below the Maximum Sustained Traffic Rate.
ブロードバンドインターネットアクセスに使用されるアップストリームおよびダウンストリームのサービスフローは、最大持続トラフィックレートで設定されるのが一般的です。このQoSパラメータは、DOCSISリンクへのトラフィックをレートシェーピングし、提供されるサービスを定義する主要なパラメータです。さらに、アップストリームおよびダウンストリームのサービスフローは、最大トラフィックバーストとピークトラフィックレートで設定されるのが一般的です。これらのパラメーターを使用すると、長期平均データレートがそれ以下である限り、最大トラフィックバーストで構成されたバイト数の最大持続トラフィックレートで定義されているレートよりも高い（時には大幅に高い）レートでサービスをバーストできます。最大持続トラフィックレート。
Mathematically, what is enforced is that the traffic placed on the DOCSIS link in the time interval (t1,t2) complies with the following rate-shaping equations:
数学的には、時間間隔（t1、t2）でDOCSISリンクに配置されたトラフィックが次のレートシェーピングの方程式に準拠していることが強制されます。
TxBytes(t1,t2) <= (t2-t1)*R/8 + B
TxBytes(t1,t2) <= (t2-t1)*P/8 + 1522
for all values t2>t1, where:
すべての値t2> t1の場合：
R = Maximum Sustained Traffic Rate (bps)
R =最大持続トラフィックレート（bps）
P = Peak Traffic Rate (bps)
P =ピークトラフィックレート（bps）
B = Maximum Traffic Burst (bytes)
B =最大トラフィックバースト（バイト）
The result of this configuration is that the link rate available to the Service Flow varies based on the pattern of load. If the load that the Service Flow places on the link is less than the Maximum Sustained Traffic Rate, the Service Flow "earns" credit that it can then use (should the load increase) to burst at the Peak Traffic Rate. This dynamic is important since these rate changes (particularly the decrease in data rate once the traffic burst credit is exhausted) can induce a step increase in buffering latency.
この構成の結果、サービスフローで使用できるリンクレートは、負荷のパターンに基づいて変化します。サービスフローがリンクに加える負荷が最大持続トラフィックレートよりも小さい場合、サービスフローはクレジットを「獲得」し、それを使用して（負荷が増加した場合）ピークトラフィックレートでバーストできます。これらのレート変更（特に、トラフィックバーストクレジットが使い果たされた後のデータレートの低下）は、バッファリングのレイテンシを段階的に増加させる可能性があるため、このダイナミックは重要です。
There are a number of differences between the version of the PIE algorithm that is mandated for cable modems in the DOCSIS specifications and the version described in [RFC8033]. These differences are described in the following subsections.
DOCSIS仕様のケーブルモデムに必須のPIEアルゴリズムのバージョンと、[RFC8033]で説明されているバージョンとの間には、いくつかの違いがあります。これらの違いについては、次のサブセクションで説明します。
The latency target (a.k.a. delay reference) is a key parameter that affects, among other things, the trade-off in performance between latency-sensitive applications and bulk TCP applications. Via simulation studies, a value of 10 ms was identified as providing a good balance of performance. However, it is recognized that there may be service offerings for which this value doesn't provide the best performance balance. As a result, this is provided as a configuration parameter that the operator can set independently on each upstream Service Flow. If not explicitly set by the operator, the modem will use 10 ms as the default value.
レイテンシターゲット（別名、遅延参照）は、特にレイテンシの影響を受けやすいアプリケーションとバルクTCPアプリケーションの間のパフォーマンスのトレードオフに影響を与える重要なパラメーターです。シミュレーション調査により、10 msの値がパフォーマンスのバランスが取れていることが確認されました。ただし、この値では最高のパフォーマンスバランスが得られないサービスオファリングが存在する可能性があることが認識されています。その結果、これは、オペレータが各アップストリームサービスフローで個別に設定できる設定パラメータとして提供されます。オペレーターが明示的に設定しない場合、モデムはデフォルト値として10ミリ秒を使用します。
The PIE algorithm utilizes a departure rate estimator to track fluctuations in the egress rate for the queue and to generate a smoothed estimate of this rate for use in the drop probability calculation. This estimator may be well suited to many link technologies but is not ideal for DOCSIS upstream links for a number of reasons.
PIEアルゴリズムは、逸脱率推定器を利用して、キューの出口レートの変動を追跡し、この確率の平滑化された推定値を生成して、ドロップ確率の計算に使用します。この推定量は多くのリンクテクノロジーに適していますが、さまざまな理由から、DOCSISアップストリームリンクには理想的ではありません。
First, the bursty nature of the upstream transmissions, in which the queue drains at line rate (up to ~100 Mbps for DOCSIS 3.0 and ~1 Gbps for DOCSIS 3.1) and then is blocked until the next transmit opportunity, results in the potential for inaccuracy in measurement, given that the PIE departure rate estimator starts each measurement during a transmission burst and ends each measurement during a (possibly different) transmission burst. For example, in the case where the start and end of measurement occur within a single burst, the PIE estimator will calculate the egress rate to be equal to the line rate, rather than the average rate available to the modem.
まず、アップストリーム伝送のバースト性の性質で、キューはラインレート（DOCSIS 3.0の場合は最大100 Mbps、DOCSIS 3.1の場合は最大1 Gbps）でドレインし、次の送信機会までブロックされるため、次の可能性があります。 PIE逸脱率推定器が送信バースト中に各測定を開始し、（場合によっては異なる）送信バースト中に各測定を終了する場合、測定の不正確さ。たとえば、測定の開始と終了が1つのバースト内で発生する場合、PIE推定器は、モデムで利用可能な平均レートではなく、出力レートをラインレートと等しくなるように計算します。
Second, the latency introduced by the DOCSIS request-grant mechanism can result in some further inaccuracy. In typical conditions, the request-grant mechanism can add between ~4 ms and ~8 ms of latency to the forwarding of upstream traffic. Within that range, the amount of additional latency that affects any individual data burst is effectively random, being influenced by the arrival time of the burst relative to the next request transmit opportunity, among other factors.
第2に、DOCSIS要求許可メカニズムによって発生する遅延により、さらに不正確になる可能性があります。通常の条件では、要求許可メカニズムにより、アップストリームトラフィックの転送に4ミリ秒から8ミリ秒の遅延が追加される可能性があります。その範囲内で、個々のデータバーストに影響を与える追加のレイテンシの量は事実上ランダムであり、他の要因の中でも、次の要求送信機会に対するバーストの到着時間の影響を受けます。
Third, in the significant majority of cases, the departure rate, while variable, is controlled by the modem itself via the pair of token bucket rate-shaping equations described in Section 3. Together, these two equations enforce a Maximum Sustained Traffic Rate, a Peak Traffic Rate, and a Maximum Traffic Burst size for the modem's requested bandwidth. The implication of this is that the modem, in the significant majority of cases, will know precisely what the departure rate will be and can predict exactly when transitions between the Peak Traffic Rate and Maximum Sustained Traffic Rate will occur. Compare this to the PIE estimator, which would be simply reacting to (and smoothing its estimate of) those rate transitions after the fact.
第3に、ほとんどの場合、逸脱率は可変ですが、セクション3で説明したトークンバケットレートシェーピング方程式のペアを介してモデム自体によって制御されます。これらの2つの方程式により、最大持続トラフィックレートが強制されます。ピークトラフィックレート、およびモデムが要求する帯域幅の最大トラフィックバーストサイズ。これが意味することは、ほとんどの場合、モデムが逸脱率を正確に把握し、ピークトラフィックレートと最大持続トラフィックレートの間の遷移が発生するタイミングを正確に予測できることです。これをPIE推定器と比較してください。PIE推定器は、事後にこれらのレート遷移に単に反応し、その推定値を平滑化します。
Finally, since the modem is already implementing the dual-token bucket traffic shaper, it contains enough internal state to calculate predicted queuing delay with a minimum of computations. Furthermore, these computations only need to be run at every drop probability update interval, as opposed to the PIE estimator, which runs a similar number of computations on each packet dequeue event.
最後に、モデムはすでにデュアルトークンバケットトラフィックシェーパーを実装しているため、最小限の計算で予測されるキューイング遅延を計算するのに十分な内部状態が含まれています。さらに、これらの計算は、各パケットデキューイベントで同様の数の計算を実行するPIEエスティメータとは対照的に、すべてのドロップ確率更新間隔で実行する必要があるだけです。
For these reasons, the DOCSIS-PIE algorithm utilizes the configuration and state of the dual-token bucket traffic shaper to translate queue depth into predicted queuing delay, rather than implementing the departure rate estimator defined in PIE.
これらの理由により、DOCSIS-PIEアルゴリズムは、デュアルトークンバケットトラフィックシェーパーの構成と状態を利用して、PIEで定義された出発率推定器を実装するのではなく、キューの深さを予測されたキューイング遅延に変換します。
The PIE algorithm [RFC8033] has two states: INACTIVE and ACTIVE. During the INACTIVE state, AQM packet drops are suppressed. The algorithm transitions to the ACTIVE state when the queue exceeds 1/3 of the buffer size. Upon transition to the ACTIVE state, PIE includes a burst protection feature in which the AQM packet drops are suppressed for the first 150 ms. Since DOCSIS-PIE is predominantly deployed on consumer broadband connections, a more sophisticated burst protection was developed to provide better performance in the presence of a single TCP session.
PIEアルゴリズム[RFC8033]には、非アクティブとアクティブの2つの状態があります。 INACTIVE状態の間、AQMパケットのドロップは抑制されます。キューがバッファサイズの1/3を超えると、アルゴリズムはACTIVE状態に移行します。アクティブ状態に移行すると、PIEにはバースト保護機能が含まれ、最初の150ミリ秒間はAQMパケットのドロップが抑制されます。 DOCSIS-PIEは主にコンシューマブロードバンド接続に展開されるため、より洗練されたバースト保護が開発され、単一のTCPセッションの存在下でより優れたパフォーマンスを提供します。
Where the PIE algorithm has two states, DOCSIS-PIE has three. The INACTIVE and ACTIVE states in DOCSIS-PIE are identical to those states in PIE. The QUIESCENT state is a transitional state between INACTIVE and ACTIVE. The DOCSIS-PIE algorithm transitions from INACTIVE to QUIESCENT when the queue exceeds 1/3 of the buffer size. In the QUIESCENT state, packet drops are immediately enabled, and upon the first packet drop, the algorithm transitions to the ACTIVE state (where drop probability is reset to zero for the 150 ms duration of the burst protection as in PIE). From the ACTIVE state, the algorithm transitions to QUIESCENT if the drop probability has decayed to zero and the queuing latency has been less than half of the LATENCY_TARGET for two update intervals. The algorithm then fully resets to the INACTIVE state if this "quiet" condition exists for the duration of the BURST_RESET_TIMEOUT (1 second). One end result of the addition of the QUIESCENT state is that a single packet drop can occur relatively early on during an initial burst, whereas all drops would be suppressed for at least 150 ms of the burst duration in PIE. The other end result is that if traffic stops and then resumes within 1 second, DOCSIS-PIE can directly drop a single packet and then re-enter burst protection, whereas PIE would require that the buffer exceed 1/3 full.
PIEアルゴリズムに2つの状態がある場合、DOCSIS-PIEには3つの状態があります。 DOCSIS-PIEのINACTIVEおよびACTIVE状態は、PIEのそれらの状態と同じです。 QUIESCENT状態は、INACTIVEとACTIVEの間の移行状態です。キューがバッファサイズの1/3を超えると、DOCSIS-PIEアルゴリズムはINACTIVEからQUIESCENTに移行します。 QUIESCENT状態では、パケットドロップがすぐに有効になり、最初のパケットドロップ時に、アルゴリズムはACTIVE状態に移行します（PIEと同様に、バースト保護の150ミリ秒の間、ドロップ確率がゼロにリセットされます）。ドロップ確率がゼロに減衰し、2つの更新間隔でキューイング遅延がLATENCY_TARGETの半分未満の場合、ACTIVE状態からアルゴリズムはQUIESCENTに移行します。次に、この「静かな」状態がBURST_RESET_TIMEOUTの間（1秒）存在する場合、アルゴリズムは完全にINACTIVE状態にリセットされます。 QUIESCENT状態が追加された結果、1つのパケットドロップが初期バーストの比較的早い段階で発生する可能性がありますが、PIEでは、バースト期間の少なくとも150ミリ秒の間、すべてのドロップが抑制されます。もう1つの最終結果は、トラフィックが停止してから1秒以内に再開した場合、DOCSIS-PIEは単一のパケットを直接ドロップしてバースト保護に再び入ることができるのに対し、PIEはバッファが1/3を超える必要があることを要求します。
The PIE algorithm scales the Proportional and Integral coefficients based on the current drop probability. The DOCSIS-PIE algorithm extends this scaling to cover values of drop probability greater than 1, which can occur as a result of the drop probability scaling function described in Section 4.6. As an example, if a flood of non-responsive 64-byte packets were to arrive at a rate that is twice the departure rate, the DOCSIS-PIE steady-state condition would be to drop 50% of these packets, which implies that drop probability would have the value of 8.00.
PIEアルゴリズムは、現在のドロップ確率に基づいて、比例係数と積分係数をスケーリングします。 DOCSIS-PIEアルゴリズムは、このスケーリングを拡張して、1より大きいドロップ確率の値をカバーします。これは、セクション4.6で説明されているドロップ確率スケーリング関数の結果として発生する可能性があります。例として、応答のない64バイトのパケットのフラッドが、出発レートの2倍のレートで到着した場合、DOCSIS-PIEの定常状態は、これらのパケットの50％をドロップすることであり、そのドロップを意味します。確率は8.00の値になります。
The PIE algorithm includes a mechanism by which the drop probability is allowed to decay exponentially (rather than linearly) when it is detected that the buffer is empty. In the DOCSIS case, recently arrived packets may reside in the buffer due to the request-grant latency even if the link is effectively idle. As a result, the buffer may not be identically empty in the situations for which the exponential decay is intended. To compensate for this, we trigger exponential decay when the buffer occupancy is less than 5 ms * Peak Traffic Rate.
PIEアルゴリズムには、バッファーが空であることが検出されたときに、ドロップ確率が（線形ではなく）指数関数的に減衰するメカニズムが含まれています。 DOCSISの場合、リンクが実質的にアイドル状態であっても、要求許可レイテンシが原因で、最近到着したパケットがバッファに存在する可能性があります。その結果、指数関数的減衰が意図されている状況では、バッファがまったく空にならない場合があります。これを補正するために、バッファ占有率が5 ms *ピークトラフィックレート未満の場合、指数関数的減衰をトリガーします。
The DOCSIS-PIE algorithm scales the calculated drop probability based on the ratio of the packet size to a constant value of 1024 bytes (representing approximate average packet size). While [RFC7567] in general recommends against this type of scaling, we note that DOCSIS-PIE is expected to be used predominantly to manage upstream queues in residential broadband deployments, where we believe the benefits outweigh the disadvantages. As a safeguard to prevent a flood of small packets from starving flows that use larger packets, DOCSIS-PIE limits the scaled probability to a defined maximum value of 0.85.
DOCSIS-PIEアルゴリズムは、1024バイトの定数値（おおよその平均パケットサイズを表す）に対するパケットサイズの比率に基づいて、計算された廃棄確率をスケーリングします。 [RFC7567]は一般にこのタイプのスケーリングを推奨しませんが、DOCSIS-PIEは主に住宅用ブロードバンド展開のアップストリームキューを管理するために使用されると予想されているため、メリットがデメリットを上回ると考えています。大きなパケットを使用するフローが不足することによる小さなパケットのフラッドを防ぐための安全策として、DOCSIS-PIEは、スケーリングされた確率を定義された最大値0.85に制限します。
DOCSIS-PIE does not include support for Explicit Congestion Notification (ECN). Cable modems are essentially IEEE 802.1d Ethernet bridges and so are not designed to modify IP header fields. Additionally, the packet-processing pipeline in a cable modem is commonly implemented in hardware. As a result, introducing support for ECN would engender a significant redesign of cable modem data path hardware, and would be difficult or impossible to modify in the future. At the time of the development of DOCSIS-PIE, which coincided with the development of modem chip designs, the benefits of ECN marking relative to packet drop were considered to be relatively minor; there was considerable discussion about differential treatment of ECN-capable packets in the AQM drop/mark decision, and there were some initial suggestions that a new ECN approach was needed. Due to this uncertainty, we chose not to include support for ECN.
DOCSIS-PIEには、明示的輻輳通知（ECN）のサポートは含まれていません。ケーブルモデムは基本的にIEEE 802.1dイーサネットブリッジであるため、IPヘッダーフィールドを変更するようには設計されていません。さらに、ケーブルモデムのパケット処理パイプラインは通常、ハードウェアに実装されます。その結果、ECNのサポートを導入すると、ケーブルモデムのデータパスハードウェアが大幅に再設計され、将来変更することが困難または不可能になります。モデムチップ設計の開発と一致したDOCSIS-PIEの開発時には、パケットドロップに対するECNマーキングの利点は比較的小さいと考えられていました。 AQMドロップ/マークの決定におけるECN対応パケットの差別的な扱いについてかなりの議論があり、新しいECNアプローチが必要であるという最初の提案がいくつかありました。この不確実性のため、ECNのサポートを含めないことにしました。
The AQM space is an evolving one, and it is expected that continued research in this field may result in improved algorithms in the future.
AQM空間は進化している空間であり、この分野での継続的な研究により、将来的にはアルゴリズムが改善されることが予想されます。
As part of defining the DOCSIS-PIE algorithm, we split the pseudocode definition into two components: a "data path" component and a "control path" component. The control path component contains the packet drop probability update functionality, whereas the data path component contains the per-packet operations, including the drop decision logic.
DOCSIS-PIEアルゴリズムを定義する一環として、疑似コード定義を「データパス」コンポーネントと「制御パス」コンポーネントの2つのコンポーネントに分割します。制御パスコンポーネントにはパケットドロップ確率更新機能が含まれていますが、データパスコンポーネントにはドロップ決定ロジックを含むパケットごとの操作が含まれています。
It is understood that some aspects of the cable modem implementation may be done in hardware, particularly functions that handle packet processing.
ケーブルモデム実装のいくつかの側面は、ハードウェア、特にパケット処理を処理する機能で実行できることを理解してください。
While the DOCSIS specifications don't mandate the internal implementation details of the cable modem, modem implementers are strongly advised against implementing the control path functionality in hardware. The intent of this advice is to retain the possibility that future improvements in AQM algorithms can be accommodated via software updates to deployed devices.
DOCSIS仕様はケーブルモデムの内部実装の詳細を義務付けていませんが、モデムの実装者は、ハードウェアに制御パス機能を実装しないことを強くお勧めします。このアドバイスの目的は、AQMアルゴリズムの将来の改善が、展開されたデバイスへのソフトウェアの更新によって対応できる可能性を保持することです。
This document describes an active queue management algorithm based on [RFC8033] for implementation in DOCSIS cable modem devices. This algorithm introduces no specific security exposures.
このドキュメントでは、DOCSISケーブルモデムデバイスに実装するための[RFC8033]に基づくアクティブキュー管理アルゴリズムについて説明します。このアルゴリズムは、特定の機密漏れをもたらしません。
[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, <http://www.rfc-editor.org/info/rfc8033>.
[RFC8033]パン、R、ナタラジャン、P、ベイカー、F、Gホワイト、2017年2月、<http://www.rfc-editor.org/info/rfc8033>。
[CommMag] White, G., "Active queue management in DOCSIS 3.1 networks", IEEE Communications Magazine vol. 53, no. 3, pp. 126-132, DOI 10.1109/MCOM.2015.7060493, March 2015.
[CommMag]ホワイト、G。、「DOCSIS 3.1ネットワークにおけるアクティブキュー管理」、IEEE Communications Magazine vol。 53、いいえ。 3、pp。126-132、DOI 10.1109 / MCOM.2015.7060493、2015年3月。
[DOCSIS-AQM] White, G., "Active Queue Management in DOCSIS 3.x Cable Modems", May 2014, <http://www.cablelabs.com/ wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf>.
[DOCSIS-AQM]ホワイト、G。、「DOCSIS 3.xケーブルモデムでのアクティブキュー管理」、2014年5月、<http://www.cablelabs.com/ wp-content / uploads / 2014/06 / DOCSIS-AQM_May2014 .pdf>。
[DOCSIS_3.0] CableLabs, "MAC and Upper Layer Protocols Interface Specification", DOCSIS 3.0, January 2017, <https://apps.cablelabs.com/specification/ CM-SP-MULPIv3.0>.
[DOCSIS_3.0] CableLabs、「MAC and Upper Layer Protocols Interface Specification」、DOCSIS 3.0、2017年1月、<https://apps.cablelabs.com/specification/ CM-SP-MULPIv3.0>。
[DOCSIS_3.1] CableLabs, "MAC and Upper Layer Protocols Interface Specification", DOCSIS 3.1, January 2017, <https://apps.cablelabs.com/specification/ CM-SP-MULPIv3.1>.
[DOCSIS_3.1] CableLabs、「MAC and Upper Layer Protocols Interface Specification」、DOCSIS 3.1、2017年1月、<https://apps.cablelabs.com/specification/ CM-SP-MULPIv3.1>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<http://www.rfc-editor.org/info/rfc7567>。
PIE defines two functions organized here into two design blocks:
PIEは、ここで2つの設計ブロックに編成された2つの機能を定義します。
1. Control path block -- a periodically running algorithm that calculates a drop probability based on the estimated queuing latency and queuing latency trend.
1. 制御パスブロック-キューイングレイテンシの推定値とキューイングレイテンシの傾向に基づいてドロップ確率を計算する定期的に実行されるアルゴリズム。
2. Data path block, a function that occurs on each packet enqueue that implements a per-packet drop decision based on the drop probability.
2. データパスブロック。ドロップ確率に基づいてパケットごとのドロップ決定を実装する、各パケットエンキューで発生する関数。
It is desirable to have the ability to update the control path block based on operational experience with PIE deployments.
PIE展開の運用経験に基づいて制御パスブロックを更新する機能があることが望ましいです。
o LATENCY_TARGET. AQM Latency Target for this Service Flow
o LATENCY_TARGET。このサービスフローのAQMレイテンシターゲット
o PEAK_RATE. Service Flow configured Peak Traffic Rate, expressed in bytes/second
o PEAK_RATE。バイト/秒で表されるサービスフロー構成ピークトラフィックレート
o MSR. Service Flow configured Maximum Sustained Traffic Rate, expressed in bytes/second
o MSR。サービスフローの構成された最大持続トラフィックレート（バイト/秒で表示）
o BUFFER_SIZE. The size (in bytes) of the buffer for this Service Flow
o バッファサイズ。このサービスフローのバッファのサイズ（バイト単位）
o A = 0.25, B = 2.5. Weights in the drop probability calculation
o A = 0.25、B = 2.5。ドロップ確率計算の重み
o INTERVAL = 16 ms. Update interval for drop probability
o インターバル= 16 ms。ドロップ確率の更新間隔
o BURST_RESET_TIMEOUT = 1 second
o BURST_RESET_TIMEOUT = 1秒
o MAX_BURST = 142 ms (150 ms - 8 ms (update error))
o MAX_BURST = 142 ms（150 ms-8 ms（更新エラー））
o MEAN_PKTSIZE = 1024 bytes
o MEAN_PKTSIZE = 1024バイト
o MIN_PKTSIZE = 64 bytes
o MIN_PKTSIZE = 64バイト
o PROB_LOW = 0.85
o PROB_LOW = 0.85
o PROB_HIGH = 8.5 o LATENCY_LOW = 5 ms
o PROB_HIGH = 8.5 o LATENCY_LOW = 5 ms
o LATENCY_HIGH = 200 ms
o LATENCY_HIGH = 200ミリ秒
o drop_prob_. The current packet drop probability
o drop_prob_。現在のパケットドロップ確率
o accu_prob_. Accumulated drop probability since last drop
o accu_prob_。最後のドロップ以降の累積ドロップ確率
o qdelay_old_. The previous queue delay estimate
o qdelay_old_。以前のキュー遅延の見積もり
o burst_allowance_. Countdown for burst protection, initialize to 0
o burst_allowance_。バースト保護のカウントダウン、0に初期化
o burst_reset_. Counter to reset burst
o burst_reset_。バーストをリセットするためのカウンター
o aqm_state_. AQM activity state encoding 3 states:
o aqm_state_。 AQMアクティビティ状態エンコード3状態：
INACTIVE - Queue staying below 1/3 full, suppress AQM drops
INACTIVE-キューは1/3未満にとどまり、AQMドロップを抑制します
QUIESCENT - Transition state
QUIESCENT-遷移状態
ACTIVE - Normal AQM drops (after burst protection period)
アクティブ-通常のAQMドロップ（バースト保護期間後）
o queue_. Holds the pending packets
o キュー_。保留中のパケットを保持します
o drop(packet). Drops/discards a packet
o ドロップ（パケット）。パケットをドロップ/破棄します
o random(). Returns a uniform random value in the range 0 ~ 1
o ランダム()。 0〜1の範囲の一様なランダム値を返します
o queue_.is_full(). Returns true if queue_ is full
o queue_.is_full()。 queue_がいっぱいの場合にtrueを返します
o queue_.byte_length(). Returns current queue_ length in bytes, including all MAC PDU bytes without DOCSIS MAC overhead
o queue_.byte_length()。 DOCSIS MACオーバーヘッドのないすべてのMAC PDUバイトを含む、現在のqueue_長さをバイトで返します
o queue_.enque(packet). Adds packet to tail of queue_
o queue_.enque（パケット）。キューの末尾にパケットを追加します_
o msrtokens(). Returns current token credits (in bytes) from the Maximum Sustained Traffic Rate token bucket
o msrtokens()。最大持続トラフィックレートトークンバケットから現在のトークンクレジット（バイト単位）を返します
o packet.size(). Returns size of packet
o packet.size()。パケットのサイズを返します
The DOCSIS-PIE control path performs the following:
DOCSIS-PIE制御パスは、次のことを実行します。
o Calls control_path_init() at Service Flow creation
o サービスフローの作成時にcontrol_path_init()を呼び出す
o Calls calculate_drop_prob() at a regular INTERVAL (16 ms)
o 通常の間隔（16ミリ秒）でcalculate_drop_prob()を呼び出します。
================
// Initialization function
control_path_init() {
drop_prob_ = 0;
qdelay_old_ = 0;
burst_reset_ = 0;
aqm_state_ = INACTIVE;
}
// Background update, occurs every INTERVAL
calculate_drop_prob() {
if (queue_.byte_length() <= msrtokens()) {
qdelay = queue_.byte_length() / PEAK_RATE;
} else {
qdelay = ((queue_.byte_length() - msrtokens()) / MSR \
+ msrtokens() / PEAK_RATE);
}
if (burst_allowance_ > 0) {
drop_prob_ = 0;
burst_allowance_ = max(0, burst_allowance_ - INTERVAL);
} else {
p = A * (qdelay - LATENCY_TARGET) + \
B * (qdelay - qdelay_old_);
// Since A=0.25 & B=2.5, can be implemented
// with shift and add
if (drop_prob_ < 0.000001) {
p /= 2048;
} else if (drop_prob_ < 0.00001) {
p /= 512;
} else if (drop_prob_ < 0.0001) {
p /= 128;
} else if (drop_prob_ < 0.001) {
p /= 32;
} else if (drop_prob_ < 0.01) {
p /= 8;
} else if (drop_prob_ < 0.1) {
p /= 2;
} else if (drop_prob_ < 1) {
p /= 0.5;
} else if (drop_prob_ < 10) {
p /= 0.125;
} else {
p /= 0.03125;
}
if ((drop_prob_ >= 0.1) && (p > 0.02)) {
p = 0.02;
}
drop_prob_ += p;
/* some special cases */
if (qdelay < LATENCY_LOW && qdelay_old_ < LATENCY_LOW) {
drop_prob_ *= 0.98; // exponential decay
} else if (qdelay > LATENCY_HIGH) {
drop_prob_ += 0.02; // ramp up quickly
}
drop_prob_ = max(0, drop_prob_);
drop_prob_ = min(drop_prob_, \
PROB_LOW * MEAN_PKTSIZE/MIN_PKTSIZE);
}
// Check if all is quiet
quiet = (qdelay < 0.5 * LATENCY_TARGET)
&& (qdelay_old_ < 0.5 * LATENCY_TARGET)
&& (drop_prob_ == 0)
&& (burst_allowance_ == 0);
// Update AQM state based on quiet or !quiet
if ((aqm_state_ == ACTIVE) && quiet) {
aqm_state_ = QUIESCENT;
burst_reset_ = 0;
} else if (aqm_state_ == QUIESCENT) {
if (quiet) {
burst_reset_ += INTERVAL ;
if (burst_reset_ > BURST_RESET_TIMEOUT) {
burst_reset_ = 0;
aqm_state_ = INACTIVE;
}
} else {
burst_reset_ = 0;
}
}
qdelay_old_ = qdelay;
}
｝
The DOCSIS-PIE data path performs the following:
DOCSIS-PIEデータパスは、次のことを実行します。
o Calls enque() in response to an incoming packet from the CMCI
o CMCIからの着信パケットに応答してenqueue()を呼び出します
================
enque(packet) {
if (queue_.is_full()) {
drop(packet);
accu_prob_ = 0;
} else if (drop_early(packet, queue_.byte_length())) {
drop(packet);
} else {
queue_.enque(packet);
}
}
////////////////
drop_early(packet, queue_length) {
// if still in burst protection, suppress AQM drops
if (burst_allowance_ > 0) {
return FALSE;
}
// if drop_prob_ goes to zero, clear accu_prob_
if (drop_prob_ == 0) {
accu_prob_ = 0;
}
if (aqm_state_ == INACTIVE) {
if (queue_.byte_length() < BUFFER_SIZE/3) {
// if queue is still small, stay in
// INACTIVE state and suppress AQM drops
return FALSE;
} else {
// otherwise transition to QUIESCENT state
aqm_state_ = QUIESCENT;
}
}
//The CM can quantize packet.size to 64, 128, 256, 512, 768,
// 1024, 1280, 1536, 2048 in the calculation below
p1 = drop_prob_ * packet.size() / MEAN_PKTSIZE;
p1 = min(p1, PROB_LOW);
accu_prob_ += p1;
// Suppress AQM drops in certain situations
if ( (qdelay_old_ < 0.5 * LATENCY_TARGET && drop_prob_ < 0.2)
|| (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) {
return FALSE;
}
if (accu_prob_ < PROB_LOW) { // avoid dropping too fast due
return FALSE; // to bad luck of coin tosses...
} else if (accu_prob_ >= PROB_HIGH) { // ...and avoid dropping
drop = TRUE; // too slowly
} else { //Random drop
double u = random(); // 0 ~ 1
if (u > p1)
return FALSE;
else
drop = TRUE;
}
// At this point, drop == TRUE, so packet will be dropped.
//この時点で、drop == TRUEなので、パケットはドロップされます。
// Reset accu_prob_
accu_prob_ = 0;
// If in QUIESCENT state, packet drop triggers
// ACTIVE state and start of burst protection
if (aqm_state_ == QUIESCENT) {
aqm_state_ = ACTIVE;
burst_allowance_ = MAX_BURST;
}
return TRUE;
}
Authors' Addresses
著者のアドレス
Greg White CableLabs 858 Coal Creek Circle Louisville, CO 80027-9750 United States of America
Greg White CableLabs 858 Coal Creek Circle Louisville、CO 80027-9750アメリカ合衆国
Email: g.white@cablelabs.com
Rong Pan Cisco Systems 510 McCarthy Blvd Milpitas, CA 95134 United States of America
Rong Pan Cisco Systems 510 McCarthy Blvd Milpitas、CA 95134アメリカ合衆国
Email: ropan@cisco.com