RFC 9957: The DOCSIS Queue Protection Algorithm to Preserve Low Latency

1.2. Terminology

The normative language for the DOCSIS QProt algorithm is in the DOCSIS specifications [DOCSIS], [DOCSIS-CM-OSS], and [DOCSIS-CCAP-OSS]: not in this Informational RFC. If there is any inconsistency, the DOCSIS specifications take precedence.¶

The following terms and abbreviations are used:¶

CM:

Cable Modem¶

CMTS:

CM Termination System¶

Congestion-rate:

The transmission rate counting only bits or bytes contained within packets of a flow that have the Congestion Experienced (CE) codepoint set in the IP-ECN field [RFC3168] (including IP headers unless specified otherwise). Congestion-bit-rate and congestion-volume were introduced in [RFC7713] and [RFC6789].¶

DOCSIS:

Data-Over-Cable Service Interface Specification. "DOCSIS" is a registered trademark of Cable Television Laboratories, Inc. ("CableLabs").¶

QProt:

The DOCSIS Queue Protection function¶

non-queue-building:

A flow that tends not to build a queue.¶

Note the use of lowercase "non-queue-building", which describes the behaviour of a flow, in contrast to uppercase Non-Queue-Building (NQB), which refers to a Diffserv marking [RFC9956]. A flow identifying itself as uppercase NQB may not, in fact, behave in a non-queue-building way, which is what the QProt algorithm is intended to detect.¶

queue-building:

A flow that builds a queue. If it is classified into the Low-Latency queue, it is therefore a candidate for the QProt algorithm to detect and sanction.¶

ECN:

Explicit Congestion Notification [RFC3168]¶

ECN marking or ECN signalling:

Setting the IP-ECN field of an increasing proportion of packets to the Congestion Experienced (CE) codepoint [RFC3168] as queuing worsens.¶

1.3. Source Material

Parts of this document are reproduced from [DOCSIS] with kind permission of Cable Television Laboratories, Inc. ("CableLabs").¶

2.1. Mechanism

The algorithm maintains per-flow state, where "flow" usually means an end-to-end (Layer 4) 5-tuple. The flow state consists of a queuing score that decays over time. Indeed, it is transformed into time units so that it represents the flow state's own expiry time (explained in Section 5.3). A higher queuing score pushes out the expiry time further.¶

Non-queue-building flows tend to release their flow state rapidly: it usually expires reasonably early in the gap between the packets of a normal flow. Then, the memory can be recycled for packets from other flows that arrive in-between. Thus, only queue-building flows hold flow state persistently.¶

The simplicity and effectiveness of the algorithm is due to the definition of the queuing score. The queueing score represents the share of blame for queuing that each flow bears. The scoring algorithm uses the same internal variable, probNative, that the AQM for the low-latency queue uses to ECN-mark packets. (The other two forms of marking, Classic and coupled, are driven by Classic traffic; therefore, they are not relevant to protection of the LL queue). In this way, the queuing score accumulates the size of each arriving packet of a flow but scaled by the value of probNative (in the range 0 to 1) at the instant the packet arrives. Therefore, a flow's score accumulates faster:¶

Section 5.1 explains further why this score represents blame for queuing.¶

Thus, the algorithm accumulates a queuing score that would rise at the so-called congestion-rate of the flow (see Section 1.2), i.e., the rate at which the flow is contributing to congestion or the rate at which the AQM is forwarding bytes of the flow that are ECN-marked. However, rather than growing continually, the queuing score is also reduced (or "aged") at a constant rate. This is because it is unavoidable for capacity-seeking flows to induce a continuous low level of congestion as they track available capacity. Section 5.2 explains why this allowance can be set to the same constant for any scalable flow, whatever its bit rate. As a result, the queuing score rises (or falls) according to the difference between the congestion-rate of the flow and the allowed aging rate.¶

For implementation efficiency, the queuing score is transformed into time units. It then represents the expiry time of the flow state (as already discussed above). Then, it does not need to be explicitly aged because the natural passage of time implicitly "ages" an expiry time. The transformation into time units simply involves dividing the queuing score of each packet by the constant aging rate (this is explained further in Section 5.3).¶

2.2. Policy

4.1. Input Parameters, Constants, and Variables

