]> CNIC

Beijing China yangwanghong@cnic.cn

CNIC

Beijing China renyongmao@cstnet.cn

CNIC

Beijing China zhouxu@cstnet.cn

ICT

Beijing China wuqinghua@ict.ac.cn

CNIC

Beijing China xie@cnic.cn

Transport Network Working Group Low Latency, Low Loss, and Scalable Throughput (L4S) is a technology designed to mitigate queueing delays while maintaining high throughput for IP traffic. In real-time communication (RTC) applications over 5G networks, rapidly fluctuating wireless link conditions impose strict requirements on congestion control algorithms, which must simultaneously ensure low latency and high bandwidth utilization. This document proposes a packet marking policy for L4S in 5G networks, where intermediate base station devices compute a link load factor and use it as a probabilistic signal to mark packets in L4S flows.

Introduction Low-latency real-time communication (RTC) applications, such as interactive video, cloud gaming, and AR/VR, require efficient congestion control mechanisms that can react quickly to changes in network conditions. Accurate and timely congestion signals from intermediate network elements are essential to prevent buffer build-up and to maintain both low latency and high throughput. The Low Latency, Low Loss, and Scalable Throughput (L4S) architecture RFC9330 provides a framework for reducing queuing delays by using Explicit Congestion Notification (ECN) as an end-to-end congestion signal. However, existing L4S marking approaches are primarily based on queuing delay measurements and do not fully capture the dynamics of wireless access networks. In particular, 5G access networks introduce rapid fluctuations in link capacity, where queuing delay alone is not a sufficient indicator of congestion. As a result, conventional L4S marking methods may provide delayed or imprecise feedback, limiting their effectiveness for RTC applications. This document proposes a packet marking strategy for L4S tailored to 5G environments. In this design, base stations compute a link load factor and use it as a probabilistic signal to mark packets in L4S flows. The link load information is encoded into packets at the 5G base station and conveyed to the sender via ACK-based feedback. On the sender side, a dynamic send rate adaptation algorithm adjusts the transmission rate based on the reported link load factor, preventing network congestion while balancing throughput and latency.

Terminology RTC: real-time communication. L4S: Low Latency, Low Loss, and Scalable Throughput (L4S) as defined in and . ECN: Explicit Congestion Notification, defined in , , and , used to signal congestion without dropping packets. gNB: Next-generation Node B, the 5G base station. MAC: Medium Access Control layer in the 5G protocol stack, responsible for multiplexing and scheduling data flows. RLC: Radio Link Control layer in the 5G protocol stack, responsible for segmentation, retransmission, and queue management. PDCP: Packet Data Convergence Protocol layer in the 5G protocol stack, which handles header compression, security, and delivery of IP packets. In this document, the PDCP layer is considered for applying ECN markings, as IP headers remain visible before encryption. ACK: Acknowledgment message, used in feedback to the sender to convey delivery status and congestion information. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and .

A New L4S Marking Process

Deployment Challenges in 5G Low Latency, Low Loss, and Scalable Throughput (L4S) is a congestion control framework designed to reduce queuing delay in general-purpose IP networks. It uses Explicit Congestion Notification (ECN) bits in the IP header to provide end-to-end congestion signaling, enabling applications to adjust their sending rates dynamically without incurring excessive delay or packet loss. ------------------>------------------->------------------------+ 5G-gNB +--------+ +----------------------------+ +--------+ | | | | | | | Client +--------------+-----MAC-----RLC-----PDCP---+-------------+ Server | | | | ^ | | | +--------+ | +------------+ | | +--------+ | | R_Length | | | | | Bandwidth |---> P_Mark | | | T_Size | | | +------------+ | | | +----------------------------+ +-----------<------------------<-------------------<------------------------+ L4S Flow ]]> Deploying L4S within the 5G protocol stack introduces specific challenges. In a typical 5G setup, L4S may be realized by maintaining queuing at the RLC layer and applying ECN markings at the PDCP layer, with flow identification based on ECN bits in compliance with existing standards. Although the L4S specification does not prescribe a packet marking policy, most current implementations rely on queuing delay measurements to probabilistically mark packets. In 5G networks, the air interface and wired backhaul mismatch often makes the RLC layer a congestion bottleneck. Ideally, marking should occur at the RLC layer to reflect actual buffer conditions. However, since RLC data is encrypted, modifying ECN bits at that layer is infeasible. A practical alternative is to apply marking at the PDCP layer, where the IP header is still accessible before encryption.

Link Load Factor Marking Strategy To address the above limitations, this document specifies a probabilistic marking strategy based on a periodically computed link load factor (P_Mark): P_Mark = (T_Size + R_Length) / (Bandwidth × T_Interval) The parameter P_Mark represents the ratio between the traffic offered to the wireless link and the link capacity available over a given interval. It indicates how heavily the link is loaded relative to its service capability. Where:

• T_Interval: The measurement interval.
• T_Size: The amount of new traffic arriving during T_Interval.
• R_Length: RLC real-time queue length before T_Interval
• Bandwidth: The average wireless bandwidth allocated by the base station to the current user within the T_Interval

If P_Mark > 1, all packets are marked; if 0 < P_Mark < 1, packets are marked with probability P_Mark. The marking is performed at the PDCP layer, and the L4S marking information is then fed back to the sender through ACK, allowing the sender to implement the corresponding adaptive rate control. This strategy provides a practical and compatible path for deploying L4S in 5G systems without altering the core structure of existing base stations.

IANA Considerations This memo includes no request to IANA.

Security Considerations For further study.

Acknowledgements Thanks to Wenji Du and Baosen Zhao for discussions and comments on the design of this draft.

Normative 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 memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load. The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.

Historical Note