| Internet-Draft | CMPM | July 2025 |
| Zhao | Expires 2 January 2026 | [Page] |
This document proposes introducing a "Competitive Mode" into delay-based congestion control algorithms to improve their competitiveness and fairness during coexistence scenarios.¶
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 2 January 2026.¶
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 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.¶
Congestion control algorithms can be categorized into loss-based and delay-based algorithms based on their congestion detection mechanisms. Loss-based congestion control algorithms typically fill the link buffer until packet loss occurs, then reduce the sending rate. In contrast, delay-based congestion control algorithms proactively reduce the sending rate when queuing delay increases. Representative delay-based congestion control algorithms (e.g., Vegas[Vegas], FAST[FAST], Copa[Copa]) measure RTT or queuing delay, calculate the expected throughput based on delay variations, determine congestion, and adjust the congestion window size.¶
While delay-based algorithms generally exhibit lower packet loss rates and smaller queuing delays than loss-based algorithms, they fail to fairly share link bandwidth with loss-based algorithms (e.g., Cubic) when both types of traffic coexist.¶
Determine whether the current flow is in a coexistence/competition phase with Cubic traffic based on the magnitude of queuing delay variation. The COPA provides a method to determine whether it is in competitive mode.¶
Specifically, upon receiving an ACK, the algorithm calculates the RTT for each flow and maintains a historical minimum RTT value(min_rtt). Based on RTT samples, it records the maximum(max_delay) and minimum(min_delay) RTT values over a 4-RTT window. Competitive Mode is triggered based on the following inequality.¶
min_delay < min_rtt + 0.1(max_delay - min_rtt) Formula 1¶
Here, max_delay and min_delay represent the maximum and minimum RTT values within the last 4 RTT intervals, and min_rtt is the historical minimum RTT. The difference between min_delay and min_rtt represents the minimum queuing delay at the bottleneck link during this period, while the difference between max_delay and min_rtt represents the maximum queuing delay. If the inequality is not satisfied, it indicates that the bottleneck link's queue has not emptied during this period, suggesting likely competition from Cubic-like flows. Consequently, the algorithm enters Competitive Mode. If the inequality holds, the algorithm operates in Default Mode.¶
When the algorithm determines it is in Competition Mode, it introduces an additional congestion window gain factor to moderately increase the congestion window size.¶
TBD.¶
TBD.¶
The following people have substantially contributed to this document:¶
Zhiqiang Li
lizhiqiangyjy@chinamobile.com
Hongwei Yang
yanghongwei@chinamoblie.com¶
TBD.¶