Pith. sign in

REVIEW 4 major objections 6 minor 60 references

Automated, Cross-Layer Root Cause Analysis of 5G Video-Conferencing Quality Degradation

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

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

Pith's one-line read Domino claims that 5G video-call quality drops are the end points of 24 specific radio-to-application causal chains, and that it can detect which chain fired from cross-layer network traces.

desk verdict New and useful measurement contribution, but Domino's quantitative root-cause attribution is not supported; the qualitative trace analyses are the credible core. read the letter →

arxiv 2505.14540 v1 pith:YPOXJYOM submitted 2025-05-20 cs.NI

Fan Yi , Haoran Wan , Kyle Jamieson , Oliver Michel This is my paper · ORCID
classification cs.NI
keywords 5GWebRTCvideoconferencingrootcauseanalysiscross-layermeasurementcausalchainscongestioncontrolQoE
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

5G video calls degrade for identifiable reasons, not random noise. The paper argues that a small set of radio-layer events—poor channel conditions, cross-traffic, uplink scheduling gaps, HARQ and RLC retransmissions, and RRC state transitions—inflate one-way delay, and that this delay then triggers one of three specific reactions inside WebRTC: jitter-buffer drains, target-bitrate cuts, or pushback-rate cuts. From synchronized traces of real calls on commercial and private 5G networks, the authors say they can name 24 such causal chains and that a typical commercial session suffers about five degradation events per minute, mostly from retransmissions and cross-traffic. On this basis they build Domino, a tool that scans sliding windows of cross-layer traces, detects which chain fired, and reports the root cause. If right, it turns a hard-to-debug experiential problem into a checkable list of measurable network conditions.

What carries the argument

The load-bearing object is the causal chain: a directed path through a six-cause radio-layer graph into a delay-increase node and out to one of three application-layer consequences, with all 24 paths defined explicitly. Domino turns a text description of these chains into executable Python detection code, then feeds a 36-dimensional feature vector computed in a sliding window of $W = 5\,\text{s}$ that advances in $\Delta t = 0.5\,\text{s}$ steps. Within each window, it tests event conditions such as: jitter-buffer drain is declared when the buffer length hits 0 ms, and cross-traffic is declared when other users' allocated physical resource blocks exceed 20% of the target client's. The window scans the synchronized traces and reports which chains fired, which is what produces the cause attribution percentages.

What would settle it

Run controlled WebRTC calls on a private 5G cell where exactly one cause is forced at a time—for example, a scheduled burst of HARQ failures, a fixed level of cross-traffic, or a deliberate RRC release—and compare Domino's attributed chains with the forced schedule over many trials. If an unforced cause is attributed almost as often as the forced one, or if a forced cause does not raise its predicted consequence's conditional probability above baseline, the co-occurrence rule is doing the work rather than causality.

Watch

Extended reading notes

Core claim

The central claim is that every significant WebRTC quality loss the authors observed in 5G can be traced to one of six 5G-side causes—poor channel conditions, cross-traffic, uplink scheduling delay, HARQ retransmission, RLC retransmission, or RRC state transition—acting through a delay-increase step to produce one of three consequences: jitter-buffer drain, GCC target-bitrate reduction, or GCC pushback-rate reduction. The paper instantiates this graph as 24 causal chains and reports concrete trace evidence for the linkage, such as an RRC transition that stopped physical-layer transmissions for roughly 300 ms and drove one-way delay toward 400 ms, and an RLC retransmission that added about 105 ms to a packet's delay. In commercial 5G, Domino detects about five degradation events per video session per minute and attributes them mainly to retransmissions (42%), cross-traffic (28%), and poor-quality channels (12%); in private cells, uplink scheduling delay (36%) and poor channels (37%) dominate. The paper's claim is that these are root causes recoverable automatically from correlated physical-layer, link-layer, transport, and application telemetry, not mere correlations.

Load-bearing premise

