Internet Engineering Task Force B. Zhang Internet-Draft Tsinghua SIGS Intended status: Informational Z. Meng Expires: 4 September 2025 HKUST 3 March 2025 Adapting Home Routers to Congestion Control’s Reactions for Consistent Low Latency draft-zhang-iccrg-confucius-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Zhang & Meng Expires 4 September 2025 [Page 1] Internet-Draft Confucius March 2025 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Overview of Confucius . . . . . . . . . . . . . . . . . . . . 3 3.1. Exponential Bandwidth Re-allocation . . . . . . . . . . . 3 3.2. Setting LAMBDA . . . . . . . . . . . . . . . . . . . . . 4 4. Annotated Pseudocode for Confucius . . . . . . . . . . . . . 4 4.1. Arrival and completion of new flows . . . . . . . . . . . 4 4.2. Age-aware Weight Adjustment Mechanism . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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[RFC8289]), the latency spikes is Zhang & Meng Expires 4 September 2025 [Page 2] Internet-Draft Confucius March 2025 worsen since the per-flow fair queueing shifts large bandwidth away from real-time flows. By labeling flows in advance, AQMs like CBQ[CBQ1995], DiffServ[RFC4594] and L4S[RFC9330] 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: (a) Provide latency consistency to real-time flows independently of the number, rate, or CCA of the competing flows. (b) Achieve eventual fairness between real-time flows and competing flows within a bounded convergence time. (c) 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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. 3.1. 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. Zhang & Meng Expires 4 September 2025 [Page 3] Internet-Draft Confucius March 2025 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. 3.2. 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. 4. 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. 4.1. Arrival and completion of new flows NewFlowArrival(f): for i in F_new: /* Scale down weights */ w_i = (|F_new| * w_i) / (|F_new| + 1) w_f = 1 / (|F_new| + 1) /* Initialize the weight for f */ F_new = F_new + f /* Add flow f to set 'F_new' */ F_all = F_all + f /* Add flow f to set 'F_all' */ Zhang & Meng Expires 4 September 2025 [Page 4] Internet-Draft Confucius March 2025 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. NewFlowCompletion(f): for i in F_new: /* Scale up weights */ w_i = (|F_new| * w_i) / (|F_new| - 1) F_new = F_new - f /* Remove flow f from set 'F_new' */ F_new = F_all - f /* Remove flow f from set 'F_all' */ 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. 4.2. Age-aware Weight Adjustment Mechanism As described in Section 3.1, Confucius reweights every 1/LAMBDA ms as follows: Reweight(f): for i in F_new: w_f = w_f * 2 /* The weight doubles every 1/LAMBDA ms */ ration = sum_weight_of(F_new) / max(1, sum_weight_of(F_old)) if ration > 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 Zhang & Meng Expires 4 September 2025 [Page 5] Internet-Draft Confucius March 2025 * 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 Section 1: 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. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations This document should not affect the security of the Internet. 7. References 7.1. Normative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Zhang & Meng Expires 4 September 2025 [Page 6] Internet-Draft Confucius March 2025 7.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8289] Nichols, K., "Controlled Delay Active Queue Management", January 2018, . [CBQ1995] Floyd, S., "Link-sharing and resource management models for packet networks", 1995. [RFC4594] Babiarz, J., "Configuration Guidelines for DiffServ Service Classes", August 2006, . [RFC9330] Briscoe, B., "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", January 2023, . Contributors Thanks to all of the contributors. Zili Meng Hong Kong University of Science and Technology (HKUST) Email: zilim@ust.hk Bochun Zhang Tsinghua Shenzhen International Graduate School (SIGS) Email: zbc22@mails.tsinghua.edu.cn Authors' Addresses Bochun Zhang Tsinghua SIGS China Email: zbc22@mails.tsinghua.edu.cn Zili Meng HKUST HongKong China Email: zilim@ust.hk Zhang & Meng Expires 4 September 2025 [Page 7] Internet-Draft Confucius March 2025 URI: https://zilimeng.com/ Zhang & Meng Expires 4 September 2025 [Page 8]