Pith. sign in

REVIEW 4 major objections 5 minor 24 references

Streaming Remote rendering services: Comparison of QUIC-based and WebRTC Protocols

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that RTP over QUIC (RoQ) currently gives the lowest end-to-end latency for remote-rendered XR video over Wi-Fi and 5G, that QUIC-based transports also connect faster than WebRTC, and that Media over QUIC (MoQ) trails on…

desk verdict A useful first three-way latency comparison of MoQ/RoQ vs WebRTC for remote rendering, but the headline QUIC advantage is overstated and confounded by immature implementations. read the letter →

arxiv 2505.22132 v1 pith:2YE4N7FO submitted 2025-05-28 cs.NI

Daniel Mejías , Inhar Yeregui , Ángel Martín , Roberto Viola , Pablo Angueira , Jon Montalbán This is my paper
classification cs.NI
keywords remoterenderingExtendedRealityQUICRTPoverMediaWebRTC5Glow-latencystreaming
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish which real-time video transport protocol is ready to carry remote-rendered XR content with the least delay. It compares WebRTC, RTP over QUIC (RoQ), and Media over QUIC (MoQ) over Wi-Fi 6 and a private 5G network, streaming H.264 video from a game-engine renderer to a spectator player. Its central result is that QUIC-based transports start connections faster than WebRTC and that RoQ achieves the best end-to-end latency, for example 215 ms versus 288.83 ms for WebRTC at 1080p over Wi-Fi, while MoQ's relay adds roughly double the latency. The paper also finds that WebRTC remains the most mature and stable implementation, with lower jitter and byte loss than the early-stage QUIC stacks.

What carries the argument

The load-bearing machinery is the set of three protocol stacks: WebRTC, which negotiates a peer-to-peer channel through a signaling server and then carries RTP; RTP over QUIC (RoQ), which encapsulates RTP packets inside QUIC after a UDP handshake; and Media over QUIC (MoQ), which muxes fragmented MP4 media and pushes it through a relay server that the client subscribes to. The startup differences follow from the negotiation path: QUIC collapses setup into a handshake, while WebRTC needs signaling, and MoQ starts generating traffic toward the relay even before the client redirects it, which explains both its fastest startup and its latency penalty.

What would settle it

Repeat the 1080p/30 fps H.264 test over the same private 5G link using a mature, officially maintained RoQ implementation with packet-loss recovery; if end-to-end latency is no longer below WebRTC's, the paper's central claim that RoQ lowers latency is falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that, under the tested conditions, RoQ delivers the lowest end-to-end latency among the three protocols, and both QUIC-based protocols connect faster than WebRTC. The authors attribute the startup advantage to QUIC's single UDP handshake replacing WebRTC's signaling negotiation, and they attribute MoQ's high latency to its relay-based publisher/subscriber delivery path. The abstract's expected figure of roughly 30% latency improvement is supported for RoQ by the measured Table I values, whereas MoQ's measured latency is about 100% higher than WebRTC's. The paper further claims that WebRTC still leads in stability, jitter, and byte-loss behavior, and that the open-source QUIC implementations are not yet mature enough for production use.

Load-bearing premise

The central claim leans on the assumption that the early-stage, unofficial open-source implementations of RoQ and MoQ faithfully represent the protocols; if those implementations are unrepresentative, the measured latency differences reflect software maturity rather than protocol design.

Editorial extensions

