idnits 2.17.1 draft-ietf-aqm-docsis-pie-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2016) is 2989 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-aqm-pie-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Active Queue Management and Packet Scheduling (aqm) G. White 3 Internet-Draft CableLabs 4 Intended status: Informational R. Pan 5 Expires: August 15, 2016 Cisco Systems 6 February 12, 2016 8 A PIE-Based AQM for DOCSIS Cable Modems 9 draft-ietf-aqm-docsis-pie-02 11 Abstract 13 Cable modems based on the DOCSIS(R) specification provide broadband 14 Internet access to over one hundred million users worldwide. In some 15 cases, the cable modem connection is the bottleneck (lowest speed) 16 link between the customer and the Internet. As a result, the impact 17 of buffering and bufferbloat in the cable modem can have a 18 significant effect on user experience. The CableLabs DOCSIS 3.1 19 specification introduces requirements for cable modems to support an 20 Active Queue Management (AQM) algorithm that is intended to alleviate 21 the impact that buffering has on latency sensitive traffic, while 22 preserving bulk throughput performance. In addition, the CableLabs 23 DOCSIS 3.0 specifications have also been amended to contain similar 24 requirements. This document describes the requirements on Active 25 Queue Management that apply to DOCSIS equipment, including a 26 description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 27 3.1 cable modems. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 15, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Overview of DOCSIS AQM Requirements . . . . . . . . . . . . . 3 65 3. The DOCSIS MAC Layer and Service Flows . . . . . . . . . . . 3 66 4. DOCSIS-PIE vs. PIE . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Latency Target . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. Departure rate estimation . . . . . . . . . . . . . . . . 5 69 4.3. Enhanced burst protection . . . . . . . . . . . . . . . . 6 70 4.4. Expanded auto-tuning range . . . . . . . . . . . . . . . 7 71 4.5. Trigger for exponential decay . . . . . . . . . . . . . . 7 72 4.6. Drop probability scaling . . . . . . . . . . . . . . . . 7 73 4.7. Support for explicit congestion notification . . . . . . 8 74 5. Implementation Guidance . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Informative References . . . . . . . . . . . . . . . . . . . 9 78 Appendix A. DOCSIS-PIE Algorithm definition . . . . . . . . . . 9 79 A.1. DOCSIS-PIE AQM Constants and Variables . . . . . . . . . 10 80 A.1.1. Configuration parameters . . . . . . . . . . . . . . 10 81 A.1.2. Constant values . . . . . . . . . . . . . . . . . . . 10 82 A.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 10 83 A.1.4. Public/system functions: . . . . . . . . . . . . . . 11 84 A.2. DOCSIS-PIE AQM Control Path . . . . . . . . . . . . . . . 11 85 A.3. DOCSIS-PIE AQM Data Path . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 A recent resurgence of interest in Active Queue Management, arising 91 from a recognition of the inadequacies of drop tail queuing in the 92 presence of loss-based congestion control algorithms, has resulted in 93 the development of new algorithms that appear to provide very good 94 congestion feedback to current TCP algorithms, while also having 95 operational simplicity and low complexity. One of these algorithms 96 has been selected as a requirement for cable modems built according 97 to the DOCSIS 3.1 specification [DOCSIS_3.1]. The Data Over Cable 98 Service Interface Specifications (DOCSIS) define the broadband 99 technology deployed worldwide for Ethernet and IP service over hybrid 100 fiber-coaxial cable systems. The most recent revision of the DOCSIS 101 technology, version 3.1, was published in October 2013 and provides 102 support for up to 10 Gbps downstream (toward the customer) and 1 Gbps 103 upstream (from the customer) capacity over existing cable networks. 104 Previous versions of the DOCSIS technology did not contain 105 requirements for AQM. This document outlines the high-level AQM 106 requirements for DOCSIS systems, discusses some of the salient 107 features of the DOCSIS MAC layer, and describes the DOCSIS-PIE 108 algorithm - largely by comparing it to its progenitor, the 109 [I-D.ietf-aqm-pie] algorithm. 111 2. Overview of DOCSIS AQM Requirements 113 CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1] mandates that cable 114 modems implement a specific variant of the Proportional Integral 115 controller Enhanced (PIE) [I-D.ietf-aqm-pie] active queue management 116 algorithm. This specific variant is provided for reference in 117 Appendix A, and simulation results comparing it to drop tail queuing 118 and other AQM options are given in [CommMag] and [DOCSIS-AQM]. In 119 addition, CableLabs' DOCSIS 3.0 specification [DOCSIS_3.0] has been 120 amended to recommend that cable modems implement the same algorithm. 121 Both specifications allow that cable modems can optionally implement 122 additional algorithms, that can then be selected for use by the 123 operator via the modem's configuration file. 125 These requirements on the cable modem apply to upstream transmissions 126 (i.e. from the customer to the Internet). 128 Both specifications also include requirements (mandatory in DOCSIS 129 3.1 and recommended in DOCSIS 3.0) that the Cable Modem Termination 130 System (CMTS) implement active queue management for downstream 131 traffic, however no specific algorithm is defined for downstream use. 133 3. The DOCSIS MAC Layer and Service Flows 135 The DOCSIS Media Access Control (sub-)layer provides tools for 136 configuring differentiated Quality of Service for different 137 applications by the use of Packet Classifiers and Service Flows. 139 Each Service Flow has an associated Quality of Service (QoS) 140 parameter set that defines the treatment of the packets that traverse 141 the Service Flow. These parameters include (for example) Minimum 142 Reserved Traffic Rate, Maximum Sustained Traffic Rate, Peak Traffic 143 Rate, Maximum Traffic Burst, and Traffic Priority. Each upstream 144 Service Flow corresponds to a queue in the cable modem, and each 145 downstream Service Flow corresponds to a queue in the CMTS. The 146 DOCSIS AQM requirements mandate that the CM and CMTS implement the 147 AQM algorithm (and allow it to be disabled if need be) on each 148 Service Flow queue independently. 150 Packet Classifiers can match packets based upon several fields in the 151 packet/frame headers including the Ethernet header, IP header, and 152 TCP/UDP header. Matched packets are then queued in the associated 153 Service Flow queue. 155 Each cable modem can be configured with multiple Packet Classifiers 156 and Service Flows. The maximum number of such entities that a cable 157 modem supports is an implementation decision for the manufacturer, 158 but modems typically support 16 or 32 upstream Service Flows and at 159 least that many Packet Classifiers. Similarly the CMTS supports 160 multiple downstream Service Flows and multiple Packet Classifiers per 161 cable modem. 163 It is typical that upstream and downstream Service Flows used for 164 broadband Internet access are configured with a Maximum Sustained 165 Traffic Rate. This QoS parameter rate-shapes the traffic onto the 166 DOCSIS link, and is the main parameter that defines the service 167 offering. Additionally, it is common that upstream and downstream 168 Service Flows are configured with a Maximum Traffic Burst and a Peak 169 Traffic Rate. These parameters allow the service to burst at a 170 higher (sometimes significantly higher) rate than is defined in the 171 Maximum Sustained Traffic Rate for the amount of bytes configured in 172 Maximum Traffic Burst, as long as the long-term average data rate 173 remains at or below the Maximum Sustained Traffic Rate. 175 Mathematically, what is enforced is that the traffic placed on the 176 DOCSIS link in the time interval (t1,t2) complies with the following 177 rate shaping equations: 179 TxBytes(t1,t2) <= (t2-t1)*R/8 + B 181 TxBytes(t1,t2) <= (t2-t1)*P/8 + 1522 183 for all values t2>t1, where: 185 R = Maximum Sustained Traffic Rate (bps) 187 P = Peak Traffic Rate (bps) 189 B = Maximum Traffic Burst (bytes) 191 The result of this configuration is that the link rate available to 192 the Service Flow varies based on the pattern of load. If the load 193 that the Service Flow places on the link is less than the Maximum 194 Sustained Traffic Rate, the Service Flow "earns" credit that it can 195 then use (should the load increase) to burst at the Peak Traffic 196 Rate. This dynamic is important since these rate changes 197 (particularly the decrease in data rate once the traffic burst credit 198 is exhausted) can induce a step increase in buffering latency. 200 4. DOCSIS-PIE vs. PIE 202 There are a number of differences between the version of the PIE 203 algorithm that is mandated for cable modems in the DOCSIS 204 specifications and the version described in [I-D.ietf-aqm-pie]. 205 These differences are described in the following subsections. 207 4.1. Latency Target 209 The latency target (aka delay reference) is a key parameter that 210 affects, among other things, the tradeoff in performance between 211 latency-sensitive applications and bulk TCP applications. Via 212 simulation studies, a value of 10ms was identified as providing a 213 good balance of performance. However, it is recognized that there 214 may be service offerings for which this value doesn't provide the 215 best performance balance. As a result, this is provided as a 216 configuration parameter that the operator can set independently on 217 each upstream service flow. If not explicitly set by the operator, 218 the modem will use 10 ms as the default value. 220 4.2. Departure rate estimation 222 The PIE algorithm utilizes a departure rate estimator to track 223 fluctuations in the egress rate for the queue and to generate a 224 smoothed estimate of this rate for use in the drop probability 225 calculation. This estimator may be well suited to many link 226 technologies, but is not ideal for DOCSIS upstream links for a number 227 of reasons. 229 First, the bursty nature of the upstream transmissions, in which the 230 queue drains at line rate (up to ~100 Mbps for DOCSIS 3.0 and ~1 Gbps 231 for DOCSIS 3.1) and then is blocked until the next transmit 232 opportunity, results in the potential for inaccuracy in measurement, 233 given that the PIE departure rate estimator starts each measurement 234 during a transmission burst and ends each measurement during a 235 (possibly different) transmission burst. For example, in the case 236 where the start and end of measurement occur within a single burst, 237 the PIE estimator will calculate the egress rate to be equal to the 238 line rate, rather than the average rate available to the modem. 240 Second, the latency introduced by the DOCSIS request-grant mechanism 241 can result in some further inaccuracy. In typical conditions, the 242 request-grant mechanism can add between ~4 ms and ~8 ms of latency to 243 the forwarding of upstream traffic. Within that range, the amount of 244 additional latency that affects any individual data burst is 245 effectively random, being influenced by the arrival time of the burst 246 relative to the next request transmit opportunity, among other 247 factors. 249 Third, in the significant majority of cases, the departure rate, 250 while variable, is controlled by the modem itself via the pair of 251 token bucket rate shaping equations described in Section 3. 252 Together, these two equations enforce a maximum sustained traffic 253 rate, a peak traffic rate, and a maximum traffic burst size for the 254 modem's requested bandwidth. The implication of this is that the 255 modem, in the significant majority of cases, will know precisely what 256 the departure rate will be, and can predict exactly when transitions 257 between peak rate and maximum sustained traffic rate will occur. 258 Compare this to the PIE estimator, which would be simply reacting to 259 (and smoothing its estimate of) those rate transitions after the 260 fact. 262 Finally, since the modem is already implementing the dual token 263 bucket traffic shaper, it contains enough internal state to calculate 264 predicted queuing delay with a minimum of computations. Furthermore, 265 these computations only need to be run every drop probability update 266 interval, as opposed to the PIE estimator, which runs a similar 267 number of computations on each packet dequeue event. 269 For these reasons, the DOCSIS-PIE algorithm utilizes the 270 configuration and state of the dual token bucket traffic shaper to 271 translate queue depth into predicted queuing delay, rather than 272 implementing the departure rate estimator defined in PIE. 274 4.3. Enhanced burst protection 276 The PIE [I-D.ietf-aqm-pie] algorithm has two states, INACTIVE and 277 ACTIVE. During the INACTIVE state, AQM packet drops are suppressed. 278 The algorithm transitions to the ACTIVE state when the queue exceeds 279 1/3 of the buffer size. Upon transition to the ACTIVE state, PIE 280 includes a burst protection feature in which the AQM packet drops are 281 suppressed for the first 150ms. Since DOCSIS-PIE is predominantly 282 deployed on consumer broadband connections, a more sophisticated 283 burst protection was developed in order to provide better performance 284 in the presence of a single TCP session. 286 Where the PIE algorithm has two states, DOCSIS-PIE has three. The 287 INACTIVE and ACTIVE states in DOCSIS-PIE are identical to those 288 states in PIE. The QUIESCENT state is a transitional state between 289 INACTIVE and ACTIVE. The DOCSIS-PIE algorithm transitions from 290 INACTIVE to QUIESCENT when the queue exceeds 1/3 of the buffer size. 291 In the QUIESCENT state, packet drops are immediately enabled, and 292 upon the first packet drop, the algorithm transitions to the ACTIVE 293 state (where drop probability is reset to zero for the 150ms duration 294 of the burst protection as in PIE). From the ACTIVE state, the 295 algorithm transitions to QUIESCENT if the drop_probability has 296 decayed to zero and the queuing latency has been less than half of 297 the LATENCY_TARGET for two update intervals. The algorithm then 298 fully resets to the INACTIVE state if this "quiet" condition exists 299 for the duration of the BURST_RESET_TIMEOUT (1 second). One end 300 result of the addition of the QUIESCENT state is that a single packet 301 drop can occur relatively early on during an initial burst, whereas 302 all drops would be suppressed for at least 150ms of the burst 303 duration in PIE. The other end result is that if traffic stops and 304 then resumes within 1 second, DOCSIS_PIE can directly drop a single 305 packet and then re-enter burst protection, whereas PIE would require 306 that the buffer exceed 1/3 full. 308 4.4. Expanded auto-tuning range 310 The PIE algorithm scales the PI coefficients based on the current 311 drop probability. The DOCSIS-PIE algorithm extends this scaling to 312 drop probabilities below 1e-4. 314 4.5. Trigger for exponential decay 316 The PIE algorithm includes a mechanism by which the drop probability 317 is allowed to decay exponentially (rather than linearly) when it is 318 detected that the buffer is empty. In the DOCSIS case, recently 319 arrived packets may reside in buffer due to the request-grant latency 320 even if the link is effectively idle. As a result, the buffer may 321 not be identically empty in the situations for which the exponential 322 decay is intended. To compensate for this, we trigger exponential 323 decay when the buffer occupancy is less than 5ms * Peak Traffic Rate. 325 4.6. Drop probability scaling 327 The DOCSIS-PIE algorithm scales the calculated drop probability based 328 on the ratio of the packet size to a constant value of 1024 bytes 329 (representing approximate average packet size). While [RFC7567] in 330 general recommends against this type of scaling, we note that DOCSIS- 331 PIE is expected to predominantly be used to manage upstream queues in 332 residential broadband deployments, where we believe the benefits 333 outweigh the disadvantages. As a safeguard to prevent a flood of 334 small packets from starving flows that use larger packets, DOCSIS-PIE 335 limits the scaled probability to a defined maximum value of 0.85. 337 4.7. Support for explicit congestion notification 339 DOCSIS-PIE does not include support for explicit congestion 340 notification. Cable modems are essentially IEEE 802.1d Ethernet 341 bridges and so are not designed to modify IP header fields. 342 Additionally, the packet processing pipeline in a cable modem is 343 commonly implemented in hardware. As a result, introducing support 344 for ECN would have engendered a more significant redesign of cable 345 modem data paths, and implementations would have been difficult or 346 impossible to modify in the future. At the time of the development 347 of DOCSIS-PIE, which coincided with the development of modem chip 348 designs, the benefits of ECN marking relative to packet drop were 349 considered to be relatively minor, there was considerable discussion 350 about differential treatment of ECN capable packets in the AQM drop/ 351 mark decision, and there were some initial suggestions that a new ECN 352 approach was needed. Due to this uncertainty, we chose not to 353 include support for ECN. 355 5. Implementation Guidance 357 The AQM space is an evolving one, and it is expected that continued 358 research in this field may in the future result in improved 359 algorithms. 361 As part of defining the DOCSIS-PIE algorithm, we split the pseudocode 362 definition into two components, a "data path" component and a 363 "control path" component. The control path component contains the 364 packet drop probability update functionality, whereas the data path 365 component contains the per-packet operations, including the drop 366 decision logic. 368 It is understood that some aspects of the cable modem implementation 369 may be done in hardware, particularly functions that handle packet- 370 processing. 372 While the DOCSIS specifications don't mandate the internal 373 implementation details of the cable modem, modem implementers are 374 strongly advised against implementing the control path functionality 375 in hardware. The intent of this advice is to retain the possibility 376 that future improvements in AQM algorithms can be accommodated via 377 software updates to deployed devices. 379 6. IANA Considerations 381 This document has no actions for IANA. 383 7. Security Considerations 385 This document describes an active queue management algorithm based on 386 [I-D.ietf-aqm-pie] for implementation in DOCSIS cable modem devices. 387 This algorithm introduces no specific security exposures. 389 8. Informative References 391 [CommMag] White, G., "Active queue management in DOCSIS 3.1 392 networks", IEEE Communications Magazine vol.53, no.3, 393 pp.126-132, March 2015. 395 [DOCSIS-AQM] 396 White, G., "Active Queue Management in DOCSIS 3.x Cable 397 Modems", May 2014, . 400 [DOCSIS_3.0] 401 CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols 402 Specification", December 2015, . 406 [DOCSIS_3.1] 407 CableLabs, "DOCSIS 3.1 MAC and Upper Layer Protocols 408 Specification", December 2015, . 412 [I-D.ietf-aqm-pie] 413 Pan, R., Natarajan, P., and F. Baker, "PIE: A Lightweight 414 Control Scheme To Address the Bufferbloat Problem", draft- 415 ietf-aqm-pie-03 (work in progress), November 2015. 417 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 418 Recommendations Regarding Active Queue Management", 419 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 420 . 422 Appendix A. DOCSIS-PIE Algorithm definition 424 PIE defines two functions organized here into two design blocks: 426 1. Control path block, a periodically running algorithm that 427 calculates a drop probability based on the estimated queuing 428 latency and queuing latency trend. 430 2. Data path block, a function that occurs on each packet enqueue: 431 per-packet drop decision based on the drop probability. 433 It is desired to have the ability to update the Control path block 434 based on operational experience with PIE deployments. 436 A.1. DOCSIS-PIE AQM Constants and Variables 438 A.1.1. Configuration parameters 440 o LATENCY_TARGET. AQM Latency Target for this Service Flow 442 o PEAK_RATE. Service Flow configured Peak Traffic Rate, expressed 443 in Bytes/sec. 445 o MSR. Service Flow configured Max. Sustained Traffic Rate, 446 expressed in Bytes/sec. 448 o BUFFER_SIZE. The size (in bytes) of the buffer for this Service 449 Flow. 451 A.1.2. Constant values 453 o A = 0.25, B = 2.5. Weights in the drop probability calculation 455 o INTERVAL = 16 ms. Update interval for drop probability. 457 o BURST_RESET_TIMEOUT = 1 s. 459 o MAX_BURST = 142 ms (150 ms - 8 ms (update error)) 461 o MEAN_PKTSIZE = 1024 bytes 463 o MIN_PKTSIZE = 64 bytes 465 o PROB_LOW = 0.85 467 o PROB_HIGH = 8.5 469 o LATENCY_LOW = 5 ms 471 o LATENCY_HIGH = 200 ms. 473 A.1.3. Variables 475 o drop_prob_. The current packet drop probability. 477 o accu_prob_. accumulated drop prob. since last drop 478 o qdelay_old_. The previous queue delay estimate. 480 o burst_allowance_. Countdown for burst protection, initialize to 0 482 o burst_reset_. counter to reset burst 484 o aqm_state_. AQM activity state encoding 3 states: 486 INACTIVE - queue staying below 1/3 full, suppress AQM drops 488 QUIESCENT - transition state 490 ACTIVE - normal AQM drops (after burst protection period) 492 o queue_. Holds the pending packets. 494 A.1.4. Public/system functions: 496 o drop(packet). Drops/discards a packet 498 o random(). Returns a uniform r.v. in the range 0 ~ 1 500 o queue_.is_full(). Returns true if queue_ is full 502 o queue_.byte_length(). Returns current queue_ length in bytes, 503 including all MAC PDU bytes without DOCSIS MAC overhead 505 o queue_.enque(packet). Adds packet to tail of queue_ 507 o msrtokens(). Returns current token credits (in bytes) from the 508 Max Sust. Traffic Rate token bucket 510 o packet.size(). Returns size of packet 512 A.2. DOCSIS-PIE AQM Control Path 514 The DOCSIS-PIE control path performs the following: 516 o Calls control_path_init() at service flow creation 518 o Calls calculate_drop_prob() at a regular INTERVAL (16ms) 520 ================ 521 // Initialization function 522 control_path_init() { 523 drop_prob_ = 0; 524 qdelay_old_ = 0; 525 burst_reset_ = 0; 526 aqm_state_ = INACTIVE; 527 } 529 // Background update, occurs every INTERVAL 530 calculate_drop_prob() { 532 if (queue_.byte_length() <= msrtokens()) { 533 qdelay = queue_.byte_length() / PEAK_RATE; 534 } else { 535 qdelay = ((queue_.byte_length() - msrtokens()) / MSR \ 536 + msrtokens() / PEAK_RATE); 537 } 539 if (burst_allowance_ > 0) { 540 drop_prob_ = 0; 541 burst_allowance_ = max(0, burst_allowance_ - INTERVAL); 542 } else { 543 p = A * (qdelay - LATENCY_TARGET) + \ 544 B * (qdelay - qdelay_old_); 545 // Since A=0.25 & B=2.5, can be implemented 546 // with shift and add 548 if (drop_prob_ < 0.000001) { 549 p /= 2048; 550 } else if (drop_prob_ < 0.00001) { 551 p /= 512; 552 } else if (drop_prob_ < 0.0001) { 553 p /= 128; 554 } else if (drop_prob_ < 0.001) { 555 p /= 32; 556 } else if (drop_prob_ < 0.01) { 557 p /= 8; 558 } else if (drop_prob_ < 0.1) { 559 p /= 2; 560 } else if (drop_prob_ < 1) { 561 p /= 0.5; 562 } else if (drop_prob_ < 10) { 563 p /= 0.125; 564 } else { 565 p /= 0.03125; 566 } 568 if ((drop_prob_ >= 0.1) && (p > 0.02)) { 569 p = 0.02; 570 } 571 drop_prob_ += p; 573 /* some special cases */ 574 if (qdelay < LATENCY_LOW && qdelay_old_ < LATENCY_LOW) { 575 drop_prob_ *= 0.98; // exponential decay 576 } else if (qdelay > LATENCY_HIGH) { 577 drop_prob_ += 0.02; // ramp up quickly 578 } 580 drop_prob_ = max(0, drop_prob_); 581 drop_prob_ = min(drop_prob_, \ 582 PROB_LOW * MEAN_PKTSIZE/MIN_PKTSIZE); 583 } 585 // check if all is quiet 586 quiet = (qdelay < 0.5 * LATENCY_TARGET) 587 && (qdelay_old_ < 0.5 * LATENCY_TARGET) 588 && (drop_prob_ == 0) 589 && (burst_allowance_ == 0); 591 // Update AQM state based on quiet or !quiet 592 if ((aqm_state_ == ACTIVE) && quiet) { 593 aqm_state_ = QUIESCENT; 594 burst_reset_ = 0; 595 } else if (aqm_state_ == QUIESCENT) { 596 if (quiet) { 597 burst_reset_ += INTERVAL ; 598 if (burst_reset_ > BURST_RESET_TIMEOUT) { 599 burst_reset_ = 0; 600 aqm_state_ = INACTIVE; 601 } 602 } else { 603 burst_reset_ = 0; 604 } 605 } 607 qdelay_old_ = qdelay; 609 } 611 A.3. DOCSIS-PIE AQM Data Path 613 The DOCSIS-PIE data path performs the following: 615 o Calls enque() in response to an incoming packet from the CMCI 617 ================ 618 enque(packet) { 619 if (queue_.is_full()) { 620 drop(packet); 621 accu_prob_ = 0; 623 } else if (drop_early(packet, queue_.byte_length())) { 624 drop(packet); 625 } else { 626 queue_.enque(packet); 627 } 628 } 630 //////////////// 631 drop_early(packet, queue_length) { 633 // if still in burst protection, suppress AQM drops 634 if (burst_allowance_ > 0) { 635 return FALSE; 636 } 638 // if drop_prob_ goes to zero, clear accu_prob_ 639 if (drop_prob_ == 0) { 640 accu_prob_ = 0; 641 } 643 if (aqm_state_ == INACTIVE) { 644 if (queue_.byte_length() < BUFFER_SIZE/3) { 645 // if queue is still small, stay in 646 // INACTIVE state and suppress AQM drops 647 return FALSE; 648 } else { 649 // otherwise transition to QUIESCENT state 650 aqm_state_ = QUIESCENT; 651 } 652 } 654 //The CM can quantize packet.size to 64, 128, 256, 512, 768, 655 // 1024, 1280, 1536, 2048 in the calculation below 656 p1 = drop_prob_ * packet.size() / MEAN_PKTSIZE; 657 p1 = min(p1, PROB_LOW); 659 accu_prob_ += p1; 661 // Suppress AQM drops in certain situations 662 if ( (qdelay_old_ < 0.5 * LATENCY_TARGET && drop_prob_ < 0.2) 663 || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { 664 return FALSE; 665 } 667 if (accu_prob_ < PROB_LOW) { // avoid dropping too fast due 668 return FALSE; // to bad luck of coin tosses... 669 } else if (accu_prob_ >= PROB_HIGH) { // ...and avoid droppping 670 drop = TRUE; // too slowly 672 } else { //Random drop 673 double u = random(); // 0 ~ 1 674 if (u > p1) 675 return FALSE; 676 else 677 drop = TRUE; 678 } 680 // at this point, drop == TRUE, so packet will be dropped. 682 // reset accu_prob_ 683 accu_prob_ = 0; 685 // If in QUIESCENT state, packet drop triggers 686 // ACTIVE state and start of burst protection 687 if (aqm_state_ == QUIESCENT) { 688 aqm_state_ = ACTIVE; 689 burst_allowance_ = MAX_BURST; 690 } 691 return TRUE; 692 } 694 Authors' Addresses 696 Greg White 697 CableLabs 698 858 Coal Creek Circle 699 Louisville, CO 80027-9750 700 USA 702 Email: g.white@cablelabs.com 704 Rong Pan 705 Cisco Systems 706 510 McCarthy Blvd 707 Milpitas, CA 95134 708 USA 710 Email: ropan@cisco.com