Media-over-QUIC Transport vs. Low-Latency DASH: a Deathmatch Testbed

Low-Latency Dynamic Adaptive Streaming over HTTP (LL-DASH) leverages Common Media Application Format's (CMAF) chunked packaging and HTTP's chunked transfer encoding capabilities to cater to the demand for media delivery with latencies of those achieved by the traditional broadcast. Nevertheless, to achieve lower latencies in a scalable and reliable way, the Internet Engineering Task Force (IETF) recently started developing a QUIC-based solution, termed Media-over-QUIC Transport (MOQT). This paper presents the first testbed to compare LL-DASH and MOQT, comparing their performance and usability under different network conditions.


INTRODUCTION
Low-Latency DASH (LL-DASH) and Media-over-QUIC Transport (MOQT) are two different protocols for reducing the latency of media ingest and delivery.LL-DASH is an extension of the overa-decade-old Dynamic Adaptive Streaming over HTTP (DASH) standard [16], whereas MOQT, which is a QUIC-based protocol, is currently under development in the Internet Engineering Task Force (IETF).LL-DASH's primary use case is one-way, low-latency live streaming, where the end-to-end latency ranges between one and 10 seconds.This latency level is essential for a user experience similar to traditional broadcast TV or second-screen experiences where an event can simultaneously be consumed on multiple devices [17].On the other hand, MOQT's use cases additionally cover interactive experiences such as live commentary, betting, in-game wagering, online gambling and auctioning, where the endto-end latency is a second or less.Networked applications that require even stricter interactivity or control-feedback features such as videoconferencing, cloud gaming, remote control of hardware platforms (e.g., V2X applications, drones and surgical robots) and metaverse are also within MOQT's scope [13].
To date, there have been many implementations and demonstrations for LL-DASH.Open-source implementations are also available in popular media players such as dash.js[7], Shaka [9] and Exo-Player [8].For performance comparisons, recent studies about lowlatency live streaming (e.g., [2][3][4]21]) provide a detailed analysis.For the MOQT, though, implementations are still quite limited.[12] was the first study in this domain: it analyzed one of the initial proposals [5], introduced new essential features and created an open-source testbed [22].It also presented preliminary results for the server and client-side bandwidth measurements using different methods.Later, [10,11] explored MOQT's prioritization capabilities and showed results for two different schemes implemented on the testbed.Other MOQT demonstrations with different sets of features are available in [18,19].
To our knowledge, this paper is the very first study to propose a comprehensive testbed approach for performance comparison between LL-DASH and MOQT.The performance comparison is envisioned over a live streaming use case.Real-time results present how the latency, measured bandwidth and number of skipped frames change in addition to the latency-quality trade-off.

LL-DASH AND MOQT RECAP 2.1 LL-DASH
LL-DASH achieves low latency thanks to two essential technologies: chunked encoding/packaging (through Common Media Application Format, CMAF [14]) and chunked delivery.First, CMAF alone does not reduce latency, but it makes low-latency live streaming possible by splitting media segments into smaller, non-overlapping chunks.Second, chunked delivery helps deliver chunks to the media players as soon as they are ready without having to wait for the entire segment to be completely packaged.In LL-DASH, the manifest (MPD) of a live session indicates when a segment will start becoming available.Therefore, the LL-DASH client can request the live-edge segment immediately.This feature requires accurate client-server clock synchronization (using the UTCTiming element and Network Time Protocol (NTP; RFC 5905)).
The ProducerReferenceTime element in the MPD provides a correlation between media timestamps and wall-clock production time.This helps LL-DASH clients avoid possible clock drifts, and enables measuring and controlling the latency (as optionally specified using the ServiceDescription element indicating the minimum and maximum latency and playback speed values acceptable for the service).The same correlation information can also be provided as part of the media segments in the prft box, as defined in [15].

MOQT
MOQT is a latency-configurable delivery protocol transmitting from one or more publisher(s) to subscriber(s) through relays using either WebTransport (in browsers) or raw QUIC (elsewhere), as shown in Figure 1.Relays forward media to other relays or subscribers without requiring a unique encoding for each recipient.On the publisher and relay side, the protocol adapts to congestion and meets latency requirements by dropping or prioritizing packets based on certain metadata.Subscribers can also react to network conditions to meet user expectations.
Changing the transport protocol can be a game-changer when it comes to finding the optimum point for the quality and latency tradeoff.To explore the possibilities of improving timely media delivery, let us first consider the illustration in Figure 2. Suppose the latency budget is 50 ms for a specific, latency-sensitive application.We can use the data received within 50 ms and any data arriving with a higher latency is useless.In this case, let us assume the success rate (a proxy metric for quality) achieved by TCP is 10%.If there is a packet loss in the process, all need to be retransmitted since TCP is fully reliable and delivery of every packet is guaranteed.However, in such a case the timely transmission of all packets will be interrupted due to head-of-line blocking issues [12,20] and the latency budget will likely be exceeded.As we increase the latency budget (i.e., relax the latency requirement), TCP will eventually reach 100% success rate.
For the same latency-sensitive application, delivering media over QUIC may achieve a higher success rate for the same latency budget or have a lower latency for the same success rate.Aiming for a high success rate under a small latency budget is a challenging task.Determining an ideal latency budget for every application is not straightforward, but with its prioritization features, QUIC is expected to perform not worse than TCP.The current MOQT draft [6] describes two prioritization schemes: send order and ordering with priorities.