A cause and consequence are counted as causally linked when both appear anywhere in a five-second sliding window, without checking which came first or whether an unrelated network event could explain both.

Editorial extensions

If this is right

  • If the attribution percentages hold, retransmission- and cross-traffic-related causes together account for about 70% of detected degradation events on commercial 5G, so operators attacking those two mechanisms would address most of the QoE loss.
  • Because GCC's delay-based estimator treats any delay increase as congestion, short radio-layer spikes can trigger bitrate cuts that recover slowly; the paper finds slow additive-increase recovery in roughly 99% of detected anomalies.
  • Because the pushback controller keys on outstanding bytes, reverse-path RTCP delay alone can lower the send rate and frame rate even when the forward media path is healthy.
  • Domino's text-configurable chain definitions mean the same detector can be pointed at new radio metrics or new application metrics without rewriting the analysis core.

Reading between the lines

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

  • One direct test of transferability: point Domino's catalog at a different WebRTC-based conferencing app using the same radio conditions; if the six causes and three consequences reproduce, the causal graph is general, and if not, some chains are specific to this setup.
  • An operator-side variant that watches only the radio-layer causes and uses Domino's conditional probabilities as a lookup table could predict likely app-level degradation without instrumenting the app; the paper does not build this, but its causal graph is the missing mapping.
  • Tightening the sliding-window rule to require cause before consequence and an observed delay increase between them would produce a stricter re-ranked version of the 24-chain catalogue; the attribution percentages in the paper's table would likely shift as a result.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper presents a cross-layer measurement study of 5G networks and WebRTC video conferencing, combining PHY/MAC/RLC-layer telemetry (NR-Scope, gNB logs) with transport- and application-layer instrumentation of a custom WebRTC client. From these traces the authors identify six 5G-side causes and three WebRTC-side consequences, organize them into a causality graph, and build Domino, an extensible tool that detects these causal chains in a sliding-window fashion. The paper reports 24 causal event chains, an average of about five degradation events per session per minute, and attribution percentages (cross-traffic 28%, retransmissions 42%, poor channel 12%) for commercial 5G. The paper also presents detailed qualitative trace analyses of channel degradation, cross-traffic, HARQ/RLC retransmissions, RRC transitions, jitter-buffer drains, GCC target-rate drops, and pushback-rate drops.

Significance. If the causal-chain identifications and the attribution statistics are valid, this would be a substantial contribution: it is the first study to correlate 5G PHY/MAC/RLC events with internally instrumented WebRTC state at high temporal resolution, and Domino would be a useful, extensible diagnostic tool for operators and application developers. The qualitative mechanisms in Sections 5 and 6—for example, the RLC head-of-line blocking trace in Fig. 18 and the RTCP-delay-induced pushback reduction in Fig. 22—are individually coherent and supported by detailed time-series evidence. The paper also promises to release Domino and the high-rate datasets, which would benefit the community. However, the central quantitative claims about the prevalence and attribution of degradation events rest on event-detection definitions that currently do not separate causation from co-occurrence or from base rates, so the significance of those specific numbers is not yet established.