If this is right

  • RoQ becomes the strongest of the three candidates for latency-critical remote rendering of 360-degree video at 30 fps, once its stability approaches WebRTC's.
  • Connection startup for XR sessions can be shortened substantially by choosing a QUIC-based transport, because MoQ and RoQ both avoid WebRTC's signaling negotiation.
  • MoQ's relay-based delivery roughly doubles end-to-end latency in these measurements, making it a poor fit for interactive latency-sensitive viewing unless relay overhead is reduced.
  • The 5G link often yields lower end-to-end latency than Wi-Fi once a session is established, so access-network choice matters after startup even when the protocol choice dominates the initial handshake.
  • WebRTC remains the robustness benchmark: it had the best jitter and byte-loss behavior, so QUIC adoption needs implementation maturity work rather than latency gains alone.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The abstract's 'approximately 30%' latency improvement is best read as an expected figure for RoQ specifically; MoQ's measured latencies are higher than WebRTC's, so the headline number should not be generalized to all QUIC-based transports.
  • Part of MoQ's latency penalty may come from fragmented-MP4 muxing and the lack of audio in its early elements, so a follow-up with equivalent encapsulation could separate relay cost from implementation cost.
  • Because the measurements ran on a private 5G network with no competing traffic, a loaded public network could change the relative ranking; testing under congestion would be the natural extension.
  • The paper's suggested multipath-QUIC direction could be turned into a concrete test: enable simultaneous 5G and Wi-Fi paths and measure whether latency and startup improve under handover.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents a measurement study of three real-time streaming protocols—WebRTC, RTP over QUIC (RoQ), and Media over QUIC (MoQ)—in the context of a remote-rendered XR/holographic conferencing service. The authors build a Unity-based remote renderer with a GStreamer plugin, deploy it on a Kubernetes cluster with an NVIDIA vGPU, and evaluate the protocols over Wi-Fi 6 and a private 5G SA network. They measure connection startup time, end-to-end latency, CPU/GPU utilization, throughput, jitter, and byte loss at 1080p/720p/480p, and report results in three tables. The central claim, stated in the abstract, is that QUIC-based protocols improve latency by approximately 30% and connection startup by approximately 60% compared to WebRTC.

Significance. If the claims were supported, the paper would be a useful empirical contribution to the ongoing evaluation of QUIC-based media transport for XR services. Its strengths include a realistic private 5G testbed, a distributed containerized deployment, concurrent measurement of resource consumption and network-level metrics, and a direct comparison of two QUIC-based protocols with WebRTC using open-source frameworks. The paper is less persuasive as a protocol-level comparison because the findings are presented as general QUIC advantages while the data show a heterogeneous picture: RoQ often improves latency, MoQ consistently worsens it, and the QUIC implementations are admitted to be immature and loss-prone. The stated 30% latency improvement is therefore not established for 'QUIC-based protocols' as a class.

major comments (4)
  1. [Abstract and Section IV-A, Table I] The abstract's claim that 'Improvements of approximately 30% in latency ... are expected in QUIC-based protocols compared to WebRTC' is contradicted by the paper's own data: MoQ shows higher latency than WebRTC in every configuration (e.g., 559.83 ms vs 288.83 ms on Wi-Fi 1080p), while only RoQ shows an improvement (215.00 ms on the same row). The conclusion in Section V repeats this conflation. The central claim must be restricted to RoQ, or the paper must separately discuss why MoQ's relay-based design incurs higher latency.
  2. [Section III-B and Section IV-A] The latency comparison is confounded by implementation maturity. The authors state that RoQ's GStreamer support 'is still in an early stage and lacks full stability' and that MoQ uses unofficial elements without audio support; Section IV-A adds that RoQ 'lacks mechanisms for handling transmission errors.' Table III quantifies the consequence: RoQ and MoQ exhibit 2.67% and 2.85% byte loss over Wi-Fi versus 0.02% for WebRTC. If RoQ achieves lower latency by omitting retransmission or buffering of lost packets, the reported latency gain cannot be attributed to the QUIC protocol design. The paper should either control for this confound or explicitly frame the results as a comparison of current open-source implementations.
  3. [Section IV-A, Tables I-III] All latency, startup, jitter, and loss measurements appear to be single-run values reported without error bars, standard deviations, or repeat counts. For example, Table I reports values such as 948.4 ms and 215.00 ms with no indication of run-to-run variability. Before making percentage-improvement claims, the authors should repeat each experiment multiple times and report dispersion metrics; ideally they should also test whether observed differences are statistically significant given the variability of wireless channels.
  4. [Section V] The conclusion sentence 'with RoQ achieving the fastest connection startup but suffering from higher overall latency due to its communication mechanism' is internally inconsistent with Table I, which shows RoQ having lower latency than WebRTC in all rows (e.g., 125.67 ms vs 269.92 ms on 5G at 1080p). The 'higher overall latency' description appears to apply to MoQ, not RoQ. The conclusion should be corrected so that it matches the reported data.
