| Internet-Draft | Mobile L4S | August 2026 |
| Poreba, et al. | Expires 12 February 2027 | [Page] |
This document documents best practices for deployment of Low Latency, Low Loss, and Scalable Throughput (L4S) in mobile devices. It defines the responsibilities of the host operating system, the link-layer (modem and WiFi) subsystems to ensure successful end-to-end low-latency communication.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://fridek.github.io/draft-sporeba-tsvwg-mobile-l4s/draft-sporeba-tsvwg-mobile-l4s.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sporeba-tsvwg-mobile-l4s/.¶
Source for this draft and an issue tracker can be found at https://github.com/fridek/draft-sporeba-tsvwg-mobile-l4s.¶
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 12 February 2027.¶
Copyright (c) 2026 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.¶
L4S (Low Latency, Low Loss, Scalable Throughput) [RFC9330] offers a framework to significantly reduce queuing delay and loss while maintaining consistent throughput. Mobile devices often have to react to quickly changing connectivity conditions and may be subject to variable throughput and connection quality. This can cause large variations in user-perceived latency and greater bufferbloat than in other devices. Deploying L4S in a mobile ecosystem requires co-operation across multiple layers: the network stack, the host operating system (OS), and link-layer drivers and firmware (e.g., Wi-Fi and cellular modem), and the network. This document outlines best current practices for each of these subsystems to achieve reliable, low-latency performance in the field.¶
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.¶
The host operating system controls application-level network access and hosts the primary TCP and UDP transport stacks.¶
To enable UDP-based transport stacks (such as QUIC) to utilize L4S, the OS MUST provide APIs that allow applications to:¶
These capabilities MUST be exposed via standard socket APIs (e.g., IP_TOS and IPV6_TCLASS for setting, and IP_RECVTOS and IPV6_RECVTCLASS via ancillary data for reading) and MUST NOT be restricted by default security policies for standard application sockets. The APIs MUST allow reading the ECN codepoints on a per-packet basis. and MUST allow setting the ECN codepoints either on a per-socket or per-packet basis. The detailed explanation of configuring UDP sockets for ECN for common platforms is covered in [I-D.ietf-tsvwg-udp-ecn]. It should be noted that on some platforms setting ECN codepoints shares calls with DSCP codepoints, and applications might need to take steps to avoid overriding commands.¶
UDP-based transport stacks SHOULD mark L4S-capable traffic as ECT(1) and MUST NOT mark non-L4S traffic as ECT(1). Other NQB traffic marked with DSCP 45 codepoint as per [RFC9956], Section 3.3. Such traffic is considered compatible with L4S and can share the low-latency queue, but should be marked with ECT(1) only to signify the responsiveness to ECN markings (i.e. Prague L4S requirements [RFC9331]. Link layers MUST respond to misbehaving stack as discussed in {#defense-against-misbehaving-traffic}.¶
To allow L4S-capable senders (e.g., Internet servers) to take advantage of L4S, host operating systems and link-layers must negotiate ECN support and verify path integrity as described in Section 1.4 and Section 3 of [RFC9768].¶
If misconfigured networks or servers drop ECN negotiation packets, and the client does not retry without ECN negotiation, TCP connections will fail. Therefore, clients MUST implement retry strategies that disable ECN negotiation, as described in Section 3.1.4 and Section 3.2.3.2.2 of [RFC9768]. Note that a server replying with Not-ECT is does not require any additional retries and is not considered a failure.¶
Latency and loss are critical to mobile applications, and retry strategies dependent on retransmissions and timeouts can lead to a degraded user experience. To ensure that L4S can be safely enabled without degrading the user experience in the presence of networks or servers that drop ECN negotiations or Accurate ECN TCP options, the client SHOULD balance implementing the retry strategies in section 3 of [RFC9768] with mechanisms to reduce the latency impact of retransmissions. A possible strategy is to only attempt ECN negotiation on the first SYN to a new server. Additionally, the host MAY cache ECN negotiation timeouts on a per-host or per-IP-address, or other basis.¶
If a host is in a network that blocks all ECN negotiation regardless of destination, all TCP connections will suffer latency impact. This will degrade the user experience even if failures are cached, because any connection to a server that is not in the cache will suffer an additional round trip delay.¶
A host system that wants to be resilient to this MAY attempt a connectivity check to a known, L4S-supporting service. In case of check failure, the result can be used to turn off L4S negotiation attempts for a given network, represented by PLMN/APN (in carrier networks) or SSID/BSSID (in Wi-Fi networks).¶
When maintaining such lists, entries SHOULD be retired after a reasonable TTL (e.g. 7 days), and SHOULD prefer information from more frequently used destinations.¶
Link-layer subsystems, such as the cellular modem and Wi-Fi schedule and manage the link-layer transmission over the physical medium interface. These systems typically perform significant queueing on the transmit path, and sometimes on the receive path as well.¶
Some link layers provide strong ordering guarantees for inbound packets by assigning a link-layer sequence number to each packet and buffering incoming packets so they can be presented to the host operating system in order. In particular, cellular networks often perform out-of-order packet delivery at the physical layer, but require the cellular modem to deliver received packets to the host operating system in order. When packets are received out of order on the air interface, the modem waits up to a network-configurable timeout to receive all previous packets. This causes out-of-order packets to be delayed until all previous packets have been received, and causes latency spikes when packets are lost due to transmission errors.¶
Delaying received packets increases latency, which is contrary to the low-latency goals of L4S. Also, by artificially introducing delays that were not imposed by the network, it reduces the accuracy of protocol rate estimation. The additional delays do not benefit protocol stacks which are equipped to handle out-of-order packets.¶
Link-layers MUST NOT buffer inbound L4S packets in a way that imposes measurable latency to the protocol stack.¶
[RFC9331] §4.3 specifies that loss detection SHOULD be resilient to packet reordering. However, to enable the requirement on the cellular modem behaviour described above, L4S-aware protocol stacks on mobile devices MUST be prepared to receive out-of-order packets.¶
Any link layer that supports L4S MUST provide a low-latency queue designated for L4S traffic and Non-Queue-Building traffic ([RFC9956] section 3.3). This queue MUST be bounded as described in {#uplink-aqm} and {#defense-against-misbehaving-traffic}. Some link-layer systems already support high-priority and low-priority queues. These queues are typically not latency-bounded, and therefore cannot guarantee the low-latency benefits of L4S. If the link layer provides such queues, low-latency queue MUST be distinct from them. An example configuration might be:¶
Low-Latency Queue: For L4S and other Non-Queue-Building traffic.¶
High-Priority Queue: For high priority but potentially queue-building traffic.¶
Low-Priority Queue: For queue-building traffic (e.g., CUBIC/Reno) and bulk data.¶
Link layers MUST ensure that the L4S queue does not starve the other queues if offered L4S traffic is higher than available bandwidth. Such prioritisation SHOULD use a scheduling algorithm (e.g., Weighted Fair Queueing) and aim to minimize the queue buildup in the Low-Latency queue.¶
The link-layer MUST map uplink traffic to the low-latency queue based on ECN markings:¶
Packets carrying the ECT(1) or CE bits in the IP header MUST be steered to the low-latency queue.¶
The link-layer SHOULD also support mapping to the low-latency queue based on the Non-Queue-Building (NQB) DSCP value (45) [RFC9956] as an alternative or supplementary classifier. Because DSCP markings are frequently bleached at carrier interconnect boundaries, ECN mapping remains the most reliable end-to-end classifier for mobile networks.¶
Link-layer networks MUST NOT attempt to dynamically classify packets for the low-latency queue using heuristic traffic inference or Deep Packet Inspection (DPI). Classification MUST rely solely on the explicit packet markings set by the application endpoints. This ensures compatibility with fully encrypted payloads and aligns with the end-to-end principle and permissionless innovation, as discussed in the ISP deployment observations in [I-D.livingood-low-latency-deployment] (which also contains details on Wi-Fi link-layer queuing considerations).¶
The link-layer uplink buffer within mobile subsystems (such as cellular modems and Wi-Fi drivers) operates as a dynamic bottleneck subject to rapid capacity fluctuations driven by radio grant scheduling, carrier aggregation shifts, and physical layer channel fading. To help achieve consistently low latency under these volatile conditions without inducing throughput degradation, implementations MUST deploy a Dual-Queue Coupled AQM framework adhering strictly to the functional design specifications of [RFC9332].¶
To optimize performance within the specific constraints of mobile device link-layer environments, the underlying AQM parameters MUST be configured as follows:¶
Bandwidth-Independent Metrics: In alignment with [RFC9332] Section 2.4, all internal marking states, delay targets, and queue boundaries MUST be calculated using packet sojourn time (expected time-to-service) rather than raw bytes or static packet counts. Expressing operational boundaries in units of time ensures that parameters remain invariant across fluctuating physical radio drain rates. Furthermore, this approach naturally accommodates large aggregated frame structures (e.g., up to 64kB aggregated packets passed via USB network interfaces or virtual overlay drivers) without triggering premature congestion signals.¶
Two-Tier Congestion Signaling: The link-layer AQM implementation SHOULD implement the structural coupling via a dual-tiered time threshold layout to separate transient bursts from sustained overload:¶
Instantaneous Burst Protection: To mitigate rapid latency spikes caused by sudden frame bursts or brief radio grant allocation delays, the Native L4S AQM component SHOULD utilize an instantaneous step threshold configured strictly between 1 ms and 5 ms.¶
Sustained Congestion Tracking: The coupled Base AQM component SHOULD track long-term link stability against a broader target delay window configured between 15 ms and 50 ms, ensuring smooth end-to-end transport adaptation under sustained link load.¶
Applications may incorrectly or maliciously mark non-responsive traffic as NQB or ECT(1) without implementing a scalable, responsive L4S congestion control algorithm. Because a standard dual-queue coupled framework lacks per-flow processing, a single non-responsive L4S stream will inflate the coupled congestion metrics, driving up CE marking across the entire Low-Latency queue and increasing drops on the Classic queue side, unfairly penalizing well-behaved applications.¶
To defend the Low-Latency queue while remaining fully compliant with the normative boundaries of [RFC9332], mobile link-layer subsystems MUST enforce the following safeguards:¶
Layered Congestion and Drop Progression: Under standard operating conditions, congestion signaling for ECN-capable packets within the Low-Latency queue MUST rely entirely on CE marking. In accordance with the overload mandates of [RFC9332] Sections 2.5.1.1 and 4.2.3, if sustained saturation is detected (i.e., marking capacity is exhausted at 100% ECN signaling or the queue delay persistently exceeds operational bounds), the link-layer MUST introduce classic packet drops to both types of traffic to defend link integrity. Implementations SHOULD follow a strict architectural fallback progression: PI2 Gradual Marking -> Step AQM Burst Marking -> Overload Drops -> Tail-Drop.¶
Buffer Limit Metrics: The link-layer MUST enforce a strict ceiling on the maximum physical capacity of the Low-Latency queue. To prevent premature packet drops when handling heavily aggregated payloads, this absolute limit SHOULD be defined in terms of packet count (with a recommended default limit of 10,000 packets) rather than raw bytes, operating strictly as a final tail-drop mechanism at physical hardware capacity exhaustion.¶
Flow Isolation Architecture: As noted in [RFC9332] Section 4.2.2, scheduling weights alone cannot resolve long-term overload across a shared buffer. For mobile device environments requiring robust traffic defense against rogue applications, the link-layer MAY layer a per-flow queueing discipline or flow-fairness mechanism underneath the macro coupled dual-queue architecture. This design architecture isolates non-responsive streams into distinct internal queueing slots, shielding well-behaved applications from the coupled penalty while fully preserving the macro coupled framework requirements.¶
The link-layer MUST NOT modify the ECN bits, DSCP flags, or AccECN TCP options (172 and 174) on low-latency-queue transit traffic, except for performing standard CE marking in the event of queue buildup.¶
On-Path Nodes MUST NOT perform network-based classification or rewrite ECN/DSCP markings based on traffic heuristics or DPI. In accordance with [I-D.livingood-low-latency-deployment], active classification decisions MUST be left to the application endpoints, and on-path devices MUST restrict their role to marking the ECN bits in the event of a queue forming.¶
On-Path Nodes MUST NOT clear (bleach) ECN bits, in accordance with [RFC3168]. They MUST preserve ECT(0), ECT(1), and CE markings on all IP packets, except in the event of queue forming, where appropriate codepoints should be marked. Similarly, On-Path Nodes MUST NOT strip, modify, or drop packets containing TCP options 172 or 174.¶
Non-compliant behaviour can lead to timeouts and retransmits in the TCP handshake, and consequently to a degraded user experience.¶
On-Path Nodes MUST transparently forward SYN and SYN-ACK packets that negotiate ECN or AccECN. On-Path Nodes MUST NOT drop TCP handshake packets solely due to the presence of ECN negotiation flags or AccECN TCP options.¶
On-Path Nodes MUST NOT act on ECT(1) flags to prioritize traffic in alternative, non-compliant ways unless a valid end-to-end feedback loop is actively maintained—where the network nodes execute compliant congestion marking and the transport endpoints record and reflect those markings in line with the transport-specific requirements specified in Section 4.2 of [RFC9331].¶
Network deployments that don't support low-latency queues, and instead prioritise ECN marked traffic based on alternative heuristics (such as bandwidth allocation multipliers) are not an L4S deployment. The risk of such alternative mechanisms is incentivising marking ECT(1) codepoints in flows to be allocated into prioritised queues, without implementing full L4S congestion control as described in {#defense-against-misbehaving-traffic}. The convergence point of such behaviour would be a prevalence of ECT(1) marked traffic that does not respond to CE markings and congestion in the incorrectly prioritised queues.¶
L4S introduces potential abuse vectors where applications mark queue-building traffic as low-latency. As described in {#defense-against-misbehaving-traffic}, the link-layer subsystem MUST deploy queue protection mechanisms to defend the low-latency queue from starvation and latency degradation.¶
This document has no IANA actions.¶