major comments (4)
  1. [§4.2, Table 5, condition 19] Condition 19 defines 'Uplink scheduling delay' as 'As long as the transmission uses the 5G uplink channel.' Because the WebRTC session continuously sends uplink media and RTCP packets, this condition is true in virtually every 5 s window, making the feature's unconditional base rate close to 1. The conditional probabilities in Table 2 (e.g., 42–43% for Target Bitrate↓ in both commercial and private cells) are therefore indistinguishable from the base rate and cannot support the abstract's attribution 'uplink scheduling delays (36%)' for private 5G. The paper should report the unconditional occurrence rate of each cause and test whether the conditional probability given each consequence is significantly higher than that base rate, or redefine the event to reflect an actual scheduling-delay anomaly.
  2. [§4.2] The sliding-window detector (W = 5 s, step 0.5 s) marks a cause and a consequence as linked when both appear anywhere within the same window; it does not require the cause to precede the consequence and does not control for confounders. As a result, the conditional probabilities in Table 2, the chain ratios in Table 4, and the causal-chain count in the abstract are co-occurrence statistics rather than evidence of causation. The authors should require temporal precedence (e.g., the cause must be detected before the consequence within the window), and should add negative-control analyses such as time-shuffled traces, windows in which only the consequence occurs with no candidate cause, and comparisons against the wired-network sessions to show that the detected associations are not an artifact of window co-occurrence.
  3. [Table 5 and Appendix D] The quantitative results are determined by a set of hand-chosen thresholds—cross-traffic PRB ratio >20%, MCS 90th percentile <20, HARQ retransmission threshold (10 in Appendix D vs. 20 in Table 5), frame-rate thresholds 27/25, TBS drop 80%, and the window length W = 5 s—but no sensitivity analysis is provided. The headline numbers (e.g., 'approximately five video quality degradation events per video session per minute') would change materially with these thresholds. The paper should vary each threshold over a reasonable range and show that the reported frequencies and conditional probabilities are stable, or report the results as ranges and discuss the sensitivity.
  4. [§4.2 and Table 2] There is no ground-truth validation of the event detector or the causal chains. The qualitative trace examples in Section 5 and Section 6 are persuasive, but the automated detector's precision and recall are never evaluated: there is no comparison against injected faults, controlled cross-traffic experiments, independent expert annotation, or a known ground-truth dataset. Until the detector is validated, the claim of 'identifying 24 previously unknown causal event chains' should be softened to 'defining 24 hypothesized chains,' and Table 2 should be described as association statistics rather than validated causal attributions.
minor comments (6)
  1. [Abstract and §4.2] The abstract says 'identifying 24 previously unknown causal event chains,' but §4.2 states that Domino 'defines 24 potential causal chains by analyzing all combinations' of causes and consequences. 'Previously unknown' is not established, and 'identifying' should be 'defining' or 'enumerating' given that the chains are constructed from the authors' graph rather than discovered.
  2. [Table 5 and Appendix D, condition 17] The HARQ retransmission threshold is inconsistent: Table 5 says 'more than 20 instances,' while Appendix D says 'more than 10 HARQ retransmissions.' The authors should correct this discrepancy and state the exact threshold used in the analysis.
  3. [References] References [30] and [31] are duplicates (the same paper, 'Device-Based LTE Latency Reduction at the Application Layer' by Tan et al.); the duplicate should be removed and the citation in the text redirected.
  4. [§2.2] The text says the Zoom analysis covers 'a time period of one week in February 2023,' but the dataset description in the same paragraph and Table 1 report 409 days of Wi-Fi, 86 days of wired, and 165 hours of cellular data. This inconsistency should be clarified.
  5. [Table 4] Table 4's header contains two columns labeled 'RLC ReTX' and the column order differs from Table 2; renaming the columns (e.g., 'RLC ReTX (commercial)' and 'RLC ReTX (private)') and aligning the order would avoid confusion.
  6. [Appendix D, condition 3] Condition 3 flags a resolution drop on the basis of any single decrease in resolution (∃i, resolution[i+1] < resolution[i]). This could be triggered by normal encoder adaptation to scene complexity or by momentary GC pressure; the condition should require the drop to persist or to coincide with a network-side cause.

Circularity Check

1 steps flagged · score 5.0 of 10

UL-scheduling 'cause' is defined as any uplink transmission, so Table 2's UL-scheduling attribution is a base-rate co-occurrence by construction.

  1. self definitional [Appendix D, Table 5, event 19; used in §4.2 detection and Table 2; cited in §1 attribution]
    ""Uplink Scheduling (19): Whenever there is an uplink channel transmission, we set this feature to be true." and "In our private 5G dataset, uplink scheduling delays (36%) and poor quality channels (37%) dominate the causes.""

    The detector defines the cause 'UL scheduling delay' as the mere presence of an uplink transmission. Because the WebRTC session continuously sends uplink media and RTCP packets, this feature is present in essentially every 5-second window, so the detected cause is simply 'the call is using the uplink.' Any consequence occurring in such a window (jitter-buffer drain, target-bitrate drop, pushback-rate drop) is therefore recorded as having UL scheduling as an associated cause. The Table 2 UL Scheduling column (e.g., 42% for Target Bitrate under commercial cells) is a base-rate co-occurrence with the always-on uplink flag, not a measurement of the 5-25 ms BSR-to-grant scheduling delay quantified in §5.2.1, which the detector never tests.

full rationale

Domino's trace-level mechanism analyses in §5 and §6 (e.g., Figs. 12, 13, 17-22) provide independent, manually inspected evidence for poor-channel, cross-traffic, HARQ/RLC retransmission, and RRC-transition chains. The 24-chain catalogue and the conditional probabilities in Tables 2 and 4 are produced by the authors' own DAG and event definitions, so any over-broad condition directly inflates the corresponding attribution. Aside from the UL-scheduling flag, the other event conditions test measurable quantities (MCS drop, PRB ratio, HARQ count, RNTI change, jitter-buffer length), and those chains are not circular in the formal sense. The cited NR-Scope [33] and Athena [35] are used as measurement tool and related work, respectively, and are not load-bearing self-citations. Overall, one definitional step makes a substantial subset of the quantitative attribution circular, but the central qualitative mechanisms retain independent content; hence a moderate score rather than a higher one.

Assumptions & free parameters 8 free parameters · 4 assumptions · 0 invented entities

The central quantitative claims (cause frequencies, conditional probabilities) depend entirely on hand-defined event thresholds in Table 5 and Appendix D, which act as free parameters. The causal interpretation additionally relies on several domain assumptions about measurement fidelity and temporal co-occurrence. No new physical or conceptual entities are postulated.

free parameters (8)
  • sliding window length W and step Δt = W=5 s, Δt=0.5 s
    Defined in Section 4.2; all event detections and chain counts depend on this window.
  • frame-rate drop thresholds = max > 27 fps; min < 25 fps
    Table 5 conditions 1 and 2 define the frame-rate-drop consequence.
  • TBS drop threshold = min TBS < 0.8 × max TBS
    Table 5 condition 13 defines the allocated-TBS-drop cause.
  • cross traffic PRB ratio threshold = other-UE PRBs > 0.2 × target-UE PRBs
    Table 5 condition 15 defines the cross-traffic cause.
  • channel degradation MCS thresholds = MCS 90th percentile < 20; MCS 50th percentile < 10 for more than 10 of the 50 ms windows
    Table 5 condition 16 defines the poor-channel cause.
  • HARQ retransmission count threshold = more than 10 per window (Appendix D) or more than 20 (Table 5)
    Inconsistent definition of the HARQ retransmission cause.
  • delay anomaly threshold = max packet delay > 80 ms
    Appendix D conditions 11 and 12 define forward and reverse delay increase.
  • app-bitrate-exceeds-TBS threshold = rate_diff > 0 for more than 10% of samples
    Table 5 condition 14 defines rate overshoot.
assumptions (4)
  • domain assumption Events co-occurring within a 5 s sliding window are treated as causally connected.
    Section 4.2 defines the detection procedure; no temporal precedence test or confounder control is applied.
  • domain assumption NR-Scope and gNB logs accurately capture the relevant PHY/MAC/RLC events.
    Section 3 relies on NR-Scope, which is developed by the authors, and on gNB logs for radio-layer ground truth; accuracy is not independently validated here.
  • domain assumption The instrumented libwebrtc client faithfully exposes GCC's internal state (delay slope, network state, target bitrate, pushback rate).
    Section 3 states the custom client collects these every 50 ms; correctness against the real GCC implementation is assumed.
  • domain assumption Zoom QSS API access-network classification (wired, Wi-Fi, or cellular) is correct.
    Section 2.2 uses this classification to attribute jitter and loss differences; no validation of the classification is reported.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automated, Cross-Layer Root Cause Analysis of 5G Video-Conferencing Quality Degradation." pith.science (2026). https://pith.science/paper/YPOXJYOM

@misc{pith2026250514540,
  author       = {Pith},
  title        = {Pith review of: Automated, Cross-Layer Root Cause Analysis of 5G Video-Conferencing Quality Degradation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YPOXJYOM}},
  note         = {Machine review of arXiv:2505.14540}
}
read the original abstract

5G wireless networks are complex, leveraging layers of scheduling, retransmission, and adaptation mechanisms to maximize their efficiency. But these mechanisms interact to produce significant fluctuations in uplink and downlink capacity and latency. This markedly impacts the performance of real-time applications, such as video-conferencing, which are particularly sensitive to such fluctuations, resulting in lag, stuttering, distorted audio, and low video quality. This paper presents a cross-layer view of 5G networks and their impact on and interaction with video-conferencing applications. We conduct novel, detailed measurements of both Private CBRS and commercial carrier cellular network dynamics, capturing physical- and link-layer events and correlating them with their effects at the network and transport layers, and the video-conferencing application itself. Our two datasets comprise days of low-rate campus-wide Zoom telemetry data, and hours of high-rate, correlated WebRTC-network-5G telemetry data. Based on these data, we trace performance anomalies back to root causes, identifying 24 previously unknown causal event chains that degrade 5G video conferencing. Armed with this knowledge, we build Domino, a tool that automates this process and is user-extensible to future wireless networks and interactive applications.

Figures

Figures reproduced from arXiv: 2505.14540 by the authors.

Figure 7
Figure 7. Each experiment consists of a 30-minute WebRTC call [PITH_FULL_IMAGE:figures/full_fig_p004_7.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

60 extracted references · 48 canonical work pages

  1. [1]

    3GPP. [n. d.]. TS138.321: 5G NR Medium Access Control (MAC) pro- tocol specification

    work page

  2. [2]

    Harald Alvestrand, Varun Singh, and Henrik Boström. 2025. Identifiers for WebRTC’s Statistics API. Retrieved May 12, 2025 from https: //www.w3.org/TR/webrtc-stats

    work page 2025

  3. [3]

    Amarisoft. 2025. Amari Callbox Mini. https://www.amarisoft. com/test-and-measurement/device-testing/device-products/amari- callbox-mini Accessed: 2025-05-11

    work page 2025

  4. [4]

    Baset and Henning G

    Salman A. Baset and Henning G. Schulzrinne. 2006. An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol. In IEEE INFOCOM

    work page 2006

  5. [5]

    Niklas Blum, Serge Lachapelle, and Harald Alvestrand. 2021. WebRTC: Real-Time Communication for the Open Web Platform. Commun. ACM 64, 8 (2021), 50–54. doi:10.1145/3453182

    doi:10.1145/3453182 2021

  6. [6]

    Francesco Bronzino, Paul Schmitt, Sara Ayoubi, Guilherme Martins, Renata Teixeira, and Nick Feamster. 2020. Inferring Streaming Video Quality from Encrypted Traffic: Practical Models and Deployment Experience. SIGMETRICS Perform. Eval. Rev. 48, 1 (2020), 27–28. doi:10. 1145/3410048.3410064

    work page arXiv 2020

  7. [7]

    Gaetano Carlucci, Luca De Cicco, Stefan Holmer, and Saverio Mas- colo. 2016. Analysis and design of the google congestion control for web real-time communication (WebRTC). In Proceedings of the 7th International Conference on Multimedia Systems . 1–12

    work page 2016

  8. [8]

    Gaetano Carlucci, Luca De Cicco, Stefan Holmer, and Saverio Mas- colo. 2017. Congestion Control for Web Real-Time Communica- tion. IEEE/ACM Transactions on Networking 25, 5 (2017), 2629–2642. doi:10.1109/TNET.2017.2703615

    work page arXiv 2017

Show all 60 references
  1. [9]

    Hyunseok Chang, Matteo Varvello, Fang Hao, and Sarit Mukherjee

  2. [10]

    Albert Choi, Mehdi Karamollahi, Carey Williamson, and Martin Arlitt

  3. [11]

    Yusuf Cinar, Peter Pocta, Desmond Chambers, and Hugh Melvin. 2021. Improved Jitter Buffer Management for WebRTC. ACM Trans. Multi- media Comput. Commun. Appl. 17, 1, Article 30 (April 2021), 20 pages. doi:10.1145/3410449

    2021 doi

  4. [12]

    János Dóka, Bálint György Nagy, Dávid Jocha, Bence Formanek, Iván Viciedo, Adrian Rodrigo, David Gomez-Barquero, and Balázs Sonkoly

  5. [13]

    Rostand A. K. Fezeu, Eman Ramadan, Wei Ye, Benjamin Minneci, Jack Xie, Arvind Narayanan, Ahmad Hassan, Feng Qian, Zhi-Li Zhang, Jaideep Chandrashekar, and Myungjin Lee. 2023. An In-Depth Mea- surement Analysis of 5G mmWave PHY Latency and its Impact on End-to-End Delay. In Pas...

    2023 doi

  6. [15]

    Google. 2025. Google Cloud Platform. https://cloud.google.com. Ac- cessed: 2025-05-11

    2025

  7. [16]

    Google Inc. 2025. libwebrtc. https://webrtc.googlesource.com/src/ Accessed: 2025-05

    2025

  8. [17]

    Prateesh Goyal, Mohammad Alizadeh, and Hari Balakrishnan. 2020. ABC: A Simple Explicit Congestion Controller for Wireless Networks. In Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20)

    2020

  9. [18]

    ITU-T. 2003. One-way transmission time . Recommendation G.114. International Telecommunication Union, Geneva, Switzerland

    2003

  10. [19]

    Rostand A. K. Fezeu, Claudio Fiandrino, Eman Ramadan, Jason Carpen- ter, Lilian Coelho de Freitas, Faaiq Bilal, Wei Ye, Joerg Widmer, Feng Qian, and Zhi-Li Zhang. 2024. Unveiling the 5G Mid-Band Landscape: From Network Deployment to Performance and Application QoE. In Proceedi...

    2024

  11. [20]

    Swarun Kumar, Ezzeldin Hamed, Dina Katabi, and Li Erran Li. 2014. LTE Radio Analytics Made Easy and Accessible. SIGCOMM Comput. Commun. Rev. 44, 4 (Aug. 2014), 211–222. doi:10.1145/2740070.2626320

    2014

  12. [21]

    Insoo Lee, Jinsung Lee, Kyunghan Lee, Dirk Grunwald, and Sangtae Ha. 2021. Demystifying Commercial Video Conferencing Applications. In ACM International Conference on Multimedia . ACM, New York, NY, USA, 3583–3591. https://doi.org/10.1145/3474085.3475523

    2021

  13. [22]

    Yuanjie Li, Chunyi Peng, Zengwen Yuan, Jiayao Li, Haotian Deng, and Tao Wang. 2016. Mobileinsight: Extracting and analyzing cellular network information on smartphones. In Proceedings of the 22nd An- nual International Conference on Mobile Computing and Networking . 202–215

    2016

  14. [23]

    Kyle MacMillan, Tarun Mangla, James Saxon, and Nick Feamster. 2021. Measuring the Performance and Network Utilization of Popular Video Conferencing Applications. In ACM Internet Measurement Conference. ACM, New York, NY, USA, 229–244. https://doi.org/10.1145/3487552. 3487842

    2021 doi

  15. [25]

    Mosolab. 2025. Mosolab Canopy Small Cell. https://opennetworking. org/products/moso-canopy-5g-indoor-small-cell/ Accessed: 2025-05- 11

    2025

  16. [26]

    2023.{POLYCORN}: Data-driven Cross-layer Multipath Networking for High-speed Railway through Composable Schedulerlets

    Yunzhe Ni, Feng Qian, Taide Liu, Yihua Cheng, Zhiyao Ma, Jing Wang, Zhongfeng Wang, Gang Huang, Xuanzhe Liu, and Chenren Xu. 2023.{POLYCORN}: Data-driven Cross-layer Multipath Networking for High-speed Railway through Composable Schedulerlets. In 20th USENIX Symposium on Netwo...

    2023

  17. [27]

    Antonio Nistico, Dena Markudova, Martino Trevisan, Michela Meo, and Giovanna Carofiglio. 2020. A comparative study of RTC appli- cations. In IEEE International Symposium on Multimedia . IEEE, New York, NY, USA, 1–8

    2020

  18. [28]

    Ranya Sharma, Nick Feamster, and Marc Richardson. 2024. A Longi- tudinal Study of the Prevalence of WiFi Bottlenecks in Home Access Networks. In Proceedings of the 2024 ACM on Internet Measurement Conference (Madrid, Spain) (IMC ’24). Association for Computing Ma- chinery, New...

    2024

  19. [29]

    Taveesh Sharma, Tarun Mangla, Arpit Gupta, Junchen Jiang, and Nick Feamster. 2023. Estimating WebRTC Video QoE Metrics Without Using Application Headers. In Proceedings of the 2023 ACM on Internet Measurement Conference (Montreal QC, Canada)(IMC ’23). Association 15 Fan Yi, Ha...

    2023

  20. [31]

    Zhaowei Tan, Jinghao Zhao, Yuanjie Li, Yifei Xu, and Songwu Lu

  21. [32]

    Matteo Varvello, Hyunseok Chang, and Yasir Zaki. 2022. Performance characterization of videoconferencing in the wild. InProceedings of the 22nd ACM Internet Measurement Conference (Nice, France) (IMC ’22). Association for Computing Machinery, New York, NY, USA, 261–273. doi:10...

    2022

  22. [33]

    Haoran Wan, Xuyang Cao, Alexander Marder, and Kyle Jamieson. 2024. NR-Scope: A Practical 5G Standalone Telemetry Tool. InProceedings of the 20th International Conference on emerging Networking EXperiments and Technologies. 73–80

    2024

  23. [34]

    Yaxiong Xie, Fan Yi, and Kyle Jamieson. 2020. PBE-CC: Congestion control via endpoint-centric, physical-layer bandwidth measurements. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, archi- tectu...

    2020

  24. [35]

    Fan Yi, Haoran Wan, Kyle Jamieson, Jennifer Rexford, Yaxiong Xie, and Oliver Michel. 2024. Athena: Seeing and Mitigating Wireless Impact on Video Conferencing and Beyond. In Proceedings of the 23rd ACM Workshop on Hot Topics in Networks (Irvine, CA, USA) (HotNets ’24). Associa...

    2024

  25. [37]

    Zoom Video Communications, Inc. 2025. Zoom QSS API. Re- trieved May 12, 2025 from https://developers.zoom.us/docs/api/qss/ #tag/dashboards 16 Automated, Cross-Layer Root Cause Analysis of 5G Video-Conferencing Quality Degradation A Ethics The Zoom API data used in this study w...

    2025

  26. [38]

    In 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21)

    {Device-Based}{ LTE} latency reduction at the application layer. In 18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21). 471–486

  27. [43]

    Encheng Yu, Jianer Zhou, Zhenyu Li, Gareth Tyson, Weichao Li, Xinyi Zhang, Zhiwei Xu, and Gaogang Xie. 2024. Mustang: Improving QoE for Real-Time Video in Cellular Networks by Masking Jitter. ACM Trans. Multimedia Comput. Commun. Appl. 20, 9, Article 285 (Sept. 2024), 23 pages...

    2024 doi

  28. [45]

    Inbound frame rate↓ Maximum inbound frame rate is higher than 27, while the minimum inbound frame rate is smaller than 25

  29. [46]

    Outbound frame rate↓ Maximum outbound frame rate is higher than 27, while the minimum outbound frame rate is smaller than 25

  30. [47]

    Outbound resolution↓ There is a downtrend in outbound resolution

  31. [48]

    Jitter buffer drains The client’s jitter buffer drops to 0 milliseconds

  32. [49]

    Target bitrate↓ There is a downtrend in the client’s target bitrate

  33. [50]

    GCC overuse detected There is an overuse entry in the GCC log

  34. [51]

    Pushback rate↓ There is a downtrend in the client’s pushback rate

  35. [52]

    Congestion window full The client’s outstanding bytes are bigger than the client’s GCC congestion window bytes

  36. [53]

    Outstanding bytes↑ There is an uptrend in the client’s windowed outstanding bytes

  37. [54]

    Pushback rate unequal to target bitrate If these two values are not equal to each other at any point

  38. [55]

    Forward packet delay↑ There is an uptrend in the windowed forward packet delay

  39. [56]

    Reverse packet delay↑ There is an uptrend in the windowed reverse packet delay

  40. [57]

    Allocated TBS↓ Minimum TBS is smaller than 80 percent of the maximum TBS in the window

  41. [58]

    App bitrate exceeds the allocated TBS The percentage of time when App bitrate exceeds the allocated TBS is higher than 10 %

  42. [59]

    5G cross traffic Other UE’s allocated PRB summation is higher than 20 % of our UE’s allocated PRB summation

  43. [60]

    5G channel degrades Maximum 90-percentile of the grouped MCSs (with a window of 50 ms) is smaller than 20, and the less-than-10 medium value appears more than 10 times

  44. [61]

    HARQ retransmission There are more than 20 instances of HARQ retransmission detected

  45. [62]

    RLC retransmission The gNB’s log indicates RLC retransmission

  46. [63]

    Uplink scheduling delay As long as the transmission uses the 5G uplink channel

  47. [64]

    Table 5— Event detection conditions used by Domino for feature extraction in the sliding window

    RRC state change The UE’s RNTI changes during the window. Table 5— Event detection conditions used by Domino for feature extraction in the sliding window. there is an uptrend in the windowed packet delay and the maximum delay is higher than 80 ms. wind_delay[k] = 1 10 ∑︁10(𝑘+1...

  48. [180]

    doi:10.1145/3712676.3714448

  49. [2006]

    doi:10.1109/INFOCOM.2006.312

    IEEE, New York, NY, USA, 1–11. doi:10.1109/INFOCOM.2006.312

    2006 doi

  50. [2021]

    In ACM Internet Measurement Conference

    Can You See Me Now? A Measurement Study of Zoom, Webex, and Meet. In ACM Internet Measurement Conference. ACM, New York, NY, USA, 216–228. https://doi.org/10.1145/3487552.3487847

  51. [2022]

    In Passive and Active Network Measurement

    Zoom Session Quality: A Network-Level View. In Passive and Active Network Measurement. Springer, Berlin, Germany, 555–572

  52. [2025]

    In Proceedings of the 16th ACM Multimedia Systems Conference (Stellenbosch, South Africa) (MMSys ’25)

    Enablers of low-latency immersive interaction in future remote- rendered Mixed Reality applications. In Proceedings of the 16th ACM Multimedia Systems Conference (Stellenbosch, South Africa) (MMSys ’25). Association for Computing Machinery, New York, NY, USA, 170–

Pith tools

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