minor comments (5)
  1. [Section IV-A] The phrase 'Gruops of Picture' should be corrected to 'Group of Pictures'.
  2. [Section III-C] The sentence beginning 'he tests were conducted' should begin with 'The tests were conducted'.
  3. [Section IV-A] The explanation that MoQ's relay increases latency is plausible but is not isolated by any measurement; the authors could strengthen it by measuring MoQ in a direct (non-relay) mode or citing a controlled comparison.
  4. [Table III] The column header 'Bytes Loss (%)' should be 'Byte Loss (%)' for consistency with the text and standard terminology.
  5. [Section II-C] The phrase 'In this research, we propose the development of a solution' describes the implemented system rather than a proposal; rephrasing would align with the experimental nature of the work.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper is an independent empirical benchmark of external protocol implementations, and its admitted implementation-maturity caveats are confounds, not circular reasoning.

full rationale

The paper's derivation chain is empirical: it builds a remote-rendering pipeline and measures startup time, end-to-end latency, CPU/GPU usage, throughput, jitter, and byte loss for WebRTC, RoQ, and MoQ over Wi-Fi and 5G. No quantity used in the analysis is defined in terms of the claimed result, and no fitted parameter is renamed as a prediction. The abstract's 'expected' improvements are stated as the paper's takeaway from the measurements, not as a result derived from internally assumed inputs. The paper explicitly identifies implementation maturity as a limitation: Section III-B states that RoQ support is 'still in an early stage and lacks full stability' and that the MoQ elements are 'not included in the stable, officially maintained versions of GStreamer', and Section IV-A notes that RoQ 'lacks mechanisms for handling transmission errors'. These are external implementation confounds that could bias the comparison, but they are not circularity: the measurements are made against independent protocol stacks, not against quantities constructed by the paper. The only self-citation, reference [10], is a prior edge-rendering architecture cited in the related-work discussion and is not load-bearing for the protocol comparison. Therefore the central empirical claim is self-contained relative to the paper's inputs, and the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no free parameters or invented entities. Its conclusions rest on domain assumptions about measurement accuracy and the representativeness of the experimental implementations and network conditions.

assumptions (3)
  • domain assumption NTP synchronization via a public server provides timestamps accurate enough for the reported latency measurements.
    Section III-C states both sides synchronize with a public NTP server, but no precision or verification is reported; if clock skew is on the order of the measured differences (tens of ms), the rankings could change.
  • domain assumption The unofficial GStreamer MoQ and RoQ elements are faithful implementations of the IETF drafts and their performance is representative of the protocols.
    Section III-B says MoQ elements are unofficial and do not support audio, and RoQ support is early-stage and 'lacks full stability'; performance gaps versus WebRTC may stem from implementation maturity, not protocol design.
  • domain assumption The testbed network conditions (single Wi-Fi AP, private 5G with no competing traffic) are representative enough for the protocol ranking to generalize.
    The paper notes 'both networks exhibit good performance due to the absence of competing traffic', so results may not hold in congested or mobile conditions.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Streaming Remote rendering services: Comparison of QUIC-based and WebRTC Protocols." pith.science (2026). https://pith.science/paper/2YE4N7FO

@misc{pith2026250522132,
  author       = {Pith},
  title        = {Pith review of: Streaming Remote rendering services: Comparison of QUIC-based and WebRTC Protocols},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2YE4N7FO}},
  note         = {Machine review of arXiv:2505.22132}
}
read the original abstract

