]> Independent

United Kingdom ietf@bobbriscoe.net https://bobbriscoe.net/

CableLabs

United States of America G.White@CableLabs.com

WIT tsvwg Independent Submission Stream ISE Latency Policing This Informational RFC explains the specification of the queue protection algorithm used in Data-Over-Cable Service Interface Specification (DOCSIS) technology since version 3.1. A shared low-latency queue relies on the non-queue-building behavior of every traffic flow using it. However, some flows might not take such care, either accidentally or maliciously. If a queue is about to exceed a threshold level of delay, the queue protection algorithm can rapidly detect the flows most likely to be responsible. It can then prevent harm to other traffic in the low-latency queue by ejecting selected packets (or all packets) of these flows. This document is designed for four audiences: a) congestion control designers who need to understand how to keep on the "good" side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm.

Introduction This Informational RFC explains the specification of the queue protection (QProt) algorithm used in DOCSIS technology since version 3.1 . Although the algorithm is defined in Annex P of , it relies on cross references to other parts of the set of specifications. This document pulls all the strands together into one self-contained document. The core of the document is a similar pseudocode walk-through to that in the DOCSIS specification, but it also includes additional material:

1. a brief overview,
2. a definition of how a data sender needs to behave to avoid triggering queue protection, and
3. a section giving the rationale for the design choices.

Low queuing delay depends on hosts sending their data smoothly, either at a low rate or responding to Explicit Congestion Notifications (ECNs) (see and ). So, low-latency queuing is something hosts create themselves, not something the network gives them. This tends to ensure that self-interest alone does not drive flows to mis-mark their packets for the low-latency queue. However, traffic from an application that does not behave in a non-queue-building way might erroneously be classified into a low-latency queue, whether accidentally or maliciously. QProt protects other traffic in the low-latency queue from the harm due to excess queuing that would otherwise be caused by such anomalous behavior. In normal scenarios without misclassified traffic, QProt is not expected to intervene at all in the classification or forwarding of packets. An overview of how low-latency support has been added to DOCSIS technology is given in . In each direction of a DOCSIS link (upstream and downstream), there are two queues: one for Low-Latency (LL) and one for Classic traffic, in an arrangement similar to the IETF's Coupled DualQ Active Queue Management (AQM) . The two queues enable a transition from "Classic" to "Scalable" congestion control so that low latency can become the norm for any application, including ones seeking both full throughput and low latency, not just low-rate applications that have been more traditionally associated with a low-latency service. The Classic queue is only necessary for traffic such as traditional (Reno/Cubic) TCP that needs about a round trip of buffering to fully utilize the link, and therefore has no incentive to mismark itself as low latency. The QProt function is located at the ingress to the Low-Latency queue. Therefore, in the upstream, QProt is located on the cable modem (CM); in the downstream, it is located on the CM Termination System (CMTS). If an arriving packet triggers queue protection, the QProt algorithm ejects the packet from the Low-Latency queue and reclassifies it into the Classic queue. If QProt is used in settings other than DOCSIS links, it would be a simple matter to detect queue-building flows by using slightly different conditions and/or to trigger a different action as a consequence, as appropriate for the scenario, e.g., dropping instead of reclassifying packets or perhaps accumulating a second per-flow score to decide whether to redirect a whole flow rather than just certain packets. Such work is for future study and out of scope of the present document. The QProt algorithm is based on a rigorous approach to quantifying how much each flow contributes to congestion, which is used in economics to allocate responsibility for the cost of one party's behavior on others (the economic externality). Another important feature of the approach is that the metric used for the queuing score is based on the same variable that determines the level of ECN signalling seen by the sender (see and ). This makes the internal queuing score visible externally as ECN markings. This transparency is necessary to be able to objectively state (in ) how a flow can keep on the "good" side of the algorithm.

Document Roadmap The core of the document is the walk-through of the DOCSIS QProt algorithm's pseudocode in . Prior to that, summarizes the approach used in the algorithm. Then, considers QProt from the perspective of the end-system by defining the behavior that a flow needs to comply with to avoid the QProt algorithm ejecting its packets from the low-latency queue. gives deeper insight into the principles and rationale behind the algorithm. Then, explains the limitations of the approach. The usual closing sections follow.

Terminology The normative language for the DOCSIS QProt algorithm is in the DOCSIS specifications , , and : 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 of bits or bytes contained within packets of a flow that have the CE codepoint set in the IP-ECN field (including IP headers unless specified otherwise). Congestion-bit-rate and congestion-volume were introduced in and .

DOCSIS:

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

Non-queue-building:

A flow that tends not to build a queue.

Queue-building:

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

ECN:

Explicit Congestion Notification

QProt:

The Queue Protection function

Copyright Material Parts of this document are reproduced from with kind permission of the copyright holder, Cable Television Laboratories, Inc. ("CableLabs").

Approach (In Brief) The algorithm is divided into mechanism and policy. There is only a tiny amount of policy code, but policy might need to be changed in the future. So, where hardware implementation is being considered, it would be advisable to implement the policy aspects in firmware or software:

• The mechanism aspects identify flows, maintain flow-state, and accumulate per-flow queuing scores;
• The policy aspects can be divided into conditions and actions:
  • The conditions are the logic that determines when action should be taken to avert the risk of queuing delay becoming excessive;
  • The actions determine how this risk is averted, e.g., by redirecting packets from a flow into another queue or by reclassifying a whole flow that seems to be misclassified.

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 ). 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. So, 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. So, a flow's score accumulates faster:

• the higher the degree of queuing and
• the faster that the flow's packets arrive when there is queuing.

explains further why this score represents blame for queuing. The algorithm, as described so far, would accumulate a number that would rise at the so-called congestion-rate of the flow (see ), 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. explains why this allowance can be set to the same constant for any scalable flow, whatever its bit rate. For implementation efficiency, the queuing score is transformed into time units; this is so that it 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 ).

Policy

Policy Conditions The algorithm uses the queuing score to determine whether to eject each packet only at the time it first arrives. This limits the policies available. For instance, when queueing delay exceeds a threshold, it is not possible to eject a packet from the flow with the highest queuing scoring because that would involve searching the queue for such a packet (if, indeed, one were still in the queue). Nonetheless, it is still possible to develop a policy that protects the low latency of the queue by making the queuing score threshold stricter the greater the excess of queuing delay relative to the threshold (this is explained in ).

Policy Action At the time of writing, the DOCSIS QProt specification states that when the policy conditions are met, the action taken to protect the low-latency queue is to reclassify a packet into the Classic queue (this is justified in ).

Necessary Flow Behavior The QProt algorithm described here can be used for responsive and/or unresponsive flows.

• It is possible to objectively describe the least responsive way that a flow will need to respond to congestion signals in order to avoid triggering queue protection, no matter the link capacity and no matter how much other traffic there is.
• It is not possible to describe how fast or smooth an unresponsive flow should be to avoid queue protection because this depends on how much other traffic there is and the capacity of the link, which an application is unable to know. However, the more smoothly an unresponsive flow paces its packets and the lower its rate relative to typical broadband link capacities, the less likelihood that it will risk causing enough queueing to trigger queue protection.

Responsive low-latency flows can use a Low Latency, Low Loss, and Scalable throughput (L4S) ECN codepoint to get classified into the low-latency queue. A sender can arrange for flows that are smooth but do not respond to ECN marking to be classified into the low-latency queue by using the Non-Queue-Building (NQB) Diffserv codepoint , which the DOCSIS specifications support, or an operator can use various other local classifiers. As already explained in , the QProt algorithm is driven from the same variable that drives the ECN-marking probability in the low-latency or "LL" queue (the "Native" AQM of the LL queue is defined in the Immediate Active Queue Management Annex of ). The algorithm that calculates this internal variable is run on the arrival of every packet, whether or not it is ECN-capable, so that it can be used by the QProt algorithm. But the variable is only used to ECN-mark packets that are ECN-capable. Not only does this dual use of the variable improve processing efficiency, but it also makes the basis of the QProt algorithm visible and transparent, at least for responsive ECN-capable flows. Then, it is possible to state objectively that a flow can avoid triggering queue protection by keeping the bit rate of ECN-marked packets (the congestion-rate) below AGING, which is a configured constant of the algorithm (default 2^19 B/s ~= 4 Mb/s). Note that it is in a congestion controller's own interest to keep its average congestion-rate well below this level (e.g., ~1 Mb/s) to ensure that it does not trigger queue protection during transient dynamics. If the QProt algorithm is used in other settings, it would still need to be based on the visible level of congestion signalling, in a similar way to the DOCSIS approach. Without transparency of the basis of the algorithm's decisions, end-systems would not be able to avoid triggering queue protection on an objective basis.

Pseudocode Walk-Through

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 and for CMTSs in . 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 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. 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. 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:

• source and destination IP addresses of the innermost IP header found;
• the protocol (IPv4) or next header (IPv6) field in this IP header
• either of:
  • source and destination port numbers, for TCP, UDP, UDP-Lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), etc.
  • Security Parameter Index (SPI) for IPsec Encapsulating Security Payload (ESP) .

The Microflow Classification section of the Queue Protection Annex of the DOCSIS specification 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 Queue Protection functions:

Queue Protection Data Path All the functions of Queue Protection 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 from packet classification before each packet is enqueued into the appropriate queue, queue_id, as follows:

The qprotect() Function On each packet arrival at the LL queue, qprotect() measures the current delay of the LL queue and derives the native LL marking probability from it. Then, it uses pick_bucket to find the bucket already holding the flow's state or to allocate a new bucket if the flow is new or its state has expired (the most likely case). Then, the queuing score is updated by the fill_bucket() function. That completes the mechanism aspects. The comments against the subsequent policy conditions and actions should be self-explanatory at a superficial level. The deeper rationale for these conditions is given in . 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; }]]>

The pick_bucket() Function The pick_bucket() function is optimized for flow-state that will normally have expired from packet to packet of the same flow. It is just one way of finding the bucket associated with the flow ID of each packet: it might be possible to develop more efficient alternatives. The algorithm is arranged so that the bucket holding any live (non-expired) flow-state associated with a packet will always be found before a new bucket is allocated. The constant ATTEMPTS, defined earlier, determines how many hashes are used to find a bucket for each flow. (Actually, only one hash is generated; then, by default, 5 bits of it at a time are used as the hash value because, by default, there are 2^5 = 32 buckets). The algorithm stores the flow's own ID in its flow-state. So, when a packet of a flow arrives, the algorithm tries up to ATTEMPTS times to hash to a bucket, looking for the flow's own ID. If found, it uses that bucket, first resetting the expiry time to "now" if it has expired. If it does not find the flow's ID, and the expiry time is still current, the algorithm can tell that another flow is using that bucket, and it continues to look for a bucket for the flow. Even if it finds another flow's bucket where the expiry time has passed, it doesn't immediately use it. It merely remembers it as the potential bucket to use. But first it runs through all the ATTEMPTS hashes to look for a bucket assigned to the flow ID. Then, if a live bucket is not already associated with the packet's flow, the algorithm should have already set aside an existing bucket with a score that has aged out. Given this bucket is no longer necessary to hold state for its previous flow, it can be recycled for use by the present packet's flow. If all else fails, there is one additional bucket (called the dregs) that can be used. If the dregs is still in live use by another flow, subsequent flows that cannot find a bucket of their own all share it, adding their score to the one in the dregs. A flow might get away with using the dregs on its own, but when there are many mis-marked flows, multiple flows are more likely to collide in the dregs, including innocent flows. The choice of number of buckets and number of hash attempts determines how likely it will be that this undesirable scenario will occur. >= 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; }]]>

The fill_bucket() Function The fill_bucket() function both accumulates and ages the queuing score over time, as outlined in . To make aging the score efficient, the increment of the queuing score is transformed into units of time by dividing by AGING so that the result represents the new expiry time of the flow. Given that probNative is already used to select which packets to ECN-mark, it might be thought that the queuing score could just be incremented by the full size of each selected packet, instead of incrementing it by the product of every packet's size (pkt_sz) and probNative. However, the unpublished experience of one of the authors with other congestion policers has found that the score then increments far too jumpily, particularly when probNative is low. A deeper explanation of the queuing score is given in .

The calcProbNative() Function To derive this queuing score, the QProt algorithm uses the linear ramp function calcProbNative() to normalize instantaneous queuing delay of the LL queue into a probability in the range [0,1], which it assigns to probNative. = 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; }]]>

Rationale

Rationale: Blame for Queuing, Not for Rate in Itself 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.

Which is more to blame for queuing delay? 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:

• to be able to ignore very low levels of queuing that contribute insignificantly to delay
• to be able to erect a steep barrier against excessive queuing delay

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.

Responsibility for Queuing: More-Complex Scenario time]]>

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 . 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.

Rationale for 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) , TCP Prague , Bottleneck Bandwidth and Round-trip propagation time version 3 (BBRv3) , or the L4S variant of SCReAM for real-time media , 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 . 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.

Rationale for 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 classic leaky bucket (except the contents of the bucket do not represent bytes).

Transformation of Queuing Score

The accumulation and aging of the queuing score is shown on the left of 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 , dividing both the input and output by the constant AGING rate. 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.

Rationale for Policy Conditions Pseudocode for the QProt policy conditions is given in 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: 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]]> 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 current packet might be ejected, even though there are packets already in the queue from flows with higher queuing scores. However, any flow that continues to contribute to the queue will have to send further packets, giving an opportunity to eject them as well, as they subsequently arrive.
• The next packets to arrive might not be ejected because they might belong to flows with low queuing scores. In this case, queue delay could continue to rise with no opportunity to eject a packet. This is why the queuing score is scaled up by the current queue delay. Then, the more the queue has grown without ejecting a packet, the more the algorithm "raises the bar" to further packets.

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). Note that, by default, CRITICALqL_us is set to the maximum threshold of the ramp marking algorithm MAXTH_us. However, there is some debate as to whether setting it to the minimum threshold instead would improve QProt performance. This would roughly double the ratio of qdelay to CRITICALqL, which is compared against the CRITICALqLSCORE threshold. So, the threshold would have to be roughly doubled accordingly. 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 behavior 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 behavior record that will lead to the packet being ejected.

Graphical Explanation of the Policy Conditions 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 sanction an innocent flow. It can be seen that, as actual harm increases, the judgment of innocence becomes increasingly stringent; the behavior 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. So, conditioning ejection on actual harm helps reduce the chance that VPN traffic will be ejected by the QProt function.

Rationale for 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 Coupled DualQ 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 mis-classified 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 behavior. Therefore, 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 or clear its ECN field to Not-ECT, in order to protect other potential L4S queues downstream. The DOCSIS specifications do not discuss sanctioning whole flows; further discussion is beyond the scope of the present document.

Limitations The QProt algorithm groups packets with common Layer 4 flow identifiers. It then uses this grouping to accumulate queuing scores and to sanction packets. This choice of identifier for grouping is pragmatic with no scientific basis. All the packets of a flow certainly pass between the same two endpoints. However, some applications might initiate multiple flows between the same endpoints, e.g., for media, control, data, etc. Others might use common flow identifiers for all these streams. Also, a user might group multiple application flows within the same encrypted VPN between the same Layer 4 tunnel endpoints. And, even if there were a one-to-one mapping between flows and applications, there is no reason to believe that the rate at which congestion can be caused ought to be allocated on a per-application-flow basis. The use of a queuing score that excludes those aspects of flow rate that do not contribute to queuing () goes some way to mitigating this limitation because the algorithm does not judge responsibility for queuing delay primarily on the combined rate of a set of flows grouped under one flow ID.

IANA Considerations This document has no IANA actions.

Implementation Status

Implementation name:	DOCSIS models for ns-3
Organization	CableLabs
Web page	https://apps.nsnam.org/app/docsis-ns3/
Description	ns-3 simulation models developed and used in support of the Low-Latency DOCSIS development, including models of Dual Queue Coupled AQM, Queue Protection, and the DOCSIS MAC
Maturity	Simulation models that can also be used in emulation mode in a testbed context
Coverage	Complete implementation of Annex P of DOCSIS 3.1
Version	DOCSIS 3.1, version I21; https://www.cablelabs.com/specifications/CM-SP-MULPIv3.1?v=I21
Licence	GPLv2
Contact	via web page
Last Implementation Update	Mar 2022
Information valid at	7 Mar 2022

There are also a number of closed source implementations, including two cable modem implementations written by different chipset manufacturers and several CMTS implementations by other manufacturers. These, as well as the ns-3 implementation, have passed the full suite of compliance tests developed by CableLabs.

Security Considerations The whole of this document concerns traffic security. It considers the security question of how to identify and eject traffic that does not comply with the non-queue-building behavior required to use a shared low-latency queue, whether accidentally or maliciously. of the L4S architecture introduces the problem of maintaining low latency by either self-restraint or enforcement and places DOCSIS queue protection in context within a wider set of approaches to the problem.

Resource Exhaustion Attacks The 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.

Exhausting Flow-State Storage To exhaust the number of buckets, the most efficient attack is to send enough long-running attack flows to increase the chance that an arriving flow will not find an available bucket and will, therefore, have to share the "dregs" bucket. For instance, if ATTEMPTS=2 and NBUCKETS=32, it requires about 94 attack flows, each using different port numbers, to increase the probability to 99% that an arriving flow will have to share the dregs, where it will share a high degree of redirection into the C queue with the remainder of the attack flows. For an attacker to keep buckets busy, it is more efficient to hold onto them by cycling regularly through a set of port numbers (94 in the above example) rather than to keep occupying and releasing buckets with single packet flows across a much larger number of ports. During such an attack, the coupled marking probability will have saturated at 100%. So, to hold a bucket, the rate of an attack flow needs to be no less than the AGING rate of each bucket: 4 Mb/s by default. However, for an attack flow to be sure to hold on to its bucket, it would need to send somewhat faster. Thus, an attack with 100 flows would need a total force of more than 100 * 4 Mb/s = 400 Mb/s. This attack can be mitigated (but not prevented) by increasing the number of buckets. The required attack force scales linearly with the number of buckets, NBUCKETS. So, if NBUCKETS were doubled to 64, twice as many 4 Mb/s flows would be needed to maintain the same impact on innocent flows. Probably the most effective mitigation would be to implement redirection of whole-flows once enough of the individual packets of a certain offending flow had been redirected. This would free up the buckets used to maintain the per-packet queuing score of persistent offenders. Whole-flow redirection is outside the scope of the current version of the QProt algorithm specified here, but it is briefly discussed at the end of . It might be considered that all the packets of persistently offending flows ought to be discarded rather than redirected. However, this is not recommended because attack flows might be able to pervert whole-flow discard, turning it onto at least some innocent flows, thus amplifying an attack that causes reordering into total deletion of some innocent flows.

Exhausting Processing Resources The processing time needed to apply the QProt algorithm to each LL packet is small and intended not to take all the time available between each of a run of fairly small packets. However, an attack could use minimum sized packets launched from multiple input interfaces into a lower capacity output interface. Whether the QProt algorithm is vulnerable to processor exhaustion will depend on the specific implementation. Addition of a capability to redirect persistently offending flows from LL to C would be the most effective way to reduce the per-packet processing cost of the QProt algorithm when under attack. As already mentioned in , this would also be an effective way to mitigate flow-state exhaustion attacks. Further discussion of whole-flow redirection is outside the scope of the present document but is briefly discussed at the end of .

Comments Solicited Evaluation and assessment of the algorithm by researchers is solicited. Comments and questions are also encouraged and welcome. They can be addressed to the authors.

References Normative References CableLabs Linaro Deutsche Telekom CableLabs CableLabs CableLabs Informative References CableLabs CableLabs CableLabs CableLabs White Paper Simula Research Lab Nokia Bell Labs arXiv:1904.07605 commit 90210de commit 0208f59

Acknowledgements Thanks to , , , , and for their reviews of this document. The design of the QProt algorithm and the settings of the parameters benefited from discussion and critique from the participants of the cable industry working group on Low-Latency DOCSIS. CableLabs funded 's initial work on this document.