Internet Engineering Task Force (IETF) G. White
Request for Comments: 8034 CableLabs
Category: Informational R. Pan
ISSN: 2070-1721 Cisco Systems
February 2017
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
基于比例积分控制器增强型（PIE）的主动队列管理（AQM）用于有线数据服务接口规范（DOCSIS）有线调制解调器
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.
基于有线数据服务接口规范（DOCSI）的有线调制解调器为全球超过一亿用户提供宽带互联网接入。在某些情况下，电缆调制解调器连接是客户与Internet之间的瓶颈（最低速度）链路。因此，电缆调制解调器中缓冲和缓冲膨胀的影响会对用户体验产生重大影响。CableLabs DOCSIS 3.1规范引入了对电缆调制解调器的要求，以支持主动队列管理（AQM）算法，该算法旨在减轻缓冲对延迟敏感流量的影响，同时保持批量吞吐量性能。此外，CableLabs DOCSIS 3.0规范也进行了修订，以包含类似要求。本文件描述了适用于DOCSIS设备的AQM要求，包括对DOCSIS 3.1电缆调制解调器所需的“DOCSIS-PIE”算法的描述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate 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 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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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算法提供非常好的拥塞反馈，同时还具有操作简单性和低复杂性。根据DOCSIS 3.1规范[DOCSIS_3.1]构建的电缆调制解调器需要选择其中一种算法。电缆数据服务接口规范（DOCSI）定义了在全球范围内为混合光纤同轴电缆系统上的以太网和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]要求电缆调制解调器实现比例积分控制器增强（PIE）AQM算法的特定变体[RFC8033]。附录A中提供了该特定变体以供参考，并在[CommMag]和[DOCSIS-AQM]中给出了将其与掉尾队列和其他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参数集，该参数集定义了对穿过服务流的数据包的处理。这些参数包括，例如，最小保留流量率、最大持续流量率、峰值流量率、最大流量突发和流量优先级。每个上行业务流对应于电缆调制解调器中的队列，每个下行业务流对应于CMT中的队列。DOCSIS AQM要求CM和CMT在每个服务流队列上独立地实施AQM算法（并允许在需要时禁用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)*R/8 + B
TxBytes(t1,t2) <= (t2-t1)*P/8 + 1522
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偏离率估计器在传输突发期间开始每个测量，并在（可能不同的）传输突发期间结束每个测量。例如，在测量的开始和结束发生在单个突发内的情况下，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.
其次，DOCSIS请求授权机制引入的延迟可能会导致进一步的不准确。在典型情况下，请求授权机制可以为上行流量的转发增加约4 ms到约8 ms的延迟。在该范围内，影响任何单个数据突发的额外延迟量实际上是随机的，受突发相对于下一个请求传输机会的到达时间以及其他因素的影响。
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节中描述的令牌桶速率成形方程对其进行控制。这两个方程共同强制调制解调器请求带宽的最大持续流量率、峰值流量率和最大流量突发大小。这意味着，在绝大多数情况下，调制解调器将准确地知道发车率是多少，并且能够准确地预测峰值交通率和最大持续交通率之间的转换将在何时发生。将此与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估计器相反，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]有两种状态：非活动和活动。在非活动状态期间，抑制AQM分组丢弃。当队列超过缓冲区大小的1/3时，算法将转换为活动状态。在转换到活动状态时，PIE包括突发保护功能，其中AQM数据包丢弃在前150毫秒内被抑制。由于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算法有两种状态时，DOCSIS-PIE有三种状态。DOCSIS-PIE中的非活动和活动状态与PIE中的状态相同。静止状态是非活动和活动之间的过渡状态。当队列超过缓冲区大小的1/3时，DOCSIS-PIE算法将从非活动变为静态。在静态状态下，立即启用数据包丢弃，并且在第一次数据包丢弃时，算法转换到活动状态（在PIE中，在突发保护的150 ms持续时间内，丢弃概率重置为零）。如果丢弃概率已衰减为零，并且在两个更新间隔内排队等待时间小于延迟_目标的一半，则该算法将从活动状态转换为静态。如果在突发重置超时（1秒）期间存在此“安静”条件，则算法将完全重置为非活动状态。添加静态状态的一个最终结果是，在初始突发期间，单个分组丢弃可以相对较早地发生，而在PIE中，所有丢弃都将被抑制至少150 ms的突发持续时间。另一个最终结果是，如果流量停止，然后在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
PIE算法根据电流下降概率缩放比例系数和积分系数。DOCSIS-PIE算法扩展了该比例，以覆盖坠落概率大于1的值，这可能是第4.6节所述坠落概率比例函数的结果。例如，如果大量无响应的64字节数据包以两倍于
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.
离开率，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情况下，由于请求许可延迟，即使链路实际上处于空闲状态，最近到达的数据包也可能驻留在缓冲区中。因此，在预期指数衰减的情况下，缓冲区可能不完全为空。为了补偿这一点，我们在缓冲区占用率小于5ms*峰值流量率时触发指数衰减。
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算法的一部分，我们将伪代码定义分为两个组件：“数据路径”组件和“控制路径”组件。控制路径组件包含分组丢弃概率更新功能，而数据路径组件包含每个分组的操作，包括丢弃决策逻辑。
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.
本文档描述了一种基于[RFC8033]的主动队列管理算法，用于在DOCSIS电缆调制解调器设备中实现。该算法不引入特定的安全暴露。
[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]Pan，R.，Natarajan，P.，Baker，F.，和G.White，“增强型比例积分控制器（PIE）：解决缓冲区膨胀问题的轻型控制方案”，RFC 8033，DOI 10.17487/RFC8033，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]White，G.，“DOCSIS 3.1网络中的主动队列管理”，《IEEE通信杂志》第53卷，第3期，第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]White，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和上层协议接口规范”，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和上层协议接口规范”，DOCSIS 3.12017年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]Baker，F.，Ed.和G.Fairhurst，Ed.，“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定义了两个功能，在这里组织为两个设计块：
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 潜伏期是你的目标。此服务流的AQM延迟目标
o PEAK_RATE. Service Flow configured Peak Traffic Rate, expressed in bytes/second
o 最高利率。服务流配置的峰值流量率，以字节/秒表示
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毫秒。跌落概率的更新间隔
o BURST_RESET_TIMEOUT = 1 second
o 突发\重置\超时=1秒
o MAX_BURST = 142 ms (150 ms - 8 ms (update error))
o 最大脉冲群=142毫秒（150毫秒-8毫秒（更新错误））
o MEAN_PKTSIZE = 1024 bytes
o 平均值=1024字节
o MIN_PKTSIZE = 64 bytes
o 最小值=64字节
o PROB_LOW = 0.85
o 概率低=0.85
o PROB_HIGH = 8.5
o 概率高=8.5
o LATENCY_LOW = 5 ms
o 延迟低=5毫秒
o LATENCY_HIGH = 200 ms
o 延迟\u高=200毫秒
o drop_prob_. The current packet drop probability
o 放下你的问题。当前丢包概率
o accu_prob_. Accumulated drop probability since last drop
o 累计故障。自上次下降以来的累计下降概率
o qdelay_old_. The previous queue delay estimate
o qdelay_old_。前一个队列延迟估计
o burst_allowance_. Countdown for burst protection, initialize to 0
o 爆裂。突发保护倒计时，初始化为0
o burst_reset_. Counter to reset burst
o 突发重置。计数器重置脉冲串
o aqm_state_. AQM activity state encoding 3 states:
o aqm_州。AQM活动状态编码3个状态：
INACTIVE - Queue staying below 1/3 full, suppress AQM drops
非活动-队列保持在满1/3以下，抑制AQM丢弃
QUIESCENT - Transition state
静态过渡态
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 队列已满（）。如果队列已满，则返回true
o queue_.byte_length(). Returns current queue_ length in bytes, including all MAC PDU bytes without DOCSIS MAC overhead
o 队列长度。字节长度（）。返回以字节为单位的当前队列长度，包括所有没有DOCSIS MAC开销的MAC PDU字节
o queue_.enque(packet). Adds packet to tail of queue_
o 队列（数据包）。将数据包添加到队列尾部_
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;
}
// 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() {
// 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 (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 {
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
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;
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;
}
} 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;
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
}
/* 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);
}
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);
// 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;
}
}
// 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;
qdelay\u old\uqdelay；
}
}
The DOCSIS-PIE data path performs the following:
DOCSIS-PIE数据路径执行以下操作：
o Calls enque() in response to an incoming packet from the CMCI
o 调用enque（）以响应来自CMCI的传入数据包
================
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);
}
}
================
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) {
////////////////
drop_early(packet, queue_length) {
// if still in burst protection, suppress AQM drops
if (burst_allowance_ > 0) {
return FALSE;
}
// 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 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;
}
}
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
//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);
p1 = drop_prob_ * packet.size() / MEAN_PKTSIZE;
p1 = min(p1, PROB_LOW);
accu_prob_ += p1;
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;
}
// 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;
}
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;
// 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;
}
// 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美国科罗拉多州路易斯维尔市煤溪圈80027-9750
Email: g.white@cablelabs.com
Email: g.white@cablelabs.com
Rong Pan Cisco Systems 510 McCarthy Blvd Milpitas, CA 95134 United States of America
美国加利福尼亚州米尔皮塔斯麦卡锡大道510号，邮编95134
Email: ropan@cisco.com
Email: ropan@cisco.com