The operator input parameters that set the parameters in the first two blocks of pseudocode below are defined for cable modems (CMs) in [DOCSIS-CM-OSS] and for CMTSs in [DOCSIS-CCAP-OSS]. Then, further constants are either derived from the input parameters or hard-coded.¶

Defaults and units are shown in square brackets. Defaults (or indeed any aspect of the QProt algorithm) are subject to change, so the latest DOCSIS specifications are the definitive references. Also, any operator might set certain parameters to non-default values.¶

<CODE BEGINS>
// Input Parameters
MAX_RATE;          // Configured maximum sustained rate [b/s]
QPROTECT_ON;       // Queue Protection is enabled [Default: TRUE]
CRITICALqL_us;     // LL queue threshold delay [µs] Default: MAXTH_us
CRITICALqLSCORE_us;// The threshold queuing score [Default: 4000 µs]
LG_AGING;          // The aging rate of the q'ing score [Default: 19]
                   //  as log base 2 of the congestion-rate [lg(B/s)]

// Input Parameters for the calcProbNative() algorithm:
MAXTH_us;          // Max LL AQM marking threshold [Default: 1000 µs]
LG_RANGE;          // Log base 2 of the range of ramp [lg(ns)]
                   //  Default: 2^19 = 524288 ns (roughly 525 µs)
<CODE ENDS>

<CODE BEGINS>
// Constants, either derived from input parameters or hard-coded
T_RES;                                    // Resolution of t_exp [ns]
                                          // Convert units (approx)
AGING = pow(2, (LG_AGING-30) ) * T_RES;   // lg([B/s]) to [B/T_RES]
CRITICALqL = CRITICALqL_us * 1000;        // [µs] to [ns]
CRITICALqLSCORE = CRITICALqLSCORE_us * 1000/T_RES; // [µs] to [T_RES]
// Threshold for the q'ing score condition
CRITICALqLPRODUCT = CRITICALqL * CRITICALqLSCORE;
qLSCORE_MAX = 5E9 / T_RES;           // Max queuing score = 5 s

ATTEMPTS = 2; // Max attempts to pick a bucket (vendor-specific)
BI_SIZE = 5;  // Bit-width of index number for non-default buckets
NBUCKETS = pow(2, BI_SIZE);  // No. of non-default buckets
MASK = NBUCKETS-1;     // convenient constant, with BI_SIZE LSBs set

                       // Queue Protection exit states
EXIT_SUCCESS  = 0;     // Forward the packet
EXIT_SANCTION = 1;     // Redirect the packet

MAX_PROB      = 1; // For integer arithmetic, would use a large int
                   //  e.g., 2^31, to allow space for overflow
MAXTH = MAXTH_us * 1000;   // Max marking threshold [ns]
MAX_FRAME_SIZE = 2000;  // DOCSIS-wide constant [B]
// Minimum marking threshold of 2 MTU for slow links [ns]
FLOOR =  2 * 8 * MAX_FRAME_SIZE * 10^9 / MAX_RATE;
RANGE = (1 << LG_RANGE);      // Range of ramp [ns]
MINTH = max ( MAXTH - RANGE, FLOOR);
MAXTH = MINTH + RANGE;           // Max marking threshold [ns]
<CODE ENDS>

Throughout the pseudocode, most variables are integers. The only exceptions are floating-point variables representing probabilities (MAX_PROB and probNative) and the AGING parameter. The actual DOCSIS QProt algorithm is defined using integer arithmetic, but in the floating-point arithmetic used in this document, 0 <= probNative <= 1. Also, the pseudocode omits overflow checking and it would need to be made robust to non-default input parameters.¶

The resolution for expressing time, T_RES, needs to be chosen to ensure that expiry times for buckets can represent times that are a fraction (e.g., 1/10) of the expected packet interarrival time for the system.¶

The following definitions explain the purpose of important variables and functions.¶

<CODE BEGINS>
// Public variables:
qdelay;        // The current queuing delay of the LL queue [ns]
probNative;    // Native marking probability of LL queue within [0,1]

// External variables
packet;            // The structure holding packet header fields
packet.size;       // The size of the current packet [B]
packet.uflow;      // The flow identifier of the current packet
                   //  (e.g., 5-tuple or 4-tuple if IPsec)

// Irrelevant details of DOCSIS function to return qdelay are removed
qdelayL(...)      // Returns current delay of the low-latency Q [ns]
<CODE ENDS>

Pseudocode for how the algorithm categorizes packets by flow ID to populate the variable packet.uflow is not given in detail here. The application's flow ID is usually defined by a common 5-tuple (or 4-tuple) of:¶

The Microflow Classification section of the Queue Protection Annex of the DOCSIS specification [DOCSIS] defines various strategies to find these headers by skipping extension headers or encapsulations. If they cannot be found, the specification defines various less-specific 3-tuples that would be used. The DOCSIS specification should be referred to for all these strategies, which will not be repeated here.¶

The array of bucket structures defined below is used by all the QProt functions:¶

<CODE BEGINS>
struct bucket { // The leaky bucket structure to hold per-flow state
   id;          // identifier (e.g., 5-tuple) of flow using bucket
   t_exp;       // expiry time in units of T_RES
                // (t_exp - now) = flow's transformed q'ing score
};
struct bucket buckets[NBUCKETS+1];
<CODE ENDS>

4.2. QProt Data Path

All the functions of QProt operate on the data path, driven by packet arrivals.¶

The following functions that maintain per-flow queuing scores and manage per-flow state are considered primarily as mechanism:¶

    pick_bucket(uflow_id);              // Returns bucket identifier
    fill_bucket(bucket_id, pkt_size, probNative); /* Returns queuing
                                                   * score */
    calcProbNative(qdelay); /* Returns ECN-marking probability of the
                             * Native LL AQM */

The following function is primarily concerned with policy:¶

    qprotect(packet, ...); /* Returns exit status to either forward
                            * or redirect the packet */

('...' suppresses distracting detail.)¶

Future modifications to policy aspects are more likely than modifications to mechanisms. Therefore, policy aspects would be less appropriate candidates for any hardware acceleration.¶

The entry point to these functions is qprotect(), which is called after packet classification and AQM (including ECN marking) yet before each packet is enqueued into the appropriate queue, queue_id, as follows:¶

