RFC 8034
Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems
Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems 🎀
- RFC number: 8034 🌸
- Published: February 2017, by the IETF 🗓️
- Authors: G. White (CableLabs) and R. Pan (Cisco Systems) 👩💻
- Category: Informational 📖
- ISSN: 2070-1721
- Obsoletes / updates: nothing listed 🙅♀️
Abstract ✨
Cable modems built to the DOCSIS specs give broadband internet to over one hundred million users worldwide 🌍. Sometimes the cable modem is the slowest link between you and the internet, so buffering and bufferbloat inside it can seriously wreck your experience 😭. CableLabs' DOCSIS 3.1 spec adds a requirement that cable modems support an AQM algorithm meant to ease the buffering hit on latency-sensitive traffic while keeping bulk throughput strong 💅. The DOCSIS 3.0 specs got amended with similar requirements too 🔥. This doc covers the AQM requirements for DOCSIS gear, including the "DOCSIS-PIE" algorithm that DOCSIS 3.1 cable modems are required to run 👑.
Status of This Memo 🙈
Okay so this doc is not an Internet Standards Track spec. It's published just for information 📚.
It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agreed on 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is up for any level of Internet Standard, so check Section 2 of RFC 7841 for that 🤓.
For the latest status, errata, and how to send feedback, go to 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. ©️
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💖.
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 . . . . . . . . . . . . . . . . . . . . . . . 171. Introduction ✨
Okay so AQM has made a big comeback 🔄. People realized that drop-tail queuing is kinda inadequate once you're dealing with loss-based congestion control algorithms 😤. That led to new algorithms that seem to give really good congestion feedback to current TCP algorithms, and they're also simple to operate and low in complexity 🧠. One of them got picked as a requirement for cable modems built to the DOCSIS 3.1 spec [DOCSIS_3.1] 🦋.
DOCSIS is the broadband tech deployed worldwide for Ethernet and IP service over hybrid fiber-coaxial cable systems 🌐. The latest revision, version 3.1, was first published in October 2013. It supports up to 10 Gbps downstream (toward the customer) and 1 Gbps upstream (from the customer) over existing cable networks 🚀. Earlier DOCSIS versions had no AQM requirements at all 💀.
This doc lays out the high-level AQM requirements for DOCSIS systems, talks through some of the salient features of the DOCSIS Media Access Control (MAC) layer, and describes DOCSIS-PIE. Mostly it does that by comparing it to its parent, the PIE algorithm [RFC8033] 💅.
2. Overview of DOCSIS AQM Requirements 🎀
CableLabs' DOCSIS 3.1 spec [DOCSIS_3.1] mandates that cable modems implement a specific variant of the Proportional Integral controller Enhanced (PIE) AQM algorithm [RFC8033] 👑. That exact variant is written out in Appendix A for reference. Simulation results comparing it to drop-tail queuing and other AQM options live in [CommMag] and [DOCSIS-AQM] 📊.
The DOCSIS 3.0 spec [DOCSIS_3.0] got amended to recommend that cable modems implement the same algorithm 🫶. Both specs also let cable modems optionally implement extra algorithms, and the operator can then pick one through the modem's configuration file ⚙️.
These cable modem requirements cover upstream transmissions, meaning traffic going from the customer to the Internet 💖.
Both specs also include requirements that the Cable Modem Termination System (CMTS) implement AQM for downstream traffic. For DOCSIS 3.1 that's mandatory, and for DOCSIS 3.0 it's recommended 🌈. Still, no specific algorithm is defined for downstream use 🤷♀️.
3. The DOCSIS MAC Layer and Service Flows 🧚
The DOCSIS Media Access Control (sub-)layer gives you tools for setting up differentiated Quality of Service (QoS) for different applications, using Packet Classifiers and Service Flows 🔧.
Each Service Flow has an associated QoS parameter set that decides how the packets traveling through it get treated. Those 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 maps to a queue in the cable modem, and each downstream Service Flow maps to a queue in the CMTS 🪣. The DOCSIS AQM requirements mandate that the CM and CMTS implement the AQM algorithm on each Service Flow queue independently, and they allow it to be disabled if needed 🔘.
Packet Classifiers can match packets using several fields in the packet/frame headers, including the Ethernet header, IP header, and TCP/UDP header 🔍. Matched packets then get queued in the associated Service Flow queue 📥.
Each cable modem can be configured with multiple Packet Classifiers and Service Flows. The max number of these a modem supports is up to the manufacturer. Modems typically support 16 or 32 upstream Service Flows, and at least that many Packet Classifiers 🛠️. The CMTS likewise supports multiple downstream Service Flows and multiple Packet Classifiers per cable modem 🌟.
Upstream and downstream Service Flows used for broadband Internet access are usually configured with a Maximum Sustained Traffic Rate. That QoS parameter rate-shapes the traffic onto the DOCSIS link, and it's the main thing that defines the service offering 🎯. It's also common for those Service Flows to have a Maximum Traffic Burst and a Peak Traffic Rate. These let the service burst at a higher rate than the Maximum Sustained Traffic Rate (sometimes way higher) for as many bytes as Maximum Traffic Burst allows, as long as the long-term average data rate stays at or below the Maximum Sustained Traffic Rate 💨.
Mathematically, what gets enforced is that the traffic put on the DOCSIS link during the time interval (t1,t2) follows these rate-shaping equations 🧮:
TxBytes(t1,t2) <= (t2-t1)*R/8 + B
TxBytes(t1,t2) <= (t2-t1)*P/8 + 1522
for all values t2>t1, where:
R = Maximum Sustained Traffic Rate (bps)
P = Peak Traffic Rate (bps)
B = Maximum Traffic Burst (bytes)So the link rate a Service Flow gets depends on its load pattern 📈. If the load is under the Maximum Sustained Traffic Rate, the Service Flow "earns" credit. It can cash that in later, when the load goes up, to burst at the Peak Traffic Rate 🏃♀️. This matters because those rate changes, especially the drop in data rate once the burst credit runs out, can cause a step increase in buffering latency 😬.
4. DOCSIS-PIE vs. PIE 🔍
There are a number of differences between the version of PIE mandated for cable modems in the DOCSIS specs and the version described in [RFC8033]. We'll go through them in the subsections below 💜.
4.1. Latency Target 🎯
The latency target (a.k.a. delay reference) is a key parameter. Among other things, it shapes the performance trade-off between latency-sensitive apps and bulk TCP apps ⚖️. Simulation studies found that 10 ms gives a good balance 🍓. Still, there may be service offerings where that value doesn't give the best balance, so it's a configuration parameter. The operator can set it independently on each upstream Service Flow 🛜. If the operator doesn't set it explicitly, the modem uses 10 ms as the default ✨.
4.2. Departure Rate Estimation
okay bestie, so PIE has this departure rate estimator 🌊 that tracks how fast the queue is draining out the egress, then smooths that into a number for the drop probability math. ngl it's a great tool for lots of link types, but it's not it for DOCSIS upstream links 💅 and here's why:
First, upstream is bursty and it's a whole mood 😭. The queue drains at line rate (up to ~100 Mbps for DOCSIS 3.0 and ~1 Gbps for DOCSIS 3.1) and then gets blocked until the next transmit opportunity. PIE's estimator starts each measurement during a transmission burst and ends it during a (possibly different) transmission burst, so the measurement can be super inaccurate. Like, if the start and end both land in one burst, PIE calculates the egress rate to be the line rate, not the average rate that's actually available to the modem. not it 💀
Second, the request-grant mechanism adds its own latency drama 🎲. In typical conditions it can add between ~4 ms and ~8 ms to the forwarding of upstream traffic. Within that range, the extra latency for any single data burst is basically random, depending on when the burst shows up relative to the next request transmit opportunity, among other factors.
Third, the modem is in control most of the time 👑. In the significant majority of cases, the departure rate (while variable) is controlled by the modem itself through the pair of token bucket rate-shaping equations described in Section 3. Together, those two equations enforce a Maximum Sustained Traffic Rate, a Peak Traffic Rate, and a Maximum Traffic Burst size for the modem's requested bandwidth. So the modem, in the significant majority of cases, knows precisely what the departure rate will be and can predict exactly when transitions between the Peak Traffic Rate and Maximum Sustained Traffic Rate will happen. Compare that to PIE's estimator, which would just be reacting to (and smoothing its estimate of) those rate transitions after the fact. the modem literally knows the plot 🧠✨
Finally, the modem is already running the dual-token bucket traffic shaper, so it has enough internal state to calculate predicted queuing delay with a minimum of computations 🧮. Even better, those computations only need to run at every drop probability update interval, whereas PIE's estimator runs a similar number of computations on each packet dequeue event.
So for these reasons, DOCSIS-PIE uses the configuration and state of the dual-token bucket traffic shaper to translate queue depth into predicted queuing delay, instead of implementing the departure rate estimator defined in PIE. 🫶
4.3. Enhanced Burst Protection
PIE [RFC8033] has two states: INACTIVE and ACTIVE. During the INACTIVE state, AQM packet drops are suppressed. The algorithm moves to the ACTIVE state when the queue exceeds 1/3 of the buffer size. Once it's in the ACTIVE state, PIE adds a burst protection feature where AQM packet drops are suppressed for the first 150 ms. Since DOCSIS-PIE is mostly deployed on consumer broadband connections, a more sophisticated burst protection was developed to perform better when there's a single TCP session 🎀.
Where PIE 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 the transitional state in between INACTIVE and ACTIVE. DOCSIS-PIE moves from INACTIVE to QUIESCENT when the queue exceeds 1/3 of the buffer size. In the QUIESCENT state, packet drops are immediately enabled, and once the first packet drop happens, the algorithm moves to the ACTIVE state (where the drop probability is reset to zero for the 150 ms duration of the burst protection, just like in PIE).
From the ACTIVE state, the algorithm moves back 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 sticks around for the duration of the BURST_RESET_TIMEOUT (1 second). ⏱️
One end result of adding the QUIESCENT state is that a single packet drop can happen relatively early on during an initial burst, whereas PIE would suppress all drops for at least the first 150 ms of the burst duration 🦋. 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 the buffer to exceed 1/3 full first 🙈.
4.4. Expanded Auto-Tuning Range
PIE scales the Proportional and Integral coefficients based on the current drop probability. DOCSIS-PIE extends this scaling to cover drop probability values greater than 1, which can happen because of the drop probability scaling function described in Section 4.6. For example, if a flood of non-responsive 64-byte packets arrived at a rate twice the departure rate, the DOCSIS-PIE steady-state condition would be to drop 50% of those packets, which means the drop probability would have the value of 8.00 💥.
4.5. Trigger for Exponential Decay
PIE includes a mechanism where the drop probability is allowed to decay exponentially (instead of linearly) when the buffer is detected to be empty. In the DOCSIS case, recently arrived packets may still be sitting in the buffer because of the request-grant latency, even when the link is effectively idle 😮💨. So the buffer might not be totally empty in the situations where exponential decay is supposed to kick in. To fix that, DOCSIS-PIE triggers exponential decay when the buffer occupancy is less than 5 ms * Peak Traffic Rate. ✨
4.6. Drop Probability Scaling
DOCSIS-PIE scales the calculated drop probability based on the ratio of the packet size to a constant value of 1024 bytes (representing an approximate average packet size). While [RFC7567] generally recommends against this type of scaling, DOCSIS-PIE is expected to be used mostly for managing upstream queues in residential broadband deployments, and we think the benefits outweigh the disadvantages 🏡. As a safeguard so a flood of small packets can't starve flows that use larger packets, DOCSIS-PIE limits the scaled probability to a defined maximum value of 0.85. 🛡️
4.7. Support for Explicit Congestion Notification
DOCSIS-PIE does not include support for Explicit Congestion Notification (ECN) 🙅♀️. Cable modems are essentially IEEE 802.1d Ethernet bridges, so they aren't designed to modify IP header fields. On top of that, the packet-processing pipeline in a cable modem is commonly implemented in hardware. So adding ECN support would take a major redesign of cable modem data path hardware, and it would be difficult or impossible to change later. Back when DOCSIS-PIE was being developed, which lined up with the development of modem chip designs, the benefits of ECN marking compared to packet drop were considered pretty minor. There was a lot of discussion about giving ECN-capable packets different treatment in the AQM drop/mark decision, and some early suggestions that a brand new ECN approach was needed. Because of all that uncertainty, we chose not to include ECN support 🤷♀️.
5. Implementation Guidance
The AQM space is always evolving, and it's expected that continued research in this field may lead to improved algorithms down the line 🔬.
When 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. The data path component contains the per-packet operations, including the drop decision logic.
It's understood that some aspects of the cable modem implementation may be done in hardware, particularly the functions that handle packet processing 🔩.
The DOCSIS specifications don't mandate the internal implementation details of the cable modem, but modem implementers are strongly advised against implementing the control path functionality in hardware. The point of this advice is to keep open the possibility that future improvements in AQM algorithms can be delivered through software updates to devices already out in the wild 💜.
6. Security Considerations
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 🔐✨.
7. References
7.1. Normative References
[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>.7.2. Informative References
[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.
[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_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.1]
CableLabs, "MAC and Upper Layer Protocols Interface
Specification", DOCSIS 3.1, January 2017,
<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>.Appendix A. DOCSIS-PIE Algorithm Definition
PIE defines two functions, which are organized here into two design blocks 🧩:
- Control path block: a periodically running algorithm that calculates a drop probability based on the estimated queuing latency and queuing latency trend.
- Data path block: a function that occurs on each packet enqueue and implements a per-packet drop decision based on the drop probability.
It's desirable to be able to update the control path block based on operational experience with PIE deployments 📈.
A.1. DOCSIS-PIE AQM Constants and Variables
A.1.1. Configuration Parameters
LATENCY_TARGET. AQM Latency Target for this Service FlowPEAK_RATE. Service Flow configured Peak Traffic Rate, expressed in bytes/secondMSR. Service Flow configured Maximum Sustained Traffic Rate, expressed in bytes/secondBUFFER_SIZE. The size (in bytes) of the buffer for this Service Flow
A.1.2. Constant Values ✨
okay bestie, these are the fixed numbers the whole DOCSIS-PIE algorithm runs on 🧮💖
A = 0.25, B = 2.5. These are the weights in the drop probability calculation 🎀INTERVAL = 16 ms. How often the drop probability gets updated ⏰BURST_RESET_TIMEOUT = 1 second🌸MAX_BURST = 142 ms (150 ms - 8 ms (update error))💅MEAN_PKTSIZE = 1024 bytes🦋MIN_PKTSIZE = 64 bytes🍓PROB_LOW = 0.85🌈PROB_HIGH = 8.5🔥LATENCY_LOW = 5 ms✨LATENCY_HIGH = 200 ms👑
A.1.3. Variables 🧠
these are the bits of state the algorithm keeps track of, lowkey the memory of the whole operation 💜
drop_prob_. The current packet drop probability 💧accu_prob_. Accumulated drop probability since last drop 🫧qdelay_old_. The previous queue delay estimate ⏳burst_allowance_. Countdown for burst protection, initialize to 0 🛡️burst_reset_. Counter to reset burst 🔁aqm_state_. AQM activity state encoding 3 states: 🚦INACTIVE- Queue staying below 1/3 full, suppress AQM drops 😴QUIESCENT- Transition state 🌙ACTIVE- Normal AQM drops (after burst protection period) 🔥
queue_. Holds the pending packets 📦
A.1.4. Public/System Functions 🛠️
these are the helper functions the algorithm just calls whenever it needs them, no cap they're the tools in the toolbox 🧰
drop(packet). Drops/discards a packet 🗑️random(). Returns a uniform random value in the range 0 ~ 1 🎲queue_.is_full(). Returns true ifqueue_is full 🚧queue_.byte_length(). Returns currentqueue_length in bytes, including all MAC PDU bytes without DOCSIS MAC overhead 📏queue_.enque(packet). Addspacketto tail ofqueue_➕msrtokens(). Returns current token credits (in bytes) from the Maximum Sustained Traffic Rate token bucket 🪣packet.size(). Returns size ofpacket📐
A.2. DOCSIS-PIE AQM Control Path 🎛️
the control path is the background crew that keeps updating the drop probability, periodt 💅
The DOCSIS-PIE control path performs the following:
- Calls
control_path_init()at Service Flow creation 🌱 - Calls
calculate_drop_prob()at a regularINTERVAL(16 ms) 🔄
================
// 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;
}A.3. DOCSIS-PIE AQM Data Path 📬
and this is the bit that actually decides whether each packet lives or gets dropped, iconic behavior 🫶
The DOCSIS-PIE data path performs the following:
- Calls
enque()in response to an incoming packet from the 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);
}
}
////////////////
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.
// 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 💌
the people who wrote this, bestie, go say hi 🎀
Greg White
CableLabs
858 Coal Creek Circle
Louisville, CO 80027-9750
United States of America
Email: g.white@cablelabs.comRong Pan
Cisco Systems
510 McCarthy Blvd
Milpitas, CA 95134
United States of America
Email: ropan@cisco.com📦 where this page comes from
- ietf: rfc8034 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms