]> Tsinghua SIGS

China zbc22@mails.tsinghua.edu.cn

HKUST

HongKong China zilim@ust.hk https://zilimeng.com/

General Internet Engineering Task Force AQM real-time communication This document describes Confucius -- a practical queue management scheme designed for offering real-time flows with consistently low latency regardless of competition. Confucius employs an age-aware weight adjustment mechanism to slows down bandwidth adjustment to match the reaction of congestion control, so that the end host can reduce the sending rate without overshooting the network. Confucius is deployed on home routers and requires no configuration in normal Internet deployments.

Introduction Emerging high-quality real-time video streaming applications require consistently low latency, which is often disrupted by latency spikes caused by competing flows, especially those from web traffic. The root cause of latency spikes in real-time flow is the mismatch in reaction time between the bandwidth reallocation on routers and congestion control mechanisms on endpoints. When loading a website, with 9 flows, in the same time with an existing real-time flow, the available bandwidth of the real-time flow is immediately reduced to 1/10 of what it was. Congestion Control Algorithms (CCAs) reduce the real-time flow’s congestion window or sending rate only after end hosts observe latency increases or packet loss, by which time the reaction is already too late. It takes several RTTs for CCAs to converge to the new available bandwidth, while the excessive packets during this period will result in a bufferbloat and lead to an increase in the end-to-end delay. Several approaches to AQM have been developed over the past two decades, but none have been able to practically control latency spikes in scenarios where real-time flows compete with eb traffic. With fair queueing (FQ and FqCoDel), the latency spikes is worsen since the per-flow fair queueing shifts large bandwidth away from real-time flows. By labeling flows in advance, AQMs like CBQ, DiffServ and L4S schedule real-time flows and web traffic differently on the router using ’StrictPriority‘ or weighted class. However, this is impractical in home networks where the application and router belong to different entities since applications will be incentivized to fake their labels for better performance. Learning from this history, the Confucius approach is designed to meet the following goals:

1. Provide latency consistency to real-time flows independently of the number, rate, or CCA of the competing flows.
2. Achieve eventual fairness between real-time flows and competing flows within a bounded convergence time.
3. Operate transparently without endpoint labeling, ensuring practical deployment.

Confucius introduces, for the first time, an age-aware weight adjustment mechanism capable of distinguishing real-time flows from web traffic while smoothly regulating bandwidth allocation between them.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Overview of Confucius The Confucius algorithm described in the rest of this document uses one key variable: LAMBDA, which controls the speed of the weight adjustment.

Exponential Bandwidth Re-allocation The scheduling of Confucius among flows is implemented with a per-flow Deficit Weighted Round Robin (DWRR) mechanism, where a flow's bandwidth share equals its weight divided by the sum of all weights under DWRR scheduling. Unlike the uniform weights in FQ, Confucius carefully calculates the weight for each flow. When a flow arrives at the home router, it is classified as a 'new flow' with an initial weight based on the number of existing new flows. For each new flow, Confucius doubles its weight every 1/LAMBDA milliseconds. This shows how Confucius exponentially increases the weights of new flows. After a time of t the weight of the new flow will be multiplied by 2 LAMBDA * t. Confucius uses a flow weight threshold of 1 to 'age out' new flows. Once the weight of a flow reaches 1, the flow is no longer considered new and will be marked as old flow.

Setting LAMBDA A large LAMBDA leads to abrupt reductions in available bandwidth and causes latency spike, while a small LAMBDA results in unfairness for new flows. The principle of setting LAMBDA SHOULD be to limit the performance degradation of competing flows to an acceptable level while maximizing 1/LAMBDA. We configure LAMBDA = 0.004 (ms^-1) to have a doubling interval of 1/LAMBDA = 250 ms based on the reduction speed metrics of the real-time flows. For typical websites with 10-20 flows, the Page Load Time (PLT) degradation is less than 100 ms, which is acceptable compared to the second-level PLT. With no changes to parameters, Confucius is expected to work across a wide range of conditions, with varying links and all major delay-controlling CCAs.

Annotated Pseudocode for Confucius What follows is the pseudocode of the Confucius algorithm, illustrating the specific process of a new flow arriving, completing, and reweighting. We denote the set of new flows and all flows as F_new and F_all, respectively.

Arrival and completion of new flows When a flow f just arrives at the queue, Confucius will adjust the weights of the flows that are already in F_new, rebalance the weights to the weight w_f for flow f.

• The sum of weights of new flows is upper-bounded. Rebalancing the weights of the new flows in F_new to the just arrived flow f ensures that the sum of weights of new flows will not surge. In general, the weights of new flows will increase only when they are doubled. In this case, the existing flows will not be affected by the arrival of flow f.
• The ratio between the weights of flows in F_new is maintained. During the rebalancing, the flows that arrived earlier will still proportionally have larger weights. For two flows i and j, if flow i arrives T units of time earlier than flow j and before the rebalancing, w_i / w_j = 2T, the ratio still holds after rebalancing. This will help flow with a longer age to exit from F_new earlier, and help to maintain the long-term fairness.

When one flow completes before its weight reaches the threshold, we will reallocate the bandwidth share to all flows in F_new. This ensures that the new flows can converge fast without affecting the existing flows.

Age-aware Weight Adjustment Mechanism As described in , Confucius reweights every 1/LAMBDA ms as follows: 1: /* New flows are the minority */ for f in F_new: w_f = w_f / ration for f in F_new: if w_f >= 1: /* The new flow is old enough */ w_f = 1 F_new = F_new - f ]]>

• When there are more old flows than new flows. Confucius addresses the issue where a burst of new flows impacts a few existing flows. However, there may be more existing flows and only a few new flows. In this case, the new flow will not drastically grab the available bandwidth from the existing flows. We allocate resources to new flows as long as the bandwidth reduction of existing flows is bounded by half and the fair share.
• When flows are no longer new, i.e., their weight reaches 1, Confucius removes the flow from F_new. After that, the flow's weight will remain 1 all the time in the scheduling.

Consider the example in : There is a real-time flow existing in the Confucius queue that is marked as an 'old flow'. Then, a web page initiates multiple flows, leading to a burst of new flows. The sum weight of the weights of the new flows equals the weight of the real-time flow, causing the bandwidth of the real-time flow to be reduced to half of its original value instead of 1/10. Subsequently, the weights of the web flows grow exponentially and quickly converge towards fair allocation within a few RTTs, which is much shorter than the completion time of web traffic. During this process, the bandwidth is smoothly allocated between the real-time flow and the web traffic. Web traffic tends to start with multiple concurrently active flows, while real-time traffic usually generates only a few flows. Despite the absence of labels from the endpoints, Confucius is still able to distinguish web traffic and implement a different reaction compared to real-time flows.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document should not affect the security of the Internet.

References Normative References Informative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Contributors Thanks to all of the contributors. Hong Kong University of Science and Technology (HKUST)

zilim@ust.hk

Tsinghua Shenzhen International Graduate School (SIGS)

zbc22@mails.tsinghua.edu.cn