TESTBED IMPLEMENTATION
This testbed is designed so that the current (and newly developed) MOQT prioritization schemes can be explored and compared with an LL-DASH media player running under the same conditions.

Overall Setup
The testbed runs on a local area network with three computers, which are used as a publisher, relay and subscriber, as shown in Figure 3.The computers are connected to each other through an Ethernet switch.
The publisher is a Macbook Pro with an Apple M2 Pro 10-core CPU and 16GB memory, running macOS Sonoma version 14.1.FFmpeg version 6.0 and moq-pub 1 utility (commit id bafee96d) were used for sourcing real-time video from a webcam.
The relay is a PC with a 4-core (2 threads per core) Intel Core i5-1035G1 CPU and 8GB memory, running Ubuntu 22.04.3LTS with a kernel version 6.5.0-15-generic.Open-source applications, origin.js 2 and moq-relay 3 are used as the DASH origin server and the MOQT relay, respectively.Each is deployed as a docker container (v24.0.7).The base docker images for the DASH origin server and MOQT relay are node:latest and rust:bookworm, respectively.

Network Emulation
We use the traffic control (tc) utility on the originjs and moqrelay for network emulation.Specifically, we use hierarchical token bucket (htb) filter queuing discipline 5 to establish a controlled test environment.Two traffic classes and the corresponding filters are set up for the DASH and MOQT pipelines, as seen in Figure 6.Additionally, we establish two iptables rules to designate the UDP 1

Metrics Recorder
Traffic Shaper  datagrams from the moq-relay and TCP segments from the originjs.The marked packets are then directed by the tc filters to their respective tc classes for flexible bandwidth throttling and control.We developed a compact Node.js server application to control the bandwidth limits based on a user-selected value through the media player interfaces.It executes shell scripts to update the network configuration (e.g., bandwidth rates of the tc classes and adding/deleting iptables rules).

LL-DASH Configuration
FFmpeg6 is used to capture live webcam video in 1280x720 resolution and encode using the H.264/AVC codec into four different resolutions shown in Table 1, based on the recommendations from [1].Each frame is packaged into a CMAF chunk, and each group of pictures (GoP, 30 frames, one second) is packaged into a CMAF fragment and ingested to the originjs over HTTP.

MOQT Configuration
The same encoded live webcam feeds are piped to moq-pub, which then transmits the media to the moq-relay over QUIC.moq-pub creates a QUIC stream per GoP to map each GoP to a MOQT group, which includes each video frame as a MOQT object.
3.4.1 Client-Side Rate Adaptation.The moq-player continually measures bandwidth using the SWMA [12]   3.4.2Last-Come-First-Served (LCFS) Prioritization Scheme.In this method, the (MOQT) groups that are encoded later have higher priority.Hence, a subscriber is more likely to receive more recently encoded groups earlier than the older ones or before completely playing out the current group in case of network congestion.This allows the subscriber to stay close to the live edge by skipping older groups.

Cockpit: Real-Time Monitoring
Two streaming solutions were monitored on a separate page, displaying graphs for various metrics gathered from active streaming sessions.Both solutions report common metrics such as (1) latency, (2) measured bandwidth, (3) stall time, (4) video bitrate, and (5) skipped time.The players report these metrics through the Broadcast Channel API 7 .The tabs displaying the players and the cockpit page connect to the same channel.They utilize the 7 Available [Online]: https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API reported metrics independently, as players only report what has been measured since the last time.The reporting logic repeats the last measurement for metrics for which no new reporting was done to prevent discontinuities in the measurements.
The cockpit page has only one objective: to display these measurements in a proper way, enabling the spectator to judge which player performs better.This is achieved by selecting the proper visualization style for each metric, as shown in Figure 8.

CONCLUSIONS
The development of MOQT is still ongoing, and it has the potential to provide numerous benefits.Based on this test setup, we plan to conduct detailed tests on what we gain and lose by these two protocols.The next step is to analyze results from latency and throughput aspects under different bandwidth constraints over a live streaming use case.Then, a performance comparison of MOQT vs. LL-DASH will follow from a latency-quality tradeoff point of view.

Figure 2 :
Figure 2: Success rates for TCP vs. QUIC-based delivery for a given latency budget.Not to scale, for illustration only.

Figure 6 :
Figure 6: The tc htb design used in the testbed.

Table 1 :
method.When the The bitrate ladder used in the testbed.adaptivebitratemode(ABR) mode is on, the moq-player switches up to the track with the highest bitrate (hence, the highest quality) among the tracks where the measured bandwidth is not smaller than 2.25 times the track bitrate.When the measured bandwidth is lower than 1.5 times the current track's bitrate, the moq-player switches down to the track where the measured bandwidth is at least 1.5 times the track bitrate.Switching between the tracks consists of sending a SUBSCRIBE message for the new track followed by an UNSUBSCRIBE message for the current track as seen in Figure7.