Fake It No More: Evaluating L4S with SCReAM on Video Traffic Nawel Alioua
Ryan Zanone
UC Santa Barbara [email protected]
UC Santa Barbara [email protected]
Cheng Xi
Elizabeth Belding
UC Santa Barbara [email protected]
UC Santa Barbara [email protected]
arXiv:2607.23767v1 [cs.NI] 26 Jul 2026
Abstract The growing interest in Low Latency, Low Loss, and Scalable Throughput (L4S) reflects the need for lower latency in interactive multimedia applications. In this paper, we use an open-source DualPI2 implementation over the Mahimahi emulator to evaluate the impact of L4S on SCReAM congestion controlled video traffic. To do so, we augment the SCReAM BW tool with a video codec, enabling the generation of video traffic in addition to its original synthetic RTP mode. We evaluate both network-level and Quality of Experience (QoE) metrics on a mobile network trace, under random packet loss, and with different motion-complexity levels. In our baseline scenario, L4S reduces the median per-run 95𝑡ℎ percentile queue delay by 35%, at the cost of a 42% drop in sender throughput. Under 1% packet loss, L4S yields more pronounced QoE gains compared to the lossless scenario, despite narrower network-level benefits. Across video content complexities, L4S also maintains more stable QoE than Classic. These results underscore the importance of evaluating QoE alongside network-level metrics when assessing the effect of L4S on end-user application performance.
CCS Concepts • Networks → Transport protocols; Network performance evaluation; • Information systems → Multimedia streaming.
Keywords SCReAM, L4S, DualPI2, Mahimahi, network emulation, video streaming, QoE, AQM
1
Introduction
The increasing demand for low-latency and reliable real-time communication services has driven the development and adoption of the Low Latency, Low Loss, and Scalable Throughput (L4S) architecture [8, 6]. L4S, described in RFC 9330 [5], aims to provide low latency while maintaining high throughput. L4S uses Explicit Congestion Notification (ECN) to signal congestion early, thereby avoiding packet drops and enabling finer-grained rate adaptation through scalable congestion control at the end hosts. To facilitate this behavior, the bottleneck isolates L4S and Classic traffic into separate queues and signals queue growth promptly via ECN [18, 19]. At a high level, the L4S architecture relies on two main components: a L4S-compatible Active Queue Management (AQM) at the network bottleneck, and scalable congestion control at the end hosts. Dual-queue coupled AQMs, as described in RFC 9332 [19], differentiate between Classic and L4S traffic, providing low latency for
the latter while ensuring fair coexistence with the former. The DualPI2 AQM [2] is the de facto implementation of such a dual-queue coupled AQM in the Linux kernel. More recently, an implementation of DualPI2 within the Mahimahi emulator [16, 3] became available [1], making controlled L4S experimentation more accessible to the research community. As a scalable congestion control protocol, Self-Clocked Rate Adaptation for Multimedia (SCReAM) [10, 11] is designed for realtime multimedia traffic. It operates based on the self-clocking principle, aiming to send data at a rate comparable to the exit rate from the network, and is specifically optimized for mobile networks where variability and channel jitter are high [10]. SCReAM utilizes the Real-time Transport Protocol (RTP) to carry multimedia traffic, and expects feedback over the Real-time Transport Control Protocol (RTCP) to adjust its congestion window and sending rate. It supports non-ECN traffic; "classic" ECN where the congestion signal used is the ECN Congestion Experienced (CE) mark rather than the traditional packet drop; and L4S, where the rate reduction is proportional to the fraction of ECN CE-marked packets. SCReAM has been standardized as RFC 8298 [11] in 2017, and work is ongoing on its updated version SCReAMv2 [12]. SCReAM is available as an open-source project [7], integrated within a bandwidth probing tool (the BW tool). However, this tool only supports fake RTP traffic generation. While this capability is valuable for early-stage experimentation and for debugging under various network conditions, it poses a limitation for more realistic traffic testing, such as Quality of Experience (QoE) evaluation of video traffic. More broadly, to assess not only SCReAM itself but also the L4S paradigm end-to-end, experiments should capture the interaction between congestion control and realistic multimedia traffic generation. This work extends the BW tool with video encoding support to enable such experiments with actual video traffic. We then use this extension to evaluate SCReAM over Classic and L4S modes in a Mahimahi-based setup, considering both network-level and QoE metrics. Enabling such traffic generation in the BW tool therefore provides the community with a practical platform for studying L4S performance on multimedia applications. Our main contributions are the following: • We extend the SCReAM BW tool with encoded video traffic capabilities, moving beyond its original synthetic-traffic operation and enabling controlled experiments with actual video content. • We compare SCReAM in Classic and L4S modes on Mahimahi emulated DualPI2 AQM using both synthetic and actual video traffic, highlighting how application-level video
Nawel Alioua, Ryan Zanone, Cheng Xi, and Elizabeth Belding
behavior complements network-level observations from synthetic traffic. • We show that L4S improves key network and playbackrelated metrics, compared to Classic traffic mode, and remains relatively stable across video content of different motion complexity, while also examining robustness under random loss. • We publicly release the encoder-augmented BW tool to support reproducible evaluation of SCReAM congestioncontrolled video traffic1 .
2
Integrating Video Encoding into the SCReAM BW Tool
In this section, we describe the design and implementation choices made while integrating a video codec into the SCReAM BW tool. Our goal is to move beyond the tool’s original synthetic RTP traffic generation and enable controlled experiments with encoded video traffic, while preserving the BW tool’s role as a lightweight and reproducible evaluation platform. For this task, We took inspiration from the Ringmaster project [14], which not only includes encoder and decoder components, but also incorporates several practical features that improve streaming robustness and make it a useful reference point as a lightweight tool for video streaming and conferencing research [17].
2.1
Video codec
We use VP9 [15], an open-source video codec introduced by Google and implemented in libvpx [20]. VP9 is a suitable choice for our integration because it is widely available, open source, and supported in WebRTC implementations [13]. The general design of the encoder and decoder modules was modeled after Ringmaster, while introducing appropriate adaptations to the SCReAM- and BW tool-specific hook points and module interfaces.
2.2
Main interactions with the SCReAM congestion controller
The integration of VP9 into the SCReAM BW tool mostly follows a pull-based interaction model, where the sender and encoder query the SCReAM API and then act according to the returned values. However, the codec also passes information back to SCReAM to maintain accurate controller state. We summarize the main interactions below. SCReAM to codec signals. In our implementation, these signals are exposed as return values from SCReAM API calls rather than as callbacks. Target bitrate and packetization guidance: The main interface between the encoder and SCReAM is the transmission of the estimated target bitrate. SCReAM provides the target bitrate through the getTargetBitrate() function and the Maximum Segment Size (MSS) through the getRecommendedMss() function. These two
values are then passed to the encoder to guide the encoding and packetization of the next frame. Loss indication: SCReAM can also inform the encoder about packet loss occurring on the medium through the isLossEpoch() function. We use this signal, in addition to the case where getTargetBitrate() returns a negative value, to request a keyframe from the encoder. We discuss keyframe injection mechanisms in more detail in §2.3. Codec to SCReAM signals. The reverse direction of the interaction consists of state updates from the media pipeline back to SCReAM. For every RTP packet produced as part of an encoded frame, the encoder calls the newMediaFrame() function as a mediaproduction notification. It also uses the addTransmitted() function after every actual RTP packet transmission to update SCReAM’s state, ensuring that the congestion controller tracks the packets that have effectively left the interface. On the decoder end, the SCReAM function receive() is called upon reception of an RTP packet, thereby updating SCReAM’s view of packet arrivals at the receiver. The function createStandardizedFeedback() is called when an RTCP feedback message is about to be formed, allowing the receiver to generate the feedback required to close the congestion-control loop.
2.3
Keyframe injection
We introduce several keyframe generation techniques that can be enabled using command-line options, some of which can be combined. To avoid excessive keyframe generation, we do not request more than one keyframe within any 100 ms interval, following a similar implementation in the SCReAM source code.2 With the exception of the periodic mode, these mechanisms can be enabled simultaneously. Keyframes triggered by target bitrate estimation. If the getTargetBitrate() function returns a negative value, a keyframe is requested immediately from the encoder as recommended in the codebase.3 This function returns -1 when SCReAM detects a severe recovery condition, such as an RTP queue discard event, an ACK received outside the window and therefore treated as lost forever, or a late ACK, also treated as lost. Importantly, the function emits -1 as a one-shot recovery signal rather than as a persistent rate value. After that first emission, subsequent calls return the regular target rate again until a new loss/discard episode occurs. Keyframes triggered by loss. If the isLossEpoch() function returns true, then we wait for 100 ms before forcing a keyframe. isLossEpoch() returns true when packet loss causes a nonzero lost-rate update, or when SCReAM discards packets from an overgrown RTP queue. After a loss is detected, the function clears the internal flag so repeated calls return false until another new loss epoch is detected.
2 https://github.com/EricssonResearch/scream/blob/master/code/wrapper_lib/scre 1 https://github.com/5G-VCA-CC/scream
amtx_plugin_wrapper.cpp#L859 3 https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.h#L329
Fake It No More: Evaluating L4S with SCReAM on Video Traffic
Keyframes triggered by long-standing unacked packets. This mechanism was ported from Ringmaster [14]. In this case, a keyframe is triggered if the oldest transmitted packet has remained unacknowledged for at least one second. This process also triggers the clearing of the transmitted packet history up to that point.
used to characterize application performance, followed by additional execution details, including the runtime environment and run configuration.
Periodic keyframes. This mode generates periodic keyframes every 𝑛 seconds, provided as a command-line parameter. Contrary to the existing periodic keyframe generation in the original BW tool, we do not prescribe a fixed multiplier for the size of the keyframe. Instead, we let the encoder decide what size a keyframe can reach based on the instantaneous target bitrate signal obtained from the congestion controller.
We use the Mahimahi emulator [16], a widely used tool in networking and multimedia systems research for its high configurability and ability to conduct experiments under diverse network scenarios. We use the Mahimahi DualPI2 AQM implementation [3, 1] to emulate the dual-queue bottleneck. Mahimahi provides a number of network traces by default; for our experiments, we select the short Verizon LTE trace. Table 1 summarizes the characteristics of this uplink trace, obtained by running iperf3 for the entire trace duration (140 seconds) using UDP to saturate the link, and logging the receiver throughput at 1 s intervals. The trace presents a considerable range of throughput values, with bouts of completely interrupted connectivity (0.0 Mbps). These conditions allow us to stress-test the SCReAM congestion-controlled video flow in a fluctuating network environment.
2.4
Extra features
Packet retransmission. A smooth video playback requires minimizing packet loss, and retransmission is a key component in achieving this. To support retransmissions, we change the underlying implementation of the RTP queue data structure to a deque, which allows packets that need to be retransmitted to be queued at the front, effectively prioritizing them over newly generated packets. RTP header extension. We introduce additional RTP header fields for reconstruction of the video flow, consisting of a keyframe indication, the fragment count, and frame and fragment identifiers. These RTP extension fields let the receiver identify frame boundaries and fragment ordering explicitly, so the decoder can safely skip incomplete or lost frames up to the next complete keyframe.
3
Experiment Setup & Methodology
This section describes the experimental setup and methodology used to evaluate how L4S affects SCReAM video traffic relative to Classic mode. We begin by presenting the Mahimahi-based emulation environment and the DualPI2 parameters used in our experiments. We then describe the evaluation metrics and video samples Throughput [Mbps]
20
3.1
Emulation system
Table 1: Per-Second throughput statistics of the Mahimahi uplink Verizon-LTE-short trace (Mbps) Trace
Duration (s)
Min
Max
Avg.
SD
Verizon
140
0.00
12.90
5.81
3.07
To validate the behavior of the Mahimahi DualPI2 AQM in the presence of L4S and Classic traffic, we perform a sanity check by running the SCReAM BW tool in its original fake RTP traffic mode through a Mahimahi setting with a fixed-rate trace of 12 Mbps and a Round-Trip Time (RTT) of 20 ms, for each of the L4S (-ect 1) and Classic modes (no -ect). The parameters of the DualPI2 AQM used in this experiment, and throughout the rest of this work, are detailed in §3.2. The results depicted in Fig. 1 show time-series plots of key metrics over a single 20-second run, including throughput, queue delay, and RTT for both modes. The behavioral differences we observe between L4S and Classic are similar in type and scale to Throughput [Mbps]
20 Transmitted RTP ACKed Target Loss
10 0
Transmitted RTP ACKed Target Loss
10 0
CWND(B) and bytes in flight(R) [kByte]
CWND(B) and bytes in flight(R) [kByte]
40
50
20
0
0
Congestion mark [%]
Congestion mark [%]
100
100
50
50
0
0
Network queue(B) and RTT(R) [s]
Network queue(B) and RTT(R) [s]
0.05
0
0.05
0
5
10
15
T [s]
(a) classic
20
25
0
0
5
10
15
T [s]
(b) L4S
Figure 1: Classic vs. L4S time-series metrics running synthetic RTP flows over Mahimahi DualPI2
20
25
Nawel Alioua, Ryan Zanone, Cheng Xi, and Elizabeth Belding
those reported in the main BW tool repository [7], supporting the use of the Mahimahi DualPI2 module for further experimentation.
3.2
DualPI2 parameters
We use the same default DualPI2 parameters as stated in RFC 9332 [19], namely 𝑡𝑎𝑟𝑔𝑒𝑡 = 15 ms, 𝑠𝑡𝑒𝑝_𝑡ℎ𝑟𝑒𝑠ℎ = 1 ms, 𝑡𝑢𝑝𝑑𝑎𝑡𝑒 = 16 ms, 𝑎𝑙𝑝ℎ𝑎 = 0.16, and 𝑏𝑒𝑡𝑎 = 3.20. In addition, we set 𝑙𝑖𝑚𝑖𝑡 = 100 packets.
3.3
Evaluation metrics
We collect execution logs consisting of a 2-second periodic output at the sender and the receiver, as well as a final per-run summary. Then, we extract the following metrics: Transmission and reception (Tx/Rx) rates: Actual sender transmit bitrate and the measured receive throughput. Queue delay: Estimated one-way queuing delay. Packet loss: Sender observed loss from feedback/loss detection as a percentage of total throughput. Inter-frame (IF) delay: Time between two consecutive completed frames at the receiver. Freeze count: Following the definition in WebRTC statistics [4], a freeze is counted when: Δ𝑡 > max 3 × 𝑇¯𝑓 , 𝑇¯𝑓 + 150 , where Δ𝑡 is the gap in ms between two consecutive rendered frames, and 𝑇¯𝑓 is the average frame duration in ms. Freeze duration: Cumulative freeze duration of rendered frames experiencing a freeze as per the above definition.
3.4
Video samples
Video content differs in the level of motion complexity, generally quantified as Temporal Information (TI), which is defined as the amount of temporal changes in a video sequence between one frame and the next [9]. To study the effect of motion complexity on the performance of L4S and Classic video flows, we consider low-, medium-, and high-motion levels, and pick one 10-second video sample for each category.4 To verify the motion complexity level of each representative video, we use the ffmpeg tool and log a per-frame TI value for each considered video. The statistics summarized in Table 2 confirm that the selected clips span increasing levels of temporal complexity, from low to high motion. Table 2: Per-frame Temporal Information (TI) for three sample videos Sample Video
Level
Min
Max
Avg.
SD
akiyo_cif.y4m news_cif.y4m foreman_cif.y4m
Low Medium High
0.95 1.10 4.04
6.80 35.21 42.22
2.99 7.86 17.20
1.37 4.6 8.55
4 Xiph.org Test Media Collection. https://media.xiph.org/video/derf/
3.5
Experimental Procedure
Our experiments are conducted on a 14-core Intel Core Ultra 5 225H system with 64 GB of RAM running Ubuntu 24.04. Because the Mahimahi trace described in §3.1 lasts 140 seconds, we loop each video sample as needed to span the full trace and capture all network fluctuations. For each experiment, we collect data from 50 such 140-second runs. In the video-based experiments, we combine three keyframe generation techniques: target bitrate-based, lossbased, and unacked-packet-triggered, while enforcing the condition stated in §2.3 that no two keyframes are generated within any 100 ms period.
4
Experiment Results
This section presents the results of three different experiments in terms of the metrics described in §3.3. Our goal in the first experiment is to understand and quantify the effect of L4S on the performance of a video flow in a mobile network scenario with an average RTT of 20 ms. In the second experiment, we examine the effect of introducing a random emulated packet loss on said performance. In the last experiment, we investigate how the video motion complexity influences the observed performance differences.
4.1
Main test case: Medium motion complexity video
To understand the effect of applying L4S to a video flow, we run the medium-motion video through the DualPI2 bottleneck over the Verizon LTE trace with 20 ms RTT. Fig. 2 shows the results for both Classic and L4S flows. At the network level, L4S reduces the median per-run 95𝑡ℎ percentile queue delay from 35.8 ms in Classic to 23.1 ms, a 35.5% reduction, but this comes with a 42.4% drop in sender throughput, from about 3.0 Mbps to 1.7 Mbps. In this baseline case, packet loss remains zero for both Classic and L4S, indicating that the observed differences are not due to drops. At the playback QoE level, the inter-frame (IF) delay changes only slightly: the median decreases from about 33.6 ms in Classic to roughly 33 ms in L4S, with L4S also exhibiting a slightly tighter distribution around the median. Freeze behavior improves more clearly under L4S. The median freeze count decreases from 17 events in Classic to 15 in L4S, while the median freeze duration decreases from 6.33 s to 5.9 s, corresponding to reductions of about 12% and 6%, respectively. Sanity check against synthetic traffic. Adding video encoding to the BW tool raises the question of whether the video pipeline preserves SCReAM’s original transport-level behavior. To answer this, we repeat the main scenario using the BW tool’s original fake RTP traffic mode and summarize the resulting network-level metrics in Fig. 3. The Tx/Rx rates, queue delay, and packet loss closely match those of the video-traffic case, showing that the encoder-integration preserves, at the network metric level, the intended SCReAM control behavior seen with synthetic traffic for both Classic and L4S flows.
4.2
Effect of random packet loss
We introduce a 1% random packet loss through Mahimahi. This setting introduces measurable loss and allows us to compare Classic and L4S under non-negligible drop conditions.
33.8 33.7 33.6 33.5 33.4
L4S
(b) Queue Delay (P95)
CDF
IF Delay (ms)
(a) Tx/Rx Rate
Classic
1.00
0.75
0.75
0.50 0.00
L4S
(d) Median IF Delay
15
Classic L4S 20
(e) Freeze Count (#)
Classic
L4S
(c) Packet Loss
1.00
0.25 Classic
0.00
0.50 Classic L4S 7
0.25 0.00
6
(f) Freeze Duration (s)
2.5 2 Classic
L4S
(a) Tx/Rx Rate
40 35 30 25 20
Packet Loss (%)
Tx Rx
3
Queue Delay (ms)
Avg. Rate (Mbps)
Figure 2: Classic vs. L4S for medium-motion video
Classic
L4S
0.03 0.01 0.00
(b) Queue Delay (P95)
Classic
L4S
(c) Packet Loss
1.5 1
Classic
L4S
Classic
L4S
(b) Queue Delay (P95)
0.15
0.05 0.00
1.00
0.75
0.75
0.25
40 Classic
L4S
(d) Median IF Delay
0.00
10
Classic L4S 15 20
(e) Freeze Count (#)
CDF
1.00 0.50
L4S
(c) Packet Loss
60 50
Classic
3.1
Tx Rx
3 2.9 2.8
Low
Medium
0.25 6
Classic L4S 8
(f) Freeze Duration (s)
Figure 4: Classic vs. L4S for medium-motion video with a 1% packet loss rate
Fig. 4 shows that L4S still reduces the median per-run 95𝑡ℎ percentile queue delay, from 79.7 ms in Classic to 62.1 ms, a 22% reduction, while the sender throughput decreases from 1.8 Mbps to 1.3 Mbps, a 27.7% drop. Compared to the no-loss scenario, the gap between Classic and L4S narrows in terms of the queue delay as well as throughput, while the spread of these metrics increases, especially in the Classic mode. At the sender, the detected packet loss remains negligible in both regimes and is slightly higher under L4S, with a median of 0.029% versus 0.026% for Classic. Both values remain far below the injected 1% link loss, reflecting the effect of retransmissions. At the playback level, the median IF delay is identical in both cases at 35 ms, but L4S exhibits a narrower interquartile range
Tx Rx
1.8 1.7
High
Low
(a) Classic Tx/Rx Rate
0.50 0.00 4
Effect of video motion complexity
In this experiment, we use the same Verizon LTE trace with a 20 ms RTT and no loss. Fig. 5 summarizes the transmission and reception rates obtained for the different motion-complexity regimes. We notice that the Tx/Rx rate does not necessarily correlate monotonically with the motion complexity level. Indeed, higher-motion content does not automatically translate into a higher transmitted rate, since the encoder can react to increased temporal complexity by compressing more aggressively, restraining the output rate. As a result, content complexity is filtered through the joint behavior of the encoder and SCReAM, rather than being reflected directly in the network load.
0.10
70
CDF
IF Delay (ms)
(a) Tx/Rx Rate
200 150 100 50
Packet Loss (%)
Tx Rx
2
Queue Delay (ms)
Avg. Rate (Mbps)
Figure 3: Classic vs. L4S for synthetic RTP traffic
4.3
Avg. Rate (Mbps)
L4S
CDF
Classic
0.01
(34–37 ms vs. 34–40 ms), indicating a more concentrated distribution and more stable playback across runs. The median freeze count decreases from 17 in Classic to 14 in L4S, corresponding to a 17.6% reduction. The median freeze duration decreases from 6.15 s in Classic to 5.7 s in L4S, a reduction of about 7%. Both reductions are larger than in the baseline lossless scenario. Overall, while the network-level gap between Classic and L4S narrows in the presence of random loss, the QoE advantage of L4S becomes more pronounced. This suggests a greater benefit of SCReAM in L4S mode under fluctuating, loss-prone mobile network conditions, and reinforces the need to analyze QoE alongside network metrics to capture the full application-level impact.
Medium
High
(b) L4S Tx/Rx Rate
Figure 5: Tx/Rx rates for different motion levels
However, we can see from Fig. 6a that SCReAM in L4S mode shows higher stability in queuing delay than Classic across all motion levels, which translates into a more stable median IF delay, as shown in Fig. 6b.
40 35 30 25 20
IF Delay (ms)
2
0.03
Avg. Rate (Mbps)
2.5
40 35 30 25 20
Queue Delay p95 (ms)
Tx Rx
Packet Loss (%)
3
Queue Delay (ms)
Avg. Rate (Mbps)
Fake It No More: Evaluating L4S with SCReAM on Video Traffic
Classic L4S
Low
Medium
(a) Queue Delay (P95)
High
33.8 33.7
Classic L4S
33.6 33.5 33.4
Low
Medium
High
(b) Median IF Delay
Figure 6: P95 queuing delay and median IF delay for different motion levels
Nawel Alioua, Ryan Zanone, Cheng Xi, and Elizabeth Belding
5
Conclusion
We extended the SCReAM BW tool with a video codec, enabling experiments with video traffic in addition to its original synthetic RTP traffic mode. Using this extension with Mahimahi, we evaluated SCReAM over Classic and L4S modes on a mobile network trace and under random packet loss, considering both network-level and QoE metrics. We find that L4S reduces the median per-run 95𝑡ℎ percentile queue delay by 35%, at the cost of a 42.4% drop in sender throughput. Under a 1% random loss, the network-level gap between Classic and L4S narrows, but the QoE advantage of L4S becomes more pronounced, with the reduction in freeze count increasing from 12% in the lossless scenario to 17% with 1% random loss. Across different motion-complexity levels, L4S also shows greater stability than Classic in terms of median inter-frame delay. These results also highlight the importance of evaluating L4S not only through network metrics, but also through application-level QoE metrics on actual video traffic.
Acknowledgments We thank Dr. Francis Yan for his sustained guidance and valuable feedback throughout the development of this work.
References [1] [2]
[3]
[4]
[5]
[6]
[7] [8]
[9]
[10]
[11] [12]
[13]
[14]
5G-VCA-CC. 2026. Mahimahi DualPI2. https://github.com/5G-VCA-CC/mahi mahi. Accessed: 2026-07-19. (2026). Olga Albisser, Koen De Schepper, Bob Briscoe, Olivier Tilmans, and Henrik Steen. 2019. DUALPI2: Low Latency, Low Loss and Scalable (L4S) AQM. In Proceedings of the Netdev 0x13 Conference. Nawel Alioua, Linghe Zhang, Aneesh Garg, Francis Y. Yan, and Elizabeth Belding. 2026. A DualPI2 Module for Mahimahi: Behavioral Characterization and Cross-Platform Analysis. (2026). arXiv: 2603.04381 [cs.NI]. Harald Alvestrand, Varun Singh, and Henrik Boström. 2025. Identifiers for WebRTC’s Statistics API. W3C Candidate Recommendation Draft. Accessed: 2026-04-15. World Wide Web Consortium (W3C), (Sept. 2025). https://www.w 3.org/TR/webrtc-stats/. Bob Briscoe, Koen De Schepper, Marcelo Bagnulo, and Greg White. 2023. Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture. RFC 9330. (Jan. 2023). Comcast. 2025. Comcast Introduces Nation’s First Ultra-Low Lag Xfinity Internet Experience with Meta, NVIDIA, and Valve. Corporate press release, Jan. 29, 2025. Accessed Jan. 27, 2026. (Jan. 2025). https://corporate.comcast.com/press/r eleases/comcast-introduces-nations-first-ultra-low-lag-xfinity-internet-ex perience-with-meta-nvidia-and-valve. Ericsson Research. 2026. SCReAM. https://github.com/EricssonResearch/screa m. Accessed: 2026-04-15. (2026). Kelly Hill. 2025. Test and Measurement: Comcast Touts ‘Ultra-low Lag Connectivity’ Using L4S. RCR Wireless News Article; Accessed 2026-01-27. (Jan. 2025). https://www.rcrwireless.com/20250129/uncategorized/comcast-l4s. ITU-T. 2023. Subjective Video Quality Assessment Methods for Multimedia Applications. Recommendation P.910. Accessed: 2026-04-15. International Telecommunication Union, (Oct. 2023). https://www.itu.int/rec/T-REC-P.910. Ingemar Johansson. 2014. Self-Clocked Rate Adaptation for Conversational Video in LTE. In Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop (CSWS ’14). Association for Computing Machinery, Chicago, Illinois, USA, 51–56. Ingemar Johansson and Zaheduzzaman Sarker. 2017. Self-Clocked Rate Adaptation for Multimedia. RFC 8298. (Dec. 2017). Ingemar Johansson, Magnus Westerlund, and Mirja Kühlewind. 2026. SelfClocked Rate Adaptation for Multimedia. Internet-Draft draft-johansson-ccwgrfc8298bis-screamv2-07. Work in Progress. Internet Engineering Task Force, (Mar. 2026). 40 pp. MDN contributors. 2025. Codecs used by WebRTC. Accessed: 2026-04-14. MDN Web Docs. (May 2025). https://developer.mozilla.org/en-US/docs/Web/Media /Guides/Formats/WebRTC_codecs. Microsoft. 2023. Ringmaster. https://github.com/microsoft/ringmaster. Accessed: 2026-04-14. (2023).
[15]
[16]
[17]
[18]
[19]
[20]
Debargha Mukherjee, Jingning Han, Jim Bankoski, Ronald S Bultje, Adrian Grange, John Koleszar, Paul Wilkins, and Yaowu Xu. 2015. The Latest Opensource Video Codec VP9 - An Overview and Preliminary Results. SMPTE Motion Imaging Journal, 124. Ravi Netravali, Anirudh Sivaraman, Somak Das, Ameesh Goyal, Keith Winstein, James Mickens, and Hari Balakrishnan. 2015. Mahimahi: Accurate Record-andReplay for HTTP. In Proceedings of the 2015 USENIX Conference on Usenix Annual Technical Conference (USENIX ATC ’15). USENIX Association, Santa Clara, CA, 417–429. isbn: 9781931971225. Michael Rudow, Francis Y. Yan, Abhishek Kumar, Ganesh Ananthanarayanan, Martin Ellis, and K.V. Rashmi. 2023. Tambur: Efficient Loss Recovery for Videoconferencing via Streaming Codes. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, (Apr. 2023), 953–971. isbn: 978-1-939133-33-5. https://www.usenix.org/co nference/nsdi23/presentation/rudow. Koen De Schepper and Bob Briscoe. 2023. The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S). RFC 9331. (Jan. 2023). Koen De Schepper, Bob Briscoe, and Greg White. 2023. Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S). RFC 9332. (Jan. 2023). The WebM Project. [n. d.] libvpx: VP8/VP9 Codec SDK. https://www.webmpro ject.org/code/. Accessed: 2026-04-14. ().