The proliferation of Extended Reality (XR) applications, requiring high-quality, low-latency media streaming, has driven the demand for efficient remote rendering solutions. This paper focuses on holographic conferencing in virtual environments and their required uplink and downlink media transmission capabilities. By examining Media over QUIC (MoQ), Real-time Transport Protocol (RTP) over QUIC (RoQ), and Web Real-Time Communication (WebRTC), we assess their latency performance over Wi-Fi and 5G networks. Improvements of approximately 30% in latency and 60% in connection startup are expected in QUIC-based protocols compared to WebRTC. The experimental setup transmits a remote-rendered virtual experience using real-time video streaming protocols to provide the content to the participant. Our findings contribute to understanding the maturity of streaming protocols, particularly within open-source frameworks, and evaluate their suitability in supporting latency-sensitive XR applications. The study highlights specific protocol advantages across varied remote rendering scenarios, informing the design of future XR communication solutions.

Figures

Figures reproduced from arXiv: 2505.22132 by the authors.

Figure 1
Figure 1. Architecture for implementing communication between the remote renderer and the player [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Testbed for Wi-Fi and 5G latency measurement. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

24 extracted references · 19 canonical work pages

  1. [1]

    Remote line rendering for mobile devices,

    J. Diepstraten, M. Gorke, and T. Ertl, “Remote line rendering for mobile devices,” inProceedings Computer Graphics International, 2004. IEEE, 2004, pp. 454–461

    work page 2004

  2. [2]

    Augmented reality for remote education,

    Y . Li, “Augmented reality for remote education,” in2010 3rd International Conference on Advanced Computer Theory and Engineering (ICACTE), vol. 3. IEEE, 2010, pp. V3–187

    work page 2010

  3. [3]

    Overview: Real-Time Protocols for Browser- Based Applications,

    H. T. Alvestrand, “Overview: Real-Time Protocols for Browser- Based Applications,” RFC 8825, Jan. 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc8825

    work page 2021

  4. [4]

    Bishop, “HTTP/3,” RFC 9114, Jun

    M. Bishop, “HTTP/3,” RFC 9114, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9114

    work page 2022

  5. [5]

    QUIC Version 2,

    M. Duke, “QUIC Version 2,” RFC 9369, May 2023. [Online]. Available: https://www.rfc-editor.org/info/rfc9369

    work page 2023

  6. [6]

    Quic: Better for what and for whom?

    S. Cook, B. Mathieu, P. Truong, and I. Hamchaoui, “Quic: Better for what and for whom?” in2017 IEEE International Conference on Communications (ICC). IEEE, 2017, pp. 1–6

    work page 2017

  7. [7]

    Metaverse remote rendering testbed,

    L. Bassbouss, A. Neparidze, K. Kieslich, S. Steglich, S. Arbanowski, and P. Pogrzeba, “Metaverse remote rendering testbed,” in2023 IEEE International Conference on Metaverse Computing, Networking and Applications (MetaCom). IEEE, 2023, pp. 578–584

    work page 2023

  8. [8]

    Evaluating performance of 5g remote rendering connections for virtual reality application deployment,

    M. Corry, J. Hatfield, B. Fulda, and E. Mandel, “Evaluating performance of 5g remote rendering connections for virtual reality application deployment,” in2023 IEEE Future Networks World F orum (FNWF). IEEE, 2023, pp. 1–6

    work page 2023

Show all 24 references
  1. [9]

    Renderlink remote rendering platform for computer games: A webrtc solution for streaming computer games,

    B.-I. Oros and V . I. B ˆacu, “Renderlink remote rendering platform for computer games: A webrtc solution for streaming computer games,” in2020 IEEE 16th International Conference on Intelligent Computer Communication and Processing (ICCP). IEEE, 2020, pp. 555–561

    2020

  2. [10]

    Edge rendering architecture for multiuser xr experiences and e2e performance assessment,

    I. Yeregui, D. Mej ´ıas, G. Pacho, R. Viola, J. Astorga, and M. Montagud, “Edge rendering architecture for multiuser xr experiences and e2e performance assessment,”arXiv preprint arXiv:2406.07087, 2024

    2024 arXiv

  3. [11]

    Towards cloud-native virtual reality applications: State-of- the-art and open challenges,

    J. Santos, “Towards cloud-native virtual reality applications: State-of- the-art and open challenges,” in2024 IEEE Symposium on Computers and Communications (ISCC), 2024, pp. 1–6

    2024

  4. [12]

    QUIC: A UDP-Based Multiplexed and Secure Transport,

    J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000

    2021

  5. [13]

    An Unreliable Datagram Extension to QUIC,

    T. Pauly, E. Kinnear, and D. Schinazi, “An Unreliable Datagram Extension to QUIC,” RFC 9221, Mar. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9221

    2022

  6. [14]

    RTP over QUIC (RoQ),

    M. Engelbart, J. Ott, and S. Dawkins, “RTP over QUIC (RoQ),” Internet Engineering Task Force, Internet-Draft draft-ietf-avtcore-rtp- over-quic-12, Oct. 2024, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic/12/

    2024

  7. [15]

    Media over QUIC Transport,

    L. Curley, K. Pugin, S. Nandakumar, V . Vasiliev, and I. Swett, “Media over QUIC Transport,” Internet Engineering Task Force, Internet-Draft draft-ietf-moq-transport-07, Oct. 2024, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-moq-transport/07/

    2024

  8. [16]

    Standardization of extended reality (xr) over 5g and 5g-advanced 3gpp new radio,

    M. Gapeyenko, V . Petrov, S. Paris, A. Marcano, and K. I. Pedersen, “Standardization of extended reality (xr) over 5g and 5g-advanced 3gpp new radio,”IEEE Network, vol. 37, no. 4, pp. 22–28, 2023

    2023

  9. [17]

    5g networks evolution for extended reality,

    A. Cedergren, F. de Laval, S. Falahati, L. Falk, D. H. Kang, R. S. Karlsson, Y . Lyazidi, A. Mirzaei, J. Olsson, J. L. Pradas, P. Schliwa-Bertling, N. Shi, B. Singh, R. Tano, and A. M. V oicu, “5g networks evolution for extended reality,”IEEE Communications Standards Magazine,...

    2024

  10. [18]

    Is wi-fi 6 ready for virtual reality mayhem? a case study using one ap and three hmds,

    C. Michaelides, M. Casasnovas, D. Marchitelli, and B. Bellalta, “Is wi-fi 6 ready for virtual reality mayhem? a case study using one ap and three hmds,” in2023 IEEE Future Networks World F orum (FNWF), 2023, pp. 1–6

    2023

  11. [19]

    Wifi tsn: Enabling deterministic wireless connectivity over 802.11,

    D. Cavalcanti, C. Cordeiro, M. Smith, and A. Regev, “Wifi tsn: Enabling deterministic wireless connectivity over 802.11,”IEEE Communications Standards Magazine, vol. 6, no. 4, pp. 22–29, 2022

    2022

  12. [20]

    Multipath quic: Design and evaluation,

    Q. De Coninck and O. Bonaventure, “Multipath quic: Design and evaluation,” inProceedings of the 13th international conference on emerging networking experiments and technologies, 2017, pp. 160–166

    2017

  13. [21]

    GStreamer: appsrc,

    “GStreamer: appsrc,” [Online] Available: https://gstreamer.freedesktop. org/documentation/app/appsrc.html?gi-language=c, Accessed: 2024-10- 10

    2024

  14. [22]

    Media over QUIC,

    L. Curley, “Media over QUIC,” [Online] Available: https://quic.video, Accessed: 2024-10-10

    2024

  15. [23]

    AMARI Callbox Mini,

    “AMARI Callbox Mini,” [Online] Available: https://www. amarisoft.com/test-and-measurement/device-testing/device-products/ amari-callbox-mini, Accessed: 2024-10-10

    2024

  16. [24]

    3GPP Release 15,

    “3GPP Release 15,” [Online] Available: https://www.3gpp.org/ specifications-technologies/releases/release-15, Accessed: 2024-10-10

    2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.