Source-linked AI summary
Extending Low Latency Service Across the Internet
Harkirat Singh, Fatih Berkay Sarpkaya, Hakan Gulec, Fraida Fund, Shivendra Panwar
TL;DR
L4S low-latency benefits depend on isolation that is difficult to maintain at bottlenecks beyond the access link. This paper combines priority queues with rate caps, SRv6 steering, and BGP signaling, and evaluates the strategy on FABRIC. The experiments show recovery of L4S performance at targeted bottlenecks and under simultaneous upstream congestion, while identifying operational and evaluation-scope limitations.
Problem
L4S isolation is difficult to preserve when end-to-end paths contain non-L4S bottlenecks across independently administered networks.
Method
The paper combines priority isolation with rate caps, SRv6 path steering, and BGP community signaling to extend L4S service without upgrading every path router.
Results
The strategy recovers L4S application performance at sender-access, peering, and core bottlenecks and under simultaneous upstream congestion.
Takeaways & Limitations
The results demonstrate a practical incremental strategy for extending low-latency service across multiple bottleneck locations and domains.
Takeaways & Limitations
The FABRIC evaluation does not capture the full diversity of production Internet environments, including heterogeneous RTTs, asymmetric routing, failures, and frequent routing changes.
Abstract
from arXiv · showhide
Protocols such as L4S for low latency network services have attracted growing interest from major industry stakeholders such as Comcast, Apple, T-Mobile, and NVIDIA. However, L4S requires isolation between L4S flows and classic flows in order to maintain its low latency benefits and safe coexistence. The L4S architecture uses a DualPI2 AQM mechanism to provide this isolation when the bottleneck occurs at the home access link. In practice, however, bottlenecks may also occur at other locations in the network, such as peering points, ingress to wide area networks, or occasionally congested links in the core, where deploying DualPI2 AQM is not feasible. Without a solution to this problem, L4S may struggle to gain deployment, since its benefits may remain limited without end-to-end support. To address this challenge, we propose a deployment strategy that reduces the need to upgrade expensive core routers by using existing networking mechanisms such as BGP communities, SRv6, and priority queues with rate caps. We demonstrate the feasibility of this approach through large scale experiments on the FABRIC testbed. Our results demonstrate a practical deployment strategy for extending low latency service across the Internet, even across independently administered networks.
I. INTRODUCTION
L4S deployment is limited by coexistence problems and bottlenecks outside the receiver access link. The paper proposes combining deployable network mechanisms to preserve low-latency service across bottleneck locations and domains.
- Shared bottlenecks create a coexistence problem because scalable and loss-based transports rely on different queue depths and congestion-marking thresholds.
- Dual queue AQM isolates low-latency and classic traffic, but many end-to-end congestion points are impractical to upgrade across administrative domains.
- The proposed strategy combines priority isolation with rate caps, SRv6 path steering, and BGP community signaling.
- L4S deployment faces limited performance when bottlenecks occur away from the receiver access link.
- Systematic FABRIC experiments evaluate the strategy while minimizing required updates to core Internet routers.
- The authors make experiment materials available for validation and further development.
II. BACKGROUND AND RELATED WORK
L4S research has addressed architecture and access-network deployment, but related evaluations leave behavior at non-DualPI2 bottlenecks insufficiently established.
- L4S can provide low latency when its components are deployed together, especially at access-network bottlenecks.
- Partial deployment remains challenging because flows may encounter non-L4S bottlenecks or classic competing traffic elsewhere on the end-to-end path.
A. L4S Architecture
L4S combines scalable congestion control, accurate ECN feedback, and DualPI2 queue treatment to provide low delay and loss with scalable throughput. Its benefits depend on these components being present along the path.
- L4S is designed to provide low queuing delay, low loss, and scalable throughput.
- The architecture relies on scalable sender congestion control, accurate receiver ECN feedback, and an L4S-capable bottleneck queue.
- DualPI2 places ECT(1)-marked L4S traffic and classic traffic in separate coupled queues to share capacity while preserving low latency.
- TCP Prague is the reference scalable congestion control, while AccECN supplies the accurate congestion feedback required by scalable senders.
- Partial deployment is challenging when flows traverse bottlenecks without L4S support or compete with classic flows using non-scalable congestion control.
B. L4S deployment
L4S deployments and measurements show benefits for congested interactive traffic, but existing work does not establish performance across uncontrolled bottleneck locations. This motivates extending protection beyond the access network with minimal router upgrades.
- L4S is moving toward production deployment across Comcast, T-Mobile, Apple, and NVIDIA services and networks.
- Measurements find reduced tail latency for interactive traffic and bulk downloads, but limited benefit for short, bursty iCloud synchronization traffic.
- Comcast’s access-network dual-queue deployment does not address congestion elsewhere along end-to-end paths.
- Prior production and controlled studies do not isolate bottleneck locations or establish behavior at bottlenecks without DualPI2.
- The paper targets sender access, peering, transit, and core bottlenecks while minimizing L4S-specific upgrades across administrative domains.
C. L4S Coexistence in Partial Deployment
Partial deployment can leave L4S flows exposed to non-L4S bottlenecks and classic competition elsewhere on the end-to-end path. TCP Prague’s fallback heuristic helps reduce dominance over classic traffic, but reliably detecting such bottlenecks remains difficult.
- L4S traffic can dominate classic traffic when both share a single ECN-enabled queue.
- TCP Prague includes an ECN fallback heuristic intended to reduce this coexistence problem.
- Reliably detecting non-L4S bottlenecks remains difficult.
D. Congestion points
Congestion can occur beyond customer access networks, including within providers, at interdomain links, and on transit or WAN-ingress paths. Backbone-trace analysis further indicates queuing at or upstream of a monitored 100 Gbps link.
- Congestion may occur on intra-provider, interdomain peering, transit, and WAN-ingress links beyond the access edge.
- Congestion location differs across access technologies: DSL is more often last-mile limited, while cable commonly experiences middle-mile or beyond-access congestion.
- Most examined interdomain links showed little persistent congestion, but a small number carried prolonged, recurring congestion.
- A 100 Gbps backbone trace shows a substantial mass of packets arriving exactly at serialization time, implying queuing at or upstream of the monitor.
E. Experiment: Upstream Congestion Beyond the Access Link
The motivating experiment tests L4S with receiver-access Dual Queue AQM while placing FIFO bottlenecks at sender access, peering, or core locations. Upstream congestion reduces transport performance and harms video applications despite receiver-access support.
- The experiment compares an access baseline with three upstream FIFO bottlenecks: 1 Gbps sender access, 4 Gbps peering, and 4 Gbps core links.All scenarios include a 100 Mbps receiver-access Dual Queue AQM and 30 ms base RTT for L4S flows.
- 54 Mbps access-baseline throughput falls to 18.2 Mbps, 10.4 Mbps, and 27.9 Mbps in peering, sender-access, and transit scenarios, respectively.Average queuing delay increases by more than 13 ms in all three upstream-congestion cases.
- Upstream congestion introduces substantial video-streaming rebuffering and affects a large fraction of played chunks.
- Sender-access congestion is especially harmful for video calls, while peering and transit congestion can also create bad intervals through increased queuing delay.
- L4S performs well only when the congestion point matches the receiver-access Dual Queue AQM deployment assumption.Receiver-access L4S support does not protect flows from congestion earlier in the path.
III. ENABLING L4S DEPLOYMENT AT SCALE
The proposed strategy extends L4S isolation beyond the receiver access link using operator-familiar mechanisms rather than universal Dual Queue AQM upgrades. It combines local priority isolation, SRv6 path steering, and BGP signaling for supported interdomain paths.
- The strategy uses DSCP-based priority queuing with rate caps for local isolation at shared bottlenecks.L4S packets enter a low-latency queue with a configured cap to prevent starvation of best-effort traffic.
- Routers classify L4S traffic from ECN markings, apply a local DSCP value, and use existing DSCP-based queue selection within managed domains.DSCP markings are not assumed to remain preserved end-to-end.
- BGP communities identify routes advertised as supporting L4S and install them in a dedicated L4S routing table.Routes lacking the community use the main routing table, providing an experimental inter-AS signaling mechanism.
- SRv6 steers L4S packets toward an upgraded core router while classic packets follow the default core path.The configuration adds 80 bytes of encapsulation overhead, so the sender MTU is reduced from 1500 to 1420 bytes.
- The receiver access router retains Dual Queue AQM and, as an SRv6 endpoint, copies ECN bits from the outer to the inner header.
IV. EXPERIMENT METHODOLOGY
The experiments vary bottleneck location and deployment mechanisms on a multi-domain FABRIC topology, using mixed L4S/classic workloads and repeated trials to measure transport, router, and application behavior.
- Topology and scenarios: The evaluation varies bottleneck location and enabled mechanisms across controlled scenarios on a six-autonomous-system topology.The topology abstracts sender and receiver access networks, peering, L4S and legacy transit, and alternative intradomain paths.
- Bottleneck configurations: Five possible bottlenecks include receiver access with DualPI2, sender access with capped priority queues, peering, and L4S-supported or legacy transit cores.The receiver access bottleneck is 100 Mbps; sender access is 1 Gbps with a 200 Mbps L4S cap, while transit-core and peering queues are 4 Gbps.
- Deployment mechanisms: The design implements BGP community signaling, SRv6 steering, and independently configurable routing and queue mechanisms using FRRouting and Linux networking.The BGP community marks L4S-supporting paths, while SRv6 steers marked traffic onto an isolated internal path.
- Workload: The foreground workload combines emulated TCP Prague video streams, UDP Prague video calls, and short TCP Prague transfers with persistent and short TCP CUBIC traffic.The L4S workload includes three 10 Mbps video streams, four 5 Mbps video calls, and five 10 MiB transfers; classic traffic includes three persistent flows and five 5 MiB transfers.
- Metrics and trials: Each scenario is repeated for eight independent 120 s trials, measuring throughput, queuing delay, queue behavior, ECN marks, drops, application performance, RTT, and flow completion time.Video-call bad intervals are defined using achieved rate below 90% of target or mean RTT above 150 ms.
V. EXPERIMENT RESULTS
Figure 11 compares L4S application performance across eleven bottleneck scenarios, distinguishing the access baseline, upstream bottlenecks without mechanisms, and performance with the corresponding mechanism enabled.
- Figure 11 summarizes L4S application performance across the eleven scenarios evaluated in Figure 9b.
- The blue bar denotes the access baseline, red bars add an upstream bottleneck without its corresponding mechanism, and green bars show performance with that mechanism enabled.
- All scenarios include the receiver access DualPI2 bottleneck while varying upstream bottlenecks and deployment mechanisms.
A. Recovery by mechanism
Each mechanism recovers L4S performance at its corresponding upstream bottleneck, while full deployment restores performance under simultaneous congestion with a trade-off for short classic transfers.
- Priority queuing: Priority queuing eliminates sender-access rebuffering and reduces call p95 RTT from 89 ms to 31 ms and mean transfer time from 11 s to 6 s.At the peering bottleneck, it similarly reduces rebuffering to zero, call p95 RTT to 34 ms, and short-transfer time to about 5 s.
- SRv6 steering: SRv6 steering reduces transit-core call p95 RTT from 130 ms to 32 ms and restores mean transfer time to 9 s, although about 5 s of rebuffering remains.
- BGP community signaling: BGP community signaling reduces legacy-transit rebuffering from about 34 s to 2 s and call p95 RTT from 141 ms to 32 ms.It also raises call achieved rate from 3 Mbps to 4.97 Mbps and reduces mean transfer time from 21 s to 8 s.
- Full deployment: Under simultaneous upstream bottlenecks, full deployment reduces rebuffering from 79 s to zero, call p95 RTT from 312 ms to 36 ms, and mean transfer time from 60 s to 5.8 s.Call achieved rate rises from 1.3 Mbps to 4.96 Mbps, compared with 6 s mean transfer time in the access baseline.
- Classic traffic: Long CUBIC flows are not starved, but strict priority increases short-transfer FCT from 4.0 s to 9.4 s at peering and from 5.9 s to 11.8 s under all-heavy load.Weighted scheduling or minimum-service guarantees could reduce this trade-off, at the cost of weaker L4S isolation or capacity.
D. Microbenchmark: priority queue at saturation
The priority-queue microbenchmark tests capped L4S service under saturation and shows bounded L4S delay while classic traffic retains service. As the L4S queue approaches its cap, ECN marking limits queue growth and preserves residual capacity for classic traffic.
- Method: The microbenchmark uses CoDel with ECN marking, with a 1 ms ce_threshold for L4S and a 15 ms target for classic traffic.The experiment runs five 60 s trials at each offered-load point under two classic loads.
- Results: L4S goodput tracks offered load to about 175 Mbps before leveling off below the 200 Mbps cap.As the queue approaches saturation, ECN marking causes Prague to reduce its rate rather than letting the queue grow.
- Results: L4S average queueing delay remains roughly 2.5–3 ms across the offered-load sweep under both classic loads.The sweep uses 100–300 Mbps L4S offered load with classic loads of 500 Mbps and 1000 Mbps.
- Results: At 500 Mbps classic load, classic traffic receives its full offered rate while L4S approaches its service cap.The priority queue provides strict-priority isolation because deployment-scenario L4S load remains below the service cap.
- Results: At 1000 Mbps classic load, classic traffic converges to around 800 Mbps residual capacity with roughly 10 ms average queueing delay.The reported delay remains below the 15 ms classic-queue threshold once the L4S queue saturates.