<CODE BEGINS>
classifier(packet) {
   // Determine which queue using ECN, DSCP, and any local-use fields
   queue_id = classify(packet);
   //  LQ & CQ are macros for valid queue IDs returned by classify()
   if (queue_id == LQ) {
      // if packet classified to Low-Latency Service Flow
      aqm_mark(packet); // apply ECN marking, as needed based on AQM
      if (QPROTECT_ON) {
         if (qprotect(packet, ...) == EXIT_SANCTION) {
            // redirect packet to Classic Service Flow
            queue_id = CQ;
         }
      }
   return queue_id;
}
<CODE ENDS>

<CODE BEGINS>
// Per-packet Queue Protection
qprotect(packet, ...) {

   bckt_id;   // bucket index
   qLscore;   // queuing score of pkt's flow in units of T_RES

   qdelay = qL.qdelay(...);
   probNative = calcProbNative(qdelay);

   bckt_id = pick_bucket(packet.uflow);
   qLscore = fill_bucket(buckets[bckt_id], packet.size, probNative);

   // Determine whether to sanction packet
   if ( ( ( qdelay > CRITICALqL ) // Test if qdelay over threshold...
      // ...and if flow's q'ing score scaled by qdelay/CRITICALqL
      // ...exceeds CRITICALqLSCORE
      && ( qdelay * qLscore > CRITICALqLPRODUCT ) )
      // or qLSCORE_MAX reached
      || ( qLscore >= qLSCORE_MAX ) )

      return EXIT_SANCTION;

   else
      return EXIT_SUCCESS;
}
<CODE ENDS>

<CODE BEGINS>
// Pick the bucket associated with flow uflw
pick_bucket(uflw) {

   now;                      // current time
   j;                        // loop counter
   h32;                      // holds hash of the packet's flow IDs
   h;                        // bucket index being checked
   hsav;                     // interim chosen bucket index

   h32   = hash32(uflw);     // 32-bit hash of flow ID
   hsav  = NBUCKETS;         // Default bucket
   now   = get_time_now();   // in units of T_RES

   // The for loop checks ATTEMPTS buckets for ownership by flow ID
   // It also records the 1st bucket, if any, that could be recycled
   // because it's expired.
   // Must not recycle a bucket until all ownership checks completed
   for (j=0; j<ATTEMPTS; j++) {
      // Use least signif. BI_SIZE bits of hash for each attempt
      h = h32 & MASK;
      if (buckets[h].id == uflw) {    // Once uflw's bucket found...
         if (buckets[h].t_exp <= now) // ...if bucket has expired...
            buckets[h].t_exp = now;   // ...reset it
         return h;                    // Either way, use it
      }
      else if ( (hsav == NBUCKETS)  // If not seen expired bucket yet
                                    //  and this bucket has expired
           && (buckets[h].t_exp <= now) ) {
         hsav = h;                  // set it as the interim bucket
      }
      h32 >>= BI_SIZE;          // Bit-shift hash for next attempt
   }
   // If reached here, no tested bucket was owned by the flow ID
   if (hsav != NBUCKETS) {
      // If here, found an expired bucket within the above for loop
      buckets[hsav].t_exp = now;              // Reset expired bucket
   } else {
      // If here, we're having to use the default bucket (the dregs)
      if (buckets[hsav].t_exp <= now) {   // If dregs has expired...
         buckets[hsav].t_exp = now;       // ...reset it
      }
   }
   buckets[hsav].id = uflw; // In either case, claim for recycling
   return hsav;
}
<CODE ENDS>

<CODE BEGINS>
fill_bucket(bckt_id, pkt_sz, probNative) {
   now;                                       // current time
   now = get_time_now();                      // in units of T_RES
   // Add packet's queuing score
   // For integer arithmetic, a bit-shift can replace the division
   qLscore = min(buckets[bckt_id].t_exp - now
                 + probNative * pkt_sz / AGING, qLSCORE_MAX);
   buckets[bckt_id].t_exp = now + qLscore;
   return qLscore;
}
<CODE ENDS>

<CODE BEGINS>
calcProbNative(qdelay){
      if ( qdelay >= MAXTH ) {
         probNative = MAX_PROB;
      } else if ( qdelay > MINTH ) {
         probNative = MAX_PROB * (qdelay - MINTH)/RANGE;
         // In practice, the * and the / would use a bit-shift
      } else {
         probNative = 0;
      }
      return probNative;
}
<CODE ENDS>

5.1. Rationale: Blame for Queuing, Not for Rate in Itself

Figure 1 shows the bit rates of two flows as stacked areas. It poses the question of which flow is more to blame for queuing delay: the unresponsive constant bit rate flow (c) that is consuming about 80% of the capacity or the flow sending regular short unresponsive bursts (b)? The smoothness of c seems better for avoiding queuing, but its high rate does not. However, if flow c were not there, or ran slightly more slowly, b would not cause any queuing.¶

^ bit rate (stacked areas)
|  ,-.          ,-.          ,-.          ,-.          ,-.
|--|b|----------|b|----------|b|----------|b|----------|b|---Capacity
|__|_|__________|_|__________|_|__________|_|__________|_|_____
|
|                       c
|
|
|
+---------------------------------------------------------------->
                                                              time

To explain queuing scores, in the following it will initially be assumed that the QProt algorithm is accumulating queuing scores but not taking any action as a result.¶

To quantify the responsibility that each flow bears for queuing delay, the QProt algorithm accumulates the product of the rate of each flow and the level of congestion, both measured at the instant each packet arrives. The instantaneous flow rate is represented at each discrete event when a packet arrives by the packet's size, which accumulates faster the more packets arrive within each unit of time. The level of congestion is normalized to a dimensionless number between 0 and 1 (probNative). This fractional congestion level is used in preference to a direct dependence on queuing delay for two reasons:¶

The unit of the resulting queue score is "congested-bytes" per second, which distinguishes it from just bytes per second.¶

Then, during the periods between bursts (b), neither flow accumulates any queuing score: the high rate of c is benign. But, during each burst, if we say the rate of c and b are 80% and 45% of capacity, thus causing 25% overload, they each bear (80/125)% and (45/125)% of the responsibility for the queuing delay (64% and 36%). The algorithm does not explicitly calculate these percentages. They are just the outcome of the number of packets arriving from each flow during the burst.¶

To summarize, the queuing score never sanctions rate solely on its own account. It only sanctions rate inasmuch as it causes queuing.¶

^ bit rate (stacked areas)                               ,
|               ,-.                       |\           ,-
|------Capacity-|b|----------,-.----------|b|----------|b\-----
|             __|_|_______   |b|        /``\| _...-._-': | ,.--
|  ,-.     __/            \__|_|_     _/    |/          \|/
|  |b| ___/                      \___/   __       r
|  |_|/                v             \__/  \_______    _/\____/
| _/                                               \__/
|
+---------------------------------------------------------------->
                                                              time

Figure 2 gives a more complex illustration of the way the queuing score assigns responsibility for queuing (limited to the precision that ASCII art can illustrate). The figure shows the bit rates of three flows represented as stacked areas labelled b, v, and r. The unresponsive bursts (b) are the same as in the previous example, but a variable-rate video (v) replaces flow c. Its rate varies as the complexity of the video scene varies. Also, on a slower timescale, in response to the level of congestion, the video adapts its quality. However, on a short timescale it appears to be unresponsive to small amounts of queuing. Also, partway through, a low-latency responsive flow (r) joins in, aiming to fill the balance of capacity left by the other two.¶

The combination of the first burst and the low application-limited rate of the video causes neither flow to accumulate queuing score. In contrast, the second burst causes similar excessive overload (125%) to the example in Figure 1. Then, the video happens to reduce its rate (probably due to a less-complex scene) so the third burst causes only a little congestion. Let us assume the resulting queue causes probNative to rise to just 1%, then the queuing score will only accumulate 1% of the size of each packet of flows v and b during this burst.¶

The fourth burst happens to arrive just as the new responsive flow (r) has filled the available capacity, so it leads to very rapid growth of the queue. After a round trip, the responsive flow rapidly backs off, and the adaptive video also backs off more rapidly than it would normally because of the very high congestion level. The rapid response to congestion of flow r reduces the queuing score that all three flows accumulate, but they each still bear the cost in proportion to the product of the rates at which their packets arrive at the queue and the value of probNative when they do so. Thus, during the fifth burst, they all accumulate a lower score than the fourth because the queuing delay is not as excessive.¶

5.2. Rationale: Constant Aging of the Queuing Score

Even well-behaved flows will not always be able to respond fast enough to dynamic events. Also, well-behaved flows, e.g., Data Center TCP (DCTCP) [RFC8257], TCP Prague [PRAGUE-CC], Bottleneck Bandwidth and Round-trip propagation time version 3 (BBRv3) [BBRv3], or the L4S variant of SCReAM [SCReAM] for real-time media [RFC8298], can maintain a very shallow queue by continual careful probing for more while also continually subtracting a little from their rate (or congestion window) in response to low levels of ECN signalling. Therefore, the QProt algorithm needs to continually offer a degree of forgiveness to age out the queuing score as it accumulates.¶

Scalable congestion controllers, such as those above, maintain their congestion window in inverse proportion to the congestion level, probNative. That leads to the important property that, on average, a scalable flow holds the product of its congestion window and the congestion level constant, no matter the capacity of the link or how many other flows it competes with. For instance, if the link capacity doubles, a scalable flow induces half the congestion probability. Or, if three scalable flows compete for the capacity, each flow will reduce to one third of the capacity they would use on their own and increase the congestion level by 3x. Therefore, in steady state, a scalable flow will induce the same constant amount of "congested-bytes" per round trip, whatever the link capacity and no matter how many flows are sharing the capacity.¶

This suggests that the QProt algorithm will not sanction a well-behaved scalable flow if it ages out the queuing score at a sufficient constant rate. The constant will need to be somewhat above the average of a well-behaved scalable flow to allow for normal dynamics.¶

Relating QProt's aging constant to a scalable flow does not mean that a flow has to behave like a scalable flow: it can be less aggressive but not more aggressive. For instance, a longer RTT flow can run at a lower congestion-rate than the aging rate, but it can also increase its aggressiveness to equal the rate of short RTT scalable flows [ScalingCC]. The constant aging of QProt also means that a long-running unresponsive flow will be prone to trigger QProt if it runs faster than a competing responsive scalable flow would. And, of course, if a flow causes excessive queuing in the short term, its queuing score will still rise faster than the constant aging process will decrease it. Then, QProt will still eject the flow's packets before they harm the low latency of the shared queue.¶

5.3. Rationale: Transformed Queuing Score

The QProt algorithm holds a flow's queuing score state in a structure called a "bucket". This is because of its similarity to a regular leaky bucket (except the contents of the bucket do not represent bytes).¶

probNative * pkt_sz   probNative * pkt_sz / AGING
          |                        |
       |  V  |                  |  V  |
       |  :  |        ___       |  :  |
       |_____|        ___       |_____|
       |     |        ___       |     |
       |__ __|                  |__ __|
          |                        |
          V                        V
     AGING * Dt                    Dt

The accumulation and aging of the queuing score is shown on the left of Figure 3 in token bucket form. Dt is the difference between the times when the scores of the current and previous packets were processed.¶

A transformed equivalent of this token bucket is shown on the right of Figure 3, dividing both the input and output by the constant rate, AGING. The result is a bucket-depth that represents time and it drains at the rate that time passes.¶

As a further optimization, the time the bucket was last updated is not stored with the flow state. Instead, when the bucket is initialized, the queuing score is added to the system time "now" and the resulting expiry time is written into the bucket. Subsequently, if the bucket has not expired, the incremental queuing score is added to the time already held in the bucket. Then, the queuing score always represents the expiry time of the flow state itself. This means that the queuing score does not need to be aged explicitly because it ages itself implicitly.¶

5.4. Rationale: Policy Conditions

Pseudocode for the QProt policy conditions is given in Section 4.1 within the second half of the qprotect() function. When each packet arrives, after finding its flow state and updating the queuing score of the packet's flow, the algorithm checks whether the shared queue delay exceeds a constant threshold CRITICALqL (e.g., 2 ms), as repeated below for convenience:¶

<CODE BEGINS>
   if (  ( qdelay > CRITICALqL )  // Test if qdelay over threshold...
      // ...and if flow's q'ing score scaled by qdelay/CRITICALqL
      // ...exceeds CRITICALqLSCORE
      && ( qdelay * qLscore > CRITICALqLPRODUCT ) )
      // Recall that CRITICALqLPRODUCT = CRITICALqL * CRITICALqLSCORE
<CODE ENDS>

If the queue delay threshold is exceeded, the flow's queuing score is temporarily scaled up by the ratio of the current queue delay to the threshold queuing delay, CRITICALqL (the reason for the scaling is given next). If this scaled up score exceeds another constant threshold CRITICALqLSCORE, the packet is ejected. The actual last line of code above multiplies both sides of the second condition by CRITICALqL to avoid a costly division.¶

This approach allows each packet to be assessed once, as it arrives. Once queue delay exceeds the threshold, it has two implications:¶

The above approach is preferred over the extra per-packet processing cost of searching the buckets for the flow with the highest queuing score and searching the queue for one of its packets to eject (if one is still in the queue).¶

Figure 4 explains this approach graphically. On the horizontal axis, it shows actual harm, meaning the queuing delay in the shared queue. On the vertical axis, it shows the behaviour record of the flow associated with the currently arriving packet, represented in the algorithm by the flow's queuing score. The shaded region represents the combination of actual harm and behaviour record that will lead to the packet being ejected.¶

Behaviour Record:
Queueing Score of
Arriving Packet's Flow
^
|   +          |/ / / / / / / / / / / / / / / / / / /
|    +   N     | / / / / / / / / / / / / / / / / / / /
|     +        |/ / / / /                   / / / / /
|      +       | / / / /  E (Eject packet)   / / / / /
|       +      |/ / / / /                   / / / / /
|         +    | / / / / / / / / / / / / / / / / / / /
|           +  |/ / / / / / / / / / / / / / / / / / /
|             +| / / / / / / / / / / / / / / / / / / /
|              |+ / / / / / / / / / / / / / / / / / /
|    N         |   + / / / / / / / / / / / / / / / / /
| (No actual   |       +/ / / / / / / / / / / / / / /
|   harm)      |            +  / / / / / / / / / / / /
|              | P (Pass over)   +   ,/ / / / / / / /
|              |                           ^ + /./ /_/
+--------------+------------------------------------------>
          CRITICALqL        Actual Harm: Shared Queue Delay

The regions labelled "N" represent cases where the first condition is not met -- no actual harm -- queue delay is below the critical threshold, CRITICALqL.¶

The region labelled "E" represents cases where there is actual harm (queue delay exceeds CRITICALqL) and the queuing score associated with the arriving packet is high enough to be able to eject it with certainty.¶

The region labelled "P" represents cases where there is actual harm, but the queuing score of the arriving packet is insufficient to eject it, so it has to be passed over. This adds to queuing delay, but the alternative would be to risk sanctioning an innocent flow. It can be seen that, as actual harm increases, the judgement of innocence becomes increasingly stringent; the behaviour record of the next packet's flow does not have to be as bad to eject it.¶

Conditioning ejection on actual harm helps prevent VPN packets being ejected unnecessarily. VPNs consisting of multiple flows can tend to accumulate queuing score faster than it is aged out because the aging rate is intended for a single flow. However, whether or not some traffic is in a VPN, the queue delay threshold (CRITICALqL) will be no more likely to be exceeded. Therefore, conditioning ejection on actual harm helps reduce the chance that VPN traffic will be ejected by the QProt function.¶

5.5. Rationale: Reclassification as the Policy Action

When the DOCSIS QProt algorithm deems that it is necessary to eject a packet to protect the Low-Latency queue, it redirects the packet to the Classic queue. In the Low-Latency DOCSIS architecture (as in Dual-Queue Coupled AQMs generally), the Classic queue is expected to frequently have a larger backlog of packets, which is caused by classic congestion controllers interacting with a Classic AQM (which has a latency target of 10 ms) as well as other bursty traffic.¶

Therefore, typically, an ejected packet will experience higher queuing delay than it would otherwise, and it could be re-ordered within its flow (assuming QProt does not eject all packets of an anomalous flow). The mild harm caused to the performance of the ejected packet's flow is deliberate. It gives senders a slight incentive to identify their packets correctly.¶

If there were no such harm, there would be nothing to prevent all flows from identifying themselves as suitable for classification into the low-latency queue and just letting QProt sort the resulting aggregate into queue-building and non-queue-building flows. This might seem like a useful alternative to requiring senders to correctly identify their flows. However, handling of misclassified flows is not without a cost. The more packets that have to be reclassified, the more often the delay of the low-latency queue would exceed the threshold. Also, more memory would be required to hold the extra flow state.¶

When a packet is redirected into the Classic queue, an operator might want to alter the identifier(s) that originally caused it to be classified into the Low-Latency queue so that the packet will not be classified into another low-latency queue further downstream. However, redirection of occasional packets can be due to unusually high transient load just at the specific bottleneck, not necessarily at any other bottleneck and not necessarily due to bad flow behaviour. Therefore, Section 5.4.1.2 of [RFC9331] precludes a network node from altering the end-to-end ECN field to exclude traffic from L4S treatment. Instead a local-use identifier ought to be used (e.g., Diffserv codepoint or VLAN tag) so that each operator can apply its own policy, without prejudging what other operators ought to do.¶

Although not supported in the DOCSIS specifications, QProt could be extended to recognize that large numbers of redirected packets belong to the same flow. This might be detected when the bucket expiry time t_exp exceeds a threshold. Depending on policy and implementation capabilities, QProt could then install a classifier to redirect a whole flow into the Classic queue, with an idle timeout to remove stale classifiers. In these "persistent offender" cases, QProt might also overwrite each redirected packet's DSCP, in order to protect other potential low-latency queues downstream. The DOCSIS specifications do not discuss sanctioning whole flows; further discussion is beyond the scope of the present document.¶

8.1. Resource Exhaustion Attacks

The QProt algorithm has been designed to fail gracefully in the face of traffic crafted to overrun the resources used for the algorithm's own processing and flow state. This means that non-queue-building flows will always be less likely to be sanctioned than queue-building flows. But an attack could be contrived to deplete resources in such a way that the proportion of innocent (non-queue-building) flows that are incorrectly sanctioned could increase.¶

Incorrect sanctioning is intended not to be catastrophic; it results in more packets from well-behaved flows being redirected into the Classic queue, which introduces more reordering into innocent flows.¶