{"id":"a50eb619-8b0b-4a33-aeaf-ee12de101440","arxiv_id":"2608.06102","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"MultiMoQ redesigns MoQ-Lite group delivery with pending and active queues and adds client-driven multi-access switching, reducing stalls and improving goodput for 360-degree tile streaming.","lead":"MultiMoQ is a new streaming framework built on Media over QUIC that keeps tile-based 360-degree video playing smoothly by separating delivery queues and switching between two network paths when quality drops. In a 96-client emulated network, it delivered more video data with far fewer playback stalls than both DASH and standard MoQ.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Single-run emulation leaves headline goodput/latency gains unquantified; repeated trials with error bars are required.","rationale":"The reader's weakest assumption identifies exactly the same load-bearing concern: the absence of independent repetitions and error bars in a network-emulation study. I agree with that assessment. The paper is honest about this limitation—Fig. 13's caption and Section 4.4 disclose the single-run nature—but the disclosure does not make the quantitative claims rigorous; it makes them conditional. The design contributions (pending/active queue separation, per-track make-before-break switching) are plausible and are supported by an ablation that separates their effects, so a REJECT verdict would be too strong. The missing repeated trials are the single most direct threat to the Abstract's performance numbers and the Fig. 9/13 comparisons. If repeated runs show overlapping distributions, the headline advantage could disappear; if the advantage persists, the paper's central claims hold. Other potential issues, such as the apparent contrast between DASH's near-zero transport stall and its 51.5% viewport freeze ratio, are plausibly explained by DASH buffering and falling behind (Section 4.5) and are secondary to the statistical weakness. The verdict should remain CONDITIONAL, demanding repeated trials and sensitivity analysis as a condition for the quantitative claims to be trusted. Therefore, no change to the reader's verdict is needed.","tokens_in":11976,"tokens_out":6213,"duration_ms":50376,"concrete_test":"Re-run the bad-access (and ideally all three access conditions) experiment with at least 10 independent Mininet seeds, computing per-system mean and 95% confidence intervals for enhancement-tile goodput, p95 end-to-end delay, and stall time. The headline should be considered stable only if MultiMoQ's mean goodput exceeds DASH's and its p95 delay remains below DASH's with non-overlapping confidence intervals in the same direction in at least 9 of 10 runs; otherwise, report the run-to-run variance and qualify the quantitative claims accordingly.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's quantitative claims rest on a single emulation run per system. Section 4.4 explicitly states that Fig. 13 reports '96 client observations per system from one shared-topology run, not independent repetitions,' and no error bars or statistical tests appear anywhere else (Figs. 9, 10, 12, 14). Because Mininet link emulation, per-client scheduling, and topology instantiation are stochastic, point estimates such as the bad-access enhancement-tile goodput (1.20 vs 0.66 Mbps for DASH) and p95 delay (1130 vs 3930 ms) may shift substantially under another random seed. The 96 clients in one run are correlated observations sharing one topology, server state, and background load; they are not independent trials. Consequently, the central claim that MultiMoQ 'increases goodput for enhancement tiles and base video and reduces enhancement-tile tail end-to-end latency relative to DASH' is not yet quantitatively established. This is a correctable methodological gap rather than a flaw in the design logic, but it is load-bearing because the paper's headline value is precisely these numbers.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes MultiMoQ, a client-driven multi-access tile streaming framework built on Media over QUIC (MoQ). It modifies MoQ-Lite group delivery with separate pending/active queues and freshness-based scoring, and adds per-track QoE-driven access switching with make-before-break handovers. The evaluation compares MultiMoQ with DASH and standard MoQ in a 96-client Mininet emulation using measured access distributions, reporting goodput, latency, stall times, freeze ratios, and SSIM/VMAF. The authors conclude that MultiMoQ increases enhancement-tile and base-video goodput, reduces tail latency relative to DASH, avoids standard MoQ's persistent stalls, and yields smoother viewport playback, with the ablation showing that the multi-access controller contributes to continuity.","tokens_in":12186,"tokens_out":7034,"duration_ms":79871,"significance":"If the results hold, this is a useful extension of MoQ for live 360-degree streaming. The paper identifies a genuine robustness gap in standard MoQ-Lite and offers a clean architectural separation between transport-layer group continuity and endpoint access adaptation. The prototype is implemented and source code is provided, the ablation is well designed, and the scope is stated candidly. The main weakness is statistical: the headline numbers come from a single emulation run per system with no error bars, and several important switching parameters are unspecified. As it stands, the quantitative comparisons are plausible but not yet firmly established.","major_comments":[{"comment":"Section 4.4 explicitly states that Fig. 13 reports 96 client observations per system from one shared-topology run, not independent repetitions, and the rest of Section 4 gives no indication of repeated trials or error bars. Since the headline comparisons (e.g., Section 4.2: enhancement-tile goodput 1.20 vs 0.66 Mbps; p95 delay 1130 vs 3930 ms) are point estimates from correlated clients within a single run, the claimed quantitative gains are not yet established. Please add multiple independent runs, report distributions or confidence intervals, and adjust the claims to reflect the statistical uncertainty.","section":"Section 4.4 / Fig. 13 and Section 4.2"},{"comment":"Section 4.2 reports that 'DASH also rarely stalled', but Section 4.4 and Fig. 14 report a 51.5% freeze ratio for DASH with 26 freeze events. If transport stall time and viewport freeze ratio are different metrics, the paper must define both clearly and explain how a system with near-zero transport stalls can exhibit 51.5% playback freeze. As written, this contradiction undermines the continuity comparison and needs to be resolved.","section":"Section 4.2 vs. Section 4.4 / Fig. 14"},{"comment":"All primary links follow the measured distributions (bad: 8–15 Mbps, stable: 15–30, good: 30–40), while every secondary link is fixed at 30 Mbps and only MultiMoQ uses the secondary path. The goodput gains over DASH and standard MoQ may therefore be due partly to a larger total access bandwidth budget rather than to the proposed delivery redesign. Please add a control comparison that provides the baselines with a comparable second path, or discuss explicitly why the asymmetry does not affect the conclusions.","section":"Section 4.1.4 / Fig. 8"},{"comment":"The quantitative behavior of the system depends on several parameters: w_stale=1, w_gap=0.5, the five-entry pending queue, the watchdog intervals, the per-round handover limit, and the QoE switching thresholds. No values are given for the switching thresholds and no sensitivity analysis is provided. Without this, the reported improvements may be artifacts of a specific parameter tuning and the implementation is not reproducible. Please report the threshold values and add a sensitivity study for the main parameters.","section":"Sections 3.2–3.3"}],"minor_comments":[{"comment":"The definitions of B_i and D_i in Fig. 13 are easy to misread; consider adding a concrete example or a small table to illustrate the weakest-track and worst-latency computation.","section":"Section 4.4"},{"comment":"The footnote says the measurements were collected across different locations and time periods, but the sampling methodology, number of samples, and date range are not specified; please add these details so the distributions can be reproduced.","section":"Table 1"},{"comment":"The notation gap_g in Eq. (2) is inconsistent with gap(g) used in the text; unify the notation.","section":"Equation (2)"},{"comment":"The paper alternates between '1-s groups' and '1-s GOP'; choose one term for consistency.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is transparent about the single-run limitation, which is commendable, but transparency does not remove the need for repeated trials. The main risk is that the quantitative comparisons may be unstable; I would not reject on this basis alone, but the evaluation needs substantial strengthening before publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The thing to know: MultiMoQ is a credible, well-scoped systems contribution to the MoQ ecosystem. The pending/active queue separation and per-track make-before-break switching are the real new pieces, and the ablation cleanly separates the two components' effects. The evaluation is the weak spot: all headline numbers come from single emulation runs with no error bars or statistical tests, so the precise goodput/latency gains are not yet quantitatively stable. But the direction of the results is plausible, the design logic is coherent, and the authors explicitly bound their scope to Mininet and one media source.\n\nThe paper does well at identifying two distinct failure modes—DASH's coarse segment retrieval and standard MoQ's freshness-driven group interruption—and then designs each layer to address its own signal. The MoQ-Lite redesign preserves in-flight groups while maintaining fresh candidates; the endpoint controller switches tracks only after a decoder-safe entry point, maintaining monotonic output. The ablation is the strongest part: redesign-only already removes transport stalls, and adding multi-access control cuts freeze ratio from 4.62% to 1.09%.\n\nSoft spots, in proportion. First, the single-run issue: Fig. 13 is explicitly one shared-topology run, and Figs. 9, 10, 12, 14 lack error bars. That is load-bearing because the paper's selling point is those numbers. Second, the controller thresholds are hand-tuned and undisclosed; a sensitivity analysis would help. Third, the internal inconsistency: the text says DASH 'rarely stalled' at transport level, yet Fig. 14 gives DASH a 51.5% viewport freeze ratio. That is not necessarily contradictory—delivery stall versus compositor freeze—but it needs a sentence explaining the mapping. Fourth, the 96 clients are correlated observations within one topology, so treat them as a single trial with many endpoints, not independent replicates.\n\nOn citation and framing: the related work is adequate, and the self-citation of MoQ drafts is appropriate since those are the standards being extended. I do not see a circularity problem; they compare against external baselines.\n\nWho is this for? Readers working on MoQ, 360-degree streaming, or multipath delivery will get value from the design and the ablation. It deserves a serious referee—the idea is solid and the gaps are correctable. I would recommend accepting it conditionally, requiring repeated runs with confidence intervals and a clarification of the DASH freeze/stall mapping.","headline":"A solid MoQ delivery redesign with a genuine ablation, but single-run emulation leaves the headline quantitative claims unproven.","tokens_in":12717,"tokens_out":1663,"would_cite":true,"duration_ms":17731,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A redesigned Media-over-QUIC delivery layer with per-track multi-access switching keeps live 360-degree tile streaming continuous and lifts goodput above DASH and standard MoQ.","keywords":["360-degree video","immersive video streaming","Media over QUIC","multi-access delivery","tile-based video streaming","network emulation","playback continuity","viewport-adaptive streaming"],"falsifier":"Re-run the bad-access scenario multiple times with different random seeds or topologies and record enhancement-tile goodput and stall time; if MultiMoQ's 1.20 Mbps versus 0.66 Mbps for DASH and its near-zero stall percentages are not separated by the run-to-run spread, the claimed robustness advantage is not established.","tokens_in":11775,"feed_emoji":"🎥","tokens_out":11124,"duration_ms":109368,"temperature":0.7,"pith_summary":"The paper tries to establish that Media over QUIC's relay-assisted fan-out, which is attractive for large-scale live streaming but stalls badly under bandwidth constraints, can be made dependable for immersive 360-degree video by changing delivery control rather than bitrate selection. MultiMoQ separates pending groups from the active group inside MoQ-Lite, the transport-facing delivery layer, and lets each client monitor tracks, warm an alternate access path, and switch individual tiles without exposing a discontinuity. In network emulation with 96 clients, the authors report enhancement-tile goodput of 1.20 Mbps in the bad-access condition versus 0.66 Mbps for DASH and 0.72 Mbps for standard MoQ, with p95 end-to-end delay cut from 3930 ms to 1130 ms. A sympathetic reader would care because the result suggests a path to live 360-degree streaming to many concurrent viewers without the repeated backhaul fetches of DASH and without the persistent stalls of current MoQ.","feed_headline":"Multi-access MoQ cuts 360-video stalls to near zero","feed_subtitle":"A redesigned Media-over-QUIC delivery layer lifts tile goodput above DASH and trims tail latency to about one second.","key_machinery":"The carrying mechanism is a two-layer separation of concerns. The lower layer, a redesigned MoQ-Lite group scheduler (the transport-facing delivery layer of Media over QUIC), maintains a FIFO pending queue per track while the active queue holds at most one group; the sender picks the group minimizing $\\mathrm{score}(g) = w_{\\mathrm{stale}} \\cdot \\mathrm{stale}(g) + w_{\\mathrm{gap}} \\cdot \\mathrm{gap}(g)$, where the gap term measures the playback time skipped if the chosen group follows the last completed group, and neither queue maintenance nor overflow can modify the active group. The upper layer, client-driven multi-access control, runs one Hang instance (the client's media-consumption layer) per access path feeding a stream multiplexer that enforces make-before-break handover: start the new path before stopping the old one. The secondary access is subscribed and probed during warmup, cutover commits only after the new stream satisfies a timestamp-lead guard and a decoder-safe entry point, and rollback keeps the primary if the alternate fails. The redesign supplies delivery continuity along the server-relay-client path; the controller supplies timeliness by moving a degraded track to a better access before transport delay turns into playback lag.","core_discovery":"The central claim is that two coordinated changes make MoQ robust for concurrent tile streams. First, the MoQ-Lite delivery layer gives each track a FIFO pending queue and allows at most one active group per track on a dedicated QUIC stream, so freshness maintenance and overflow eviction never abort an in-flight group; a score balancing staleness and sequence gap selects the next group. Second, each client runs per-track access control with make-before-break handover: an alternate access is warmed while the primary continues, and cutover happens only when the alternate reaches a decoder-safe entry point and advances beyond the committed timestamp, so the application sees one ordered stream. The authors report that this design raises enhancement-tile goodput above both baselines across bad, stable, and good access conditions, reduces enhancement-tile tail latency relative to DASH to roughly one second, preserves audio continuity, and eliminates the persistent stalls of standard MoQ. Reconstructed viewport playback shows a 1.09% freeze ratio and one 0.50-second freeze event, versus a 51.5% freeze ratio for DASH and a 3.96% ratio with longer maximum freeze for standard MoQ.","pith_inferences":["Editorial extension: the pending-active separation tested on tiled 360-degree video should apply to other live media workloads with several synchronized streams, such as multi-angle sports or spatial audio, where one stalled track can degrade the whole presentation.","Editorial extension: because the paper disables adaptive bitrate selection to isolate transport, combining MultiMoQ with a representation controller is a direct next experiment and could show additional quality-of-experience gains when access bandwidth varies.","Editorial extension: the paper argues qualitatively that secondary-relay subscriptions can reuse existing relay fan-out instead of adding proportional backhaul load; a direct measurement of backhaul traffic would test whether this scalability benefit holds under many concurrent switches.","Editorial extension: the conservative switching trigger suggests a tunable tradeoff between responsiveness and stability; a parameter sweep over the watchdog interval and handover limits could map how much latency improvement is lost when switching is made more aggressive."],"forward_implications":["Enhancement-tile goodput in the bad-access condition rises to 1.20 Mbps with MultiMoQ versus 0.66 Mbps for DASH and 0.72 Mbps for standard MoQ.","Enhancement-tile p95 end-to-end latency drops from 3930/3062/2473 ms with DASH to 1130/936/956 ms with MultiMoQ across bad, stable, and good conditions.","Transport stall time falls to 0.11%, 1.32%, and 1.03% for MultiMoQ, while standard MoQ stalls 29.1% in the bad condition and above 14% otherwise, and its audio track stalls above 85% in every condition.","The MoQ-Lite redesign alone removes most transport stalls, and adding multi-access control cuts the playback freeze ratio from 4.62% to 1.09% and the maximum freeze from 1.03 seconds to 0.50 seconds.","Viewport reconstruction keeps the transport gains: MultiMoQ's freeze ratio is 1.09% with mean SSIM 0.990, compared with 51.5% freeze ratio for DASH and 3.96% for standard MoQ."],"supporting_citations":[{"why":"Defines Media over QUIC transport, the publish-subscribe track/group/object architecture that MultiMoQ extends.","marker":"[17]"},{"why":"Specifies MoQ-Lite's single-active-group delivery, the behavior MultiMoQ redesigns and the direct baseline for the stall problem.","marker":"[5]"},{"why":"Defines DASH segment-based streaming, the coarse-grained delivery baseline MultiMoQ compares against.","marker":"[24]"},{"why":"Supplies the network emulation platform used for the 96-client shared-topology evaluation.","marker":"[13]"},{"why":"Motivates the constrained shared backhaul assumption used in the evaluation topology.","marker":"[7]"}],"fun_headline_variants":["MultiMoQ multi-access MoQ cuts 360-video freeze ratio to 1.09%","MultiMoQ's multi-access MoQ eliminates persistent 360-video stalls","MultiMoQ: multi-access MoQ lifts tile goodput, trims tail latency to ~1s","MultiMoQ uses multi-path MoQ to cut 360-video freeze ratio to 1.09%","MultiMoQ redesigns MoQ for robust multi-access 360-video streaming"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The headline numbers come from a single emulation run per system with no repeated trials or error bars, so the comparisons rest on the assumption that those runs are representative of each system's typical behavior.","fun_headline_variants_meta":{"raw":{"variants":["MultiMoQ multi-access MoQ cuts 360-video freeze ratio to 1.09%","MultiMoQ's multi-access MoQ eliminates persistent 360-video stalls","MultiMoQ: multi-access MoQ lifts tile goodput, trims tail latency to ~1s","MultiMoQ uses multi-path MoQ to cut 360-video freeze ratio to 1.09%","MultiMoQ redesigns MoQ for robust multi-access 360-video streaming"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00125,"raw_usage":{"total_tokens":5162,"prompt_tokens":1020,"completion_tokens":4142,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":636,"completion_tokens_details":{"reasoning_tokens":4022}},"tokens_in":636,"tokens_out":4142,"duration_ms":23128,"temperature":1.0,"reasoning_tokens":4022,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T14:48:29.070346+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the bad-access scenario multiple times with different random seeds or topologies and record enhancement-tile goodput and stall time; if MultiMoQ's 1.20 Mbps versus 0.66 Mbps for DASH and its near-zero stall percentages are not separated by the run-to-run spread, the claimed robustness advantage is not established.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines Media over QUIC transport, the publish-subscribe track/group/object architecture that MultiMoQ extends."},{"cited_title":"2026.Media over QUIC - Lite","cited_arxiv_id":null,"evidence_quote":"Specifies MoQ-Lite's single-active-group delivery, the behavior MultiMoQ redesigns and the direct baseline for the stall problem."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the network emulation platform used for the 96-client shared-topology evaluation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Motivates the constrained shared backhaul assumption used in the evaluation topology."}],"review_version":1}