Media-over-Multipath-QUIC for Realtime Video Applications

Media-over-Multipath-QUIC for Realtime Video Applications Tanya Shreedhar∗

Zuji Zhou∗

Delft University of Technology The Netherlands

Delft University of Technology The Netherlands

Nitinder Mohan

Fernando Kuipers

Delft University of Technology The Netherlands

Delft University of Technology The Netherlands

arXiv:2608.10741v1 [cs.NI] 11 Aug 2026

ABSTRACT

networks at once. Laptops and phones combine WiFi with cellular, and LEO satellite service adds another whose failures are largely independent of terrestrial ones [48]. These networks also differ in cost. Starlink, for instance, charges a flat rate while a terrestrial one is metered. Past efforts to use these networks together add multipath capability inside the transport layer, so that several attachments work as one end-to-end connection. MPTCP does so for TCP and is widely deployed in production [3, 6, 47]. MPQUIC brings the same capability to QUIC, and is currently in standardization discussions [15, 33]. Both extensions rely on a scheduler that assigns each packet to a path. It treats the application-layer packets as uniform bytes and decides from transport metrics alone, namely round-trip time, loss, and congestion-window state. MPTCP forces this blindness, since it lives in the kernel behind a socket interface that offers applications no way to express preferences about path management or data scheduling [51]. As a result, the schedulers explored so far largely port the logic of MPTCP into MPQUIC, from round-robin and lowest-RTT heuristics to blockingaware refinements [18, 43, 58]. MPQUIC lifts this placement barrier, since a QUIC stack is also implemented at the application layer. However, the scheduling abstraction remains largely unchanged. Data still enters the transport as ordered streams of opaque bytes, and no interface lets an application state what those bytes need [33]. Real-time video workloads also increasingly adopt scalable video coding (SVC) [52]. Its intra-coded IDR (Instantaneous Decoder Refresh) frames, or I-frames, carry a complete picture, and P-frames encode only differences from earlier reference frames (see fig. 1). An I-frame is roughly 23× larger, enough to occupy a path for several congestion-window rounds [62]. A P-frame is small but undecodable until its references arrive. Delivering such a stream over multiple heterogeneous paths is a scheduling problem, since a large Iframe should avoid a path about to be disrupted (or delayed), dependent frames should stay together, and a metered path

Multipath transports place a client’s WiFi, cellular, and satellite networks under one connection, yet real-time video gains little from them. The scheduler that assigns packets to paths sees only bytes, so it cannot tell a keyframe that anchors a second of video from an enhancement frame whose loss costs one image. We show that the limiting factor is not a shortage of path diversity but the absence of a channel through which the application can name what the transport cannot see. Media over QUIC Transport (MoQT), already deployed on production CDNs, carries media as named Objects, and relays forward each Object’s metadata without interpreting it. The knowledge the scheduler lacks therefore already flows through the subscriber’s relay. We present MoMQ, a MoQT extension that turns this metadata into path decisions. Applications and relay operators install declarative rules at the edge relay that match Object metadata and express delivery preferences against labeled paths. The relay evaluates the rules mechanically, so it acts on video semantics while containing no video logic. On a live testbed spanning Starlink and WiFi, four rules cut P99.9 frame completion time from 384.7 ms under the best transport-only scheduler to 114.1 ms and reduce the required playback buffer by 61.5%. MoMQ is the only configuration that meets the 150 ms interactive latency target. Across relays in two countries and subscribers on two continents, the same rules apply unchanged and retain their advantage wherever the paths remain disjoint.

1

INTRODUCTION

Real-time video spans live streaming, conferencing, and cloud gaming, and its most interactive uses require a frame to travel from capture to display within roughly 150 ms [26]. A single access network leaves little slack inside this budget, because any congestion episode or wireless disruption translates directly into late frames. Each such frame misses its playout deadline, and the receiver stalls playback or discards it. Client endpoints increasingly hold several access ∗ Both authors contributed equally to this research.

1

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

should only be used when required. Existing MPQUIC schedulers cannot honor this, since no transport signal marks frame boundaries, criticality, or dependencies. Media over QUIC Transport (MoQT), a protocol under active standardization at the IETF [38], offers a place to close this gap. MoQT carries real-time media for conferencing and streaming alike as named Objects through a tree of relays. One publisher connection serves many subscribers, and each relay caches, prioritizes, and forwards Objects close to the receivers. Cloudflare already runs a MoQT relay on every server of its global CDN, and an industry consortium including Akamai, Cisco, and Google is building production relays [14, 16, 42]. This tree’s last hop, from edge relay to subscriber, crosses the access networks above. On that hop the relay is the sender, so the scheduler that chooses among those networks must run there. Prior application-aware schedulers build the logic into the sender’s own transport [64]. A relay serves several applications simultaneously, so it cannot embed the logic of any one of them. Each Object, however, carries application metadata that the relay forwards without interpreting, yet nothing in MoQT relates an Object to a path. We present MoMQ, a compatibility layer between MoQT and MPQUIC that enables multipath real-time video delivery over subscriber’s last-mile access networks. The subscriber installs declarative rules on its edge relay that map Objects onto suitable paths, and the same interface opens MoQT-level scheduling optimizations to CDN operators. To the best of our knowledge, MoMQ is the first multipath extension to MoQT. Specifically, we make the following contributions.

The four-rule policy reduces P99.9 frame completion time from 384.7 ms under the best transport-only scheduler to 114.1 ms, the only delivery tail inside the 150 ms budget. It uses the metered path for 11.3% of traffic, against 90– 100% for the latency-oriented schedulers. The gains persist at 2.5× the relay distance and vanish when the two paths converge onto a shared backbone.

2 BACKGROUND AND RELATED WORK 2.1 Background Media over QUIC Transport (MoQT) is in active standardization at the IETF. It organizes media as a hierarchy of Track, Group, Subgroup, and Object, whose levels map in layered video to a resolution layer, a Group of Pictures, a temporal layer, and an individual frame [38]. Each Object carries metadata alongside its immutable payload, and applications attach their own metadata through code point ranges reserved for application use. Relays must forward this metadata unchanged without attempting to interpret its meaning. A companion draft makes this boundary cryptographic by authenticating metadata end to end, so a relay can read it but not alter it [27]. A two-level priority scheme orders delivery under congestion, with subscriber priority expressing receiver preferences across Tracks and publisher priority expressing the inherent importance of an Object or Subgroup. Earlier delivery architectures offer two kinds of intermediary. A Selective Forwarding Unit (SFU) selects and forwards at frame granularity by parsing the media [32, 36, 63], while a CDN cache scales because it stores opaque bytes and sees nothing finer than a segment [4, 41]. A MoQT relay observes per-Object structure as an SFU does while remaining as independent of the media format as a cache, and the base protocol guarantees both properties. MoQT also lets a subscriber install property filters that the relay evaluates against Objects as it forwards them, and multiple filters combine into compound conditions [38]. Every filter action, however, resolves to forwarding an Object or withholding it, and the specification does not model a relay with more than one downstream path. MoMQ adopts this declarative matching and binds it to a new action, path selection (§3). Multipath QUIC (MPQUIC) [15, 33] runs one QUIC connection over several network paths in parallel, with independent RTT estimates, congestion state, and loss detection per path. Existing schedulers pick a path by transport heuristics, distributing packets cyclically (Round-Robin), by lowest observed round-trip time (MinRTT), by predicted head-ofline blocking (BLEST [18]), or redundantly on every path, with further variants refining the same signals [43, 55, 58]. The specification leaves scheduling to the implementation, guided by preferences the application is assumed to hold, yet

• We design MoMQ, a multipath extension that operates as a layer between MoQT and MPQUIC (§3). MPQUIC keeps path management, congestion control, and packet scheduling, and MoMQ passes it the application metadata that those mechanisms cannot see. Rules refer to paths through descriptive labels rather than identifiers, so a policy carries across access technologies and new scenarios need new labels and rules rather than protocol changes. The extension adds five wire-level elements and falls back to standard MoQT when a session does not negotiate it. • We define the scheduling rules and environment-specific enhancements that adapt MoMQ to widely used access networks (§4). A four-rule policy derived from live measurements addresses the scheduling failures of SVC conferencing over satellite and terrestrial paths, where the terrestrial path models a metered access such as cellular. A reconfigurationavoidance enhancement exploits the predictable disruption schedule of LEO constellations. • We implement1 MoMQ and evaluate it on a live testbed with subscriber nodes in Europe and North America, each holding a Starlink terminal alongside a terrestrial link (§5). 1 To be released upon acceptance.

2

Media-over-Multipath-QUIC for Realtime Video Applications ≈230 KB (≈23× P-frame)

Layer 2

P1

50 fps

Layer 1 Layer 0

IDR

frame #

0

Publisher

≈8–15 KB P5

SVC encoder

P7 strict P6 decoding dependency

P2

25 fps

13 fps

P3

P4 1

2

3

4

… P4 P1 P2 1

X

Conference’17, July 2017, Washington, DC, USA

1 RTT

i

convoy effect

In the scenario of fig. 1, an edge relay forwards the stream to subscribers whose network attachments differ, with S1 reachable over one path and S2 over two. For S1, the frame inequality first surfaces as the convoy effect (❶ in fig. 1). An I-frame that exceeds the congestion window drains over several transmission rounds, and every P-frame produced while it drains is queued behind it. Each queued P-frame inherits several RTTs of delay, and the convoy recurs at the head of every GOP. The convoy deepens when the path drops packets, whether through wireless channel losses [39] or through the scheduled reconfigurations of LEO satellite networks [11, 37]. Every retransmission extends the I-frame’s occupancy of the path. A reconfiguration met mid-transmission, the reconfiguration collision, can raise the I-frame’s completion time to several times the interactive budget. MoQT’s static priorities cannot express the remedy, because the correct ordering is conditional. P-frames should overtake only while an I-frame occupies the path, and only within a budget that does not delay the I-frame itself. These failures invite a second path. For S2, consider the pairing of a LEO satellite link with a terrestrial link, since the two differ in delay, stability, per-byte cost, and failure behavior [37, 48] (our measurement setup in §5.1). The satellite path offers wide coverage and high capacity at a flat rate, subject to the reconfigurations above. The terrestrial path offers lower and steadier delay over a narrower link that is usually metered. However, splitting the stream across the two paths adds two challenges. The first is the dependency violation (❷ in fig. 1). When a multipath scheduler splits dependent frames across paths with asymmetric RTTs, the receiver must buffer every early-arriving frame for at least the RTT difference until its reference arrives on the slower path. Recall that the multipath scheduler cannot see these SVC dependencies. The second is backup overuse, because access cost is equally invisible to the transport. Latency-optimizing schedulers concentrate traffic on the lower-RTT metered backup, and the user pays per-byte charges for minor latency gains. All challenges described above share the same root cause. Every property that separates one frame from another, its size class, its dependents, its tolerance for delay or loss, exists only above the layer where the path is chosen. As we show in §5.2, transport heuristics do not compensate and no existing MPQUIC scheduler meets the interactive latency target. We argue that last-mile path diversity is not the bottleneck, and the missing ingredient is application context rather than a better transport heuristic.

Sub (S1)

P8 5

6

7

8

… P8 P4 Edge Relay

2

i

dependency violation

Sub (S2)

… P3 P1 P6 P2

Figure 1: SVC delivery through an MoQT edge relay. Left, the temporal layering of one GOP, with arrows highlighting frame references. (❶) P-frames queued behind a multi-round IDR transmission on a single path. (❷) Dependent frames split across two paths and arriving out-of-decode-order.

it defines no interface through which those preferences could be expressed [33]. Running MoQT over out-of-box MPQUIC, the scheduler remains blind to the Object boundaries and provides application-agnostic delivery. Scalable Video Coding (SVC) [52] encodes a video once into a base layer and enhancement layers that refine it, so a receiver decodes as many layers as its network sustains. Deployed conferencing platforms including Google Meet and Jitsi Meet already run SVC in production [1, 25], which sharpens the semantic gap between MoQT and MPQUIC. Figure 1 shows the temporal layering of the three-layer stream we study, in which the base layer alone plays at 13 fps and the full stack at 50 fps. The encoder partitions the stream into Groups of Pictures (GOPs), self-contained runs of frames that decode without reference to anything outside the group. Each GOP opens with an I-frame (IDR), which carries a complete image. Every other frame is a P-frame that encodes only its difference from an earlier reference frame, so it is undecodable until that reference arrives (see fig. 1). This structure leaves the frames of one stream deeply unequal (§A.1 gives the per-type breakdown). At roughly 23× the size of a P-frame [62], an I-frame exceeds the congestion window, so its transmission spans several congestionwindow rounds while a P-frame completes within one. Because every frame depends on its I-frame directly or transitively, losing an I-frame invalidates its entire GOP, a full second of video, while losing a top-layer P-frame costs a single image. Enhancement frames can therefore tolerate risk that base-layer frames and I-frames cannot. A frame that arrives before its reference is undecodable until the reference follows, so frames that depend on one another must also arrive close together. None of these distinctions survives below the Object layer. On the wire an I-frame and a P-frame are indistinguishable, so any differentiated treatment requires additional context at the transport.

2.2

Related Work

Multipath transport for real-time media has a long lineage, and in all of it the application-aware decision runs at a sender that owns the traffic. MPRTP schedules RTP media across 3

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

paths at the sender [56], and XLINK drives a production MPQUIC scheduler with video QoE feedback across three million short-video plays [64]. AUGUR schedules frame retransmission and path switching for cloud gaming from per-user probability models at the service’s own edge servers [65], and Converge builds a video-aware multipath scheduler for WebRTC with path-specific packet protection [50]. QCON reaches multi-connectivity from inside the 5G radio access network instead, and steers streams across base stations below the end-to-end transport [31]. COMPACT splits foreground and background video tiles across cellular paths from a sender-side classifier [12], and ALCS compensates latency asymmetry for MPTCP on the same satellite and terrestrial pairing we study [61]. Transport-only schedulers such as BLEST and ECF avoid application coupling by using transport signals alone, and remain blind to what the bytes mean [18, 58]. On the LEO side, prior work shows that congestion control misreads satellite mobility as congestion [30], LeoCC makes a single satellite path robust to that dynamic [29], and handover-aware pacing resizes a WebRTC sender queue ahead of predicted disruptions [22]. Casparsen et al. predict degraded LEO windows and suggest steering traffic between interfaces during them, without a mechanism that could act on the suggestion [9]. A second line gives applications direct influence over multipath scheduling. ProgMP lets an application install its own MPTCP scheduling program in the sender’s kernel [21], and DTP attaches size, priority, and deadline metadata to blocks that its endpoint transport schedules against [53]. Stream-aware MPQUIC schedulers map streams to paths by priority [46, 54], MP-DASH states path preferences bound to DASH segment deadlines [24], and Kozuka and Okabe bind streams to policy-defined path groups [28]. Cech et al. rethink the MPQUIC scheduling interface itself, with the application pacing transmission through tokens [10], and an Internet-Draft maps the modalities of a multimodal stream to paths at the endpoint transport [57]. On a single path, Salsify couples codec and transport into one control loop [19], and Syntra synthesizes cross-layer video controllers from a declarative objective [44]. The interfaces range from imperative programs to declarative objectives, but every system in this line assumes the scheduler runs where the application does. MoMQ moves this decision to the CDN-operated edge relay. The relay serves many applications at once and cannot be trusted to run their code, so preferences reach it as declarative rules over per-Object metadata. Within MoQ, recent work treats the relay as a general object substrate, both by applying it beyond media [17] and by proposing selective Object dropping at the relay [20]. The closest MoQ work to ours reaches multiple networks only through sequential failover, where a subscriber holds connections to several relays and switches on transmission

error [40]. Blind duplication across paths needs no protocol support, and it appears in our evaluation as the Redundant baseline, at twice the bandwidth and with no per-Object decision. The MoQT specification itself never mentions multiple paths and treats redundancy only as relay and publisher duplication with sequential switchover [38]. We are aware of no Internet-Draft that proposes multipath for MoQT. To our knowledge, MoMQ is the first system in which a MoQT relay selects among concurrent paths per Object.

3

MOMQ: MEDIA OVER MULTIPATH QUIC

MoMQ is a backward-compatible extension to MoQT that lets the relay schedule Objects across the paths of an MPQUIC connection to the subscriber. Every Object passes through the relay that makes the forwarding decision, and the application can attach descriptive metadata to each Object, for instance a field that distinguishes an I-frame from an enhancement-layer P-frame. The metadata sits as key-value pairs in a block between the unchanged Object header and the payload, which the relay never reads (fig. 8 in §A.2). MoQT, however, lacks a channel through which the application can state what should happen to an Object carrying a given metadata value, and MoMQ adds this channel. The subscriber installs rules on its edge relay that match generic Object metadata and express delivery preferences against labeled paths rather than path identifiers (fig. 2). For example, a rule can keep every Object that depends on another Object on the same path as its dependency, or prefer paths of a given cost class (§4.1 derives four such rules for SVC delivery over LEO and terrestrial paths). The relay evaluates the rules mechanically as Objects pass through it and merges the matching actions into a per-Object directive that its MPQUIC scheduler takes as advice. It never interprets what a metadata value means, so it acts on video semantics while containing no video logic. The rule interface follows the match-action abstraction of programmable forwarding [7, 34], applied one layer up. The endpoints keep the semantics and the transport implements only the mechanism [13, 49]. Last-hop architecture. MoMQ operates only at the last hop of the relay tree, where the edge relay and the subscriber may hold an MPQUIC connection across the subscriber’s access networks2 . Upstream hops carry standard MoQT unchanged, since they traverse backbone networks whose path diversity the infrastructure manages. The subscriber, by contrast, knows the cost and capacity of each of its own access networks. Media flows downstream, so the relay is the sending endpoint of the multipath connection and the only party that holds the Objects and chooses their paths. Only the edge relay implements the extension, and because each subscriber and relay pair runs an independent MoMQ session, one 2 §6 discusses extending MoMQ to the publisher’s first hop.

4

Media-over-Multipath-QUIC for Realtime Video Applications Origin Relay

MoQT

Edge relay

Conference’17, July 2017, Washington, DC, USA

fourth is that evaluation must be cheap and bounded, because it runs once per Object on the forwarding path. An interface permitting arbitrary predicates invites unpredictable latency and denial of service through deliberately expensive matches, so every relay must support the policy language.

Publisher

Subscriber

Media

Object forward + cache

MoQT

Objects + metadata

Decoder + player ENABLE_MOMQ

Subscription

Rules over opaque metadata. A rule contains match entries that select Objects by metadata, action entries that express delivery preferences, and a priority that orders it against the other installed rules. The relay’s role is confined to matching conditions and executing actions, so a relay that appears to understand SVC is one configured with rules that match SVC frame types (the first design challenge). The match language has two operators (table 6 in §A.2), where EQUALS compares a metadata value byte for byte against a stated value and EXISTS tests for the presence of a key. Match entries within a rule combine with AND, disjunction is expressed by installing several rules, and a rule with no match entries is a catch-all. A match entry ranges over the Object’s metadata joined with annotations that the relay’s own components may inject at evaluation time, for instance a flag that a link’s disruption window is currently open. A rule can therefore condition on state the relay observes locally through the same two operators (§4.1 injects two such annotations for LEO satellite paths). Both operators reduce to byte comparisons, so rule evaluation runs at a cost bounded by the number of installed rules and a match cannot be made deliberately expensive (recall fourth design challenge). EQUALS covers categorical distinctions such as frame type and layer index, EXISTS covers presence-based policies such as acting on every Object that declares a dependency, and more complex predicates are expressed through rule composition. The complete policy of our case study uses only these two operators (§4.1). The language cannot express negation or a numeric range. A policy that needs an else branch obtains it from priority order, since an Object that fails every specific match falls through to the catch-all. Evaluation cost still grows with the number of installed rules, so the design also recommends per-session caps on rule count, match entries, key and value lengths, and installation rate (§A.3 gives recommended values). The relay enforces a cap by rejecting the offending operation. PRIORITY governs the order in which queued Objects reach the wire under contention (table 7 in §A.2 lists all four action types). BALANCING constrains whether one Object’s packets may split across paths for throughput. Its default keeps each Object on a single path, since cross-path reordering is the primary source of the application-level latency degradation observed in §2.1. PATH_PREFERENCE biases selection toward paths whose labels contain a specified keyvalue pair, and falls back to default selection when no healthy path matches. A rule preferring cost_class=free therefore

metadata

directive

match & merge

rule selector

rule + label authoring

MoMQ advises

MPQUIC

relay state labels, budget, history

MoMQ-compatible scheduler

QUIC Streams media data

reorder + reassemble Path 1

QUIC Streams

Path 2 control

Figure 2: MoMQ at the last hop of an end-to-end MoQT delivery. The subscriber installs rules and path-label annotations over the MoQT session. The edge relay matches each Object’s metadata against them, merges the matching actions into a per-Object directive, and hands it to the MPQUIC scheduler as advice rather than a command. Upstream hops are unmodified MoQT.

relay serves MoMQ-enabled and legacy subscribers at once. This placement assumes one relay reachable over all of the subscriber’s access networks, and an edge relay in a wellconnected datacenter meets this assumption. The alternative of connecting to a separate relay inside each access network needs no protocol change, but it forfeits the per-Object path choice and the shared cache of a single multipath sender. Design challenges. The first challenge is expressiveness against agnosticism. The interface must encode scheduling policies such as keeping dependent SVC frames together and steering I-frames away from a disruption window. It must simultaneously stay blind enough that the relay never parses a codec, never tracks a dependency graph, and never needs a software update when a new format appears. The second is that rules must outlive the topology. A subscriber that moves from WiFi and cellular to WiFi and satellite should not have to rewrite its policy, yet any rule that names a path directly is invalidated the moment paths are added, removed, or renumbered. The interface therefore cannot expose path identifiers and needs a level of indirection between the application’s stated preference and the path that satisfies it. The third is that the relay must retain authority. It observes live path conditions that the subscriber cannot see, serves many subscribers at once, and is subject to operator policy. An application that could demand a specific path could starve other subscribers or force traffic onto a path the operator has reserved, so application preferences must be advisory. The 5

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

Scheduling pipeline. For each outgoing Object the relay executes three stages, and each stage reads distinct state. Rule evaluation walks the installed rules in priority order and collects the actions of every rule the Object matches, consulting only the session’s rule store and the relay’s current annotations. Directive merge resolves those actions per dimension into one scheduling directive, and consults nothing else. Path selection hands the directive to the MPQUIC scheduler, which weighs it against path labels and live transport metrics. Within one directive an affinity binds while a preference biases, so a resolvable affinity decides the path before any preference is weighed. The directive crosses the layering boundary as scheduler-readable context is attached to the Object’s stream (see §4). If no rule matches, the Object carries a default directive, BALANCING, that balances across all paths. A directive that cannot be satisfied under current conditions yields to the Metadata and path labels. The publisher attaches metadefault scheduler, so MoMQ never blocks delivery. Every didata to an Object as key-value pairs, which travel with it to rective is advice, so the relay keeps final authority over path every relay that forwards it. The pairs form a block between selection (the third design challenge). The relay honors a the unchanged Object header and the payload (see fig. 8 in directive according to local policy and resource availability. §A.2 for the MoMQ object layout. MoMQ defines well-known Note that differentiated services applies the same division, keys such as frame_type and temporal_layer, together where per-hop behaviors are advisory and enforcement is with the addressing key object_id that PATH_AFFINITY domain-local [5]. Advisory semantics let relays with different resolves against. Applications may define their own keys, capabilities interoperate, and they accommodate conflicts which relays match without interpretation. The publisher the application cannot foresee, such as two subscribers rethat attaches a key and the subscriber that matches on it are questing the highest priority when only one path is healthy. two ends of the same application, so they share the vocabuThe pipeline’s two inputs, Object metadata and path labels, lary without relay involvement. Application keys sit in the are also its extension points. The relay may refresh labels ranges MoQT reserves for application use (§2), so the relay’s continuously from any local source of path knowledge, such blindness is guaranteed by the base protocol, not asserted as a model of a link’s disruption schedule. A rule that referby our design extension. ences such a label converts that knowledge into scheduling Path labels describe path properties and come from both behavior while the rule language, the wire format, and the ends of the connection. The relay labels paths from operevaluation logic remain unchanged. A specialization for a ator configuration or transport observation, for instance link technology is therefore an add-on that any operator or link_type=satellite, and the subscriber annotates them application can deploy, namely a label provider that annowith knowledge only it holds, for instance cost_class=metered. tates paths or the match context, plus rules that reference The relay merges both sets per path, with the subscriber’s the annotation. MoMQ itself contains no environment-specific value taking precedence where the two assign the same logic. We build one such add-on for LEO satellite paths in key, so a rule can act on information that neither side holds §4.1 and evaluate it in §5 against state-of-the-art alternatives. alone. The override is confined to descriptive keys such as cost_class, so a subscriber label can never alter how the reProtocol surface and lifecycle. MoMQ adds five wire-level lay configures its transport (see §4). Because rules reference elements to MoQT, one setup parameter and four control meslabels rather than path identifiers, they remain valid when sages, and fig. 3 shows how a session uses them. §A.2 gives paths are added, removed, or renumbered (the second design the byte layout and code points of each element. Both endchallenge). A rule preferring paths where cost_class=free points exchange ENABLE_MOMQ in the MoQT setup, after which applies to whichever path carries that label at the moment, the relay reports its paths and labels in a PATH_STATE_REPORT and a switch to a metered satellite plan becomes a single and the subscriber annotates them through PATH_LABEL_UPDATE. relabel rather than a rule reinstallation. The indirection also The subscriber then installs rules with PATH_MAPPING_RULE, hides the relay’s topology from the subscriber and leaves the and the relay accepts or rejects each one with PATH_MAPPING_RESULT. relay free to translate a preference into a path decision while Those four messages are the whole of the control plane. The respecting subscriber’s preferences. channel carries no compliance feedback, since PATH_MAPPING_RESULT does not block delivery when the free path is temporarily unavailable. PATH_AFFINITY names a metadata key whose value holds the object_id of another Object. The relay looks that identifier up in a bounded history of recent assignments (one byte comparison) and sends this Object on the path it recorded for the referenced one. When multiple rules match an Object, their actions merge per dimension, taking the maximum priority, a single path if any rule requests one, and the first matching affinity. Path preferences merge as a union ordered by rule priority. When two rules prefer different values of the same label key, the higher-priority rule prevails, so a specific rule overrides a catch-all default. An action entry carries its own length and a relay skips an action type it does not implement. This design choice leaves the door open for future extensions as new delivery preferences are expressed as new action types rather than protocol revision.

6

Media-over-Multipath-QUIC for Realtime Video Applications Publisher + upstream relays

standard MoQT

Data Plane

Control Plane

Edge relay

① Handshake ② Setup ③ Discovery ④ Rules ⑤ Delivery ⑥ Adapt

Conference’17, July 2017, Washington, DC, USA

The division between reused and added code follows the protocol layering. The QUIC connection machinery, MPQUIC path management, and per-path congestion control are used unchanged, with each path’s controller assigned by static configuration. In the MoQT layer, the Object encoding gains the metadata block and nothing else, so every base header field keeps its wire format. MoMQ’s setup parameter and four control messages live in a protocol module separate from the base MoQT message set, so the extension is additive in code as it is on the wire. Changes to the transport itself are confined to its scheduler, which is extended to read a per-stream directive during path selection and to admit prioritized data into the slack of a multi-round transmission (§4.1). Installed rules live in a per-session store that rule evaluation consults for every forwarded Object. Installing a rule under an existing identifier replaces it. MoMQ and MPQUIC are negotiated independently, so a subscriber can install rules while only one path exists and the policy takes effect without an additional round trip when a second path appears. Metadata is attached as UTF-8 keys with byte-string values, so frame type, temporal layer, and dependency identifiers are present for each Object. The relay reads these fields for matching and never parses the payload, which remains encrypted end to end. The metadata overhead is minimal, roughly 40–80 bytes on Objects whose payloads span 5–230 KB. Note that our prototype does not implement multi-subscriber rule isolation, relay-side authorization of rule installation, or the resource limits as we consider them out of scope. §6 discusses how new rule sets could reach a relay.

MoMQ

Subscriber QUIC + MPQUIC handshake

CLIENT_SETUP {ENABLE_MOMQ} SERVER_SETUP {ENABLE_MOMQ} PATH_STATE_REPORT {paths, labels} PATH_LABEL_UPDATE {cost_class} PATH_MAPPING_RULE {install} PATH_MAPPING_RESULT {OK} Objects on Path 0 Objects on Path 1 per Object: Relay evaluates rules, attaches a directive, and selects the path

PATH_STATE_REPORT (updated) PATH_MAPPING_RULE (update) PATH_MAPPING_RESULT (OK)

Figure 3: A MoMQ session from handshake to steady state. The shaded exchanges are the only additions MoMQ makes, all control-plane, at setup and whenever paths or policy change. Delivery itself carries no MoMQ signaling, and upstream relays and the publisher see standard MoQT throughout.

acknowledges that a rule was installed rather than that it was followed. A subscriber verifies that its preferences take effect by observing delivery. Steady-state delivery then runs the scheduling pipeline on relay-local state alone, and no further MoMQ message is exchanged until a path changes. When one does, a fresh PATH_STATE_REPORT lets the subscriber adjust rules or labels without interrupting delivery. MoMQ state is session-scoped and isolated between subscribers. A session in which either side omits ENABLE_MOMQ carries no MoMQ messages and behaves as standard MoQT. Note that we do not change anything else in MoQT. Group ordering, Object status, caching, priority scheme and the stream-mapping modes all behave as before. Subscriber and publisher priority continue to govern which Objects the relay forwards first at the MoQT layer, while a MoMQ PRIORITY directive acts one layer down and orders the streams already released to the transport.

4

Crossing the layer boundary. When rule evaluation completes, the relay binds the merged directive to the QUIC stream that carries the Object, as implementation-local context that the scheduler can read. Before attachment, a QUIC stream is an opaque byte channel that the scheduler treats like any other. After attachment, the scheduler reads the directive from the stream without parsing any MoQT framing. MoQT carries each Subgroup on its own QUIC stream, so a stream corresponds to a temporal layer. Many Objects therefore share one stream, and the relay refreshes the stream’s directive with each Object it forwards. When the scheduler next selects a path, it reads the directive of every stream that is ready to send. Each dimension acts as §3 defines it, so the priority sets the dequeue order under contention, the balancing constraint gates cross-path splitting, the preference biases the scheduler’s path scoring, and the affinity resolves through the bounded history of recent assignments. If no rule matches, the directive holds defaults, namely priority zero, SINGLE_PATH, no preference, and no affinity (§3). Suppose an Object arrives carrying frame_type=IDR, and an illustrative rule assigns matching Objects priority 100,

MOMQ IN PRACTICE

We implement MoQT and its MoMQ extension in Rust on top of TQUIC [60], an open-source QUIC stack with MPQUIC support. The prototype exists to test whether rule-driven path selection produces the behavior the design predicts, not to serve production traffic. Three binaries form the delivery chain, where the publisher encodes media into GOPstructured Objects, the relay forwards them and hosts the MoMQ rule path, and the subscriber reconstructs frames and records per-frame delivery timing. 7

Shreedhar and Zhou et al.

SINGLE_PATH, and a preference for cost_class=free. Rule evaluation produces exactly that directive, directive attachment binds it to the Object’s stream, and path selection weighs it against two live paths, a 45 ms satellite path labeled cost_class=free and a 15 ms metered path. The scheduler dequeues this stream first, keeps the frame whole, and sends it on the free path even though the metered path is 30 ms faster (enforced by the cost-sensitive behavior rule in §4.1). Information also crosses this boundary in the other direction, and again only as reads. Rule-side state may consult transport state, as the interleave budget of §4.1 consults a congestion-window estimate, but no rule can set a congestion window, retransmit a packet, or pin a path. Labels are the only channel through which subscriber input could reach transport configuration, so the implementation bounds this channel as well. Descriptive labels take effect only through rules that reference them, and the subscriber-over-relay label merge of §3 applies to descriptive keys alone. An implementation may treat selected keys as operational, for instance a key that selects a path’s congestion controller, but such keys are accepted only from operator configuration against an allowlist. The relay also rate-limits its own PATH_STATE_REPORT messages to one per smoothed RTT, since path state can change on millisecond timescales during a reconfiguration and per-fluctuation reports would be stale before the subscriber could act on them.

4.1

RTT (ms)

120

RTT reconf. event

(a)

I-frame delay P-frame delay

600

80 400 40

200 ms

200

0

0

Delayed frame ratio (%)

0

20

40

60

Time (seconds)

80

100

120

(b)

I-frame 14.8%

15

Frame completion time (ms)

Conference’17, July 2017, Washington, DC, USA

before I-frame (0) after

10 5 0 -20

-10

0

10

Frame index distance from I-frame

20

Figure 4: Delayed frames on Starlink. (a) Frame completion times beyond 200 ms over the sender-perceived RTT trace, with reconfiguration events marked and delays beyond 400 ms drawn as larger markers. (b) Delayed-frame ratio by frame index distance from the I-frame across 100 GOPs.

The disruption itself is schedulable, because the 15-second reconfiguration cycle of §2.1 runs on a constellation-wide wall clock, at the 12th, 27th, 42nd, and 57th second of each minute [11, 37, 59]. Our measurements confirm this schedule from a separate vantage point, with every observed interval within ±50 ms of its predicted time, so the timing is predictable enough to schedule against (F3). The events are also brief enough that a short avoidance window suffices, with a median duration of 58 ms and 88% completing within 100 ms (F4, with the full distribution in §A.4).

Case Study: MoMQ over LEO-Terrestrial Networks

We build a complete specialization, an SVC conferencing policy for the Starlink and WiFi path pair that §5.1 describes. Recall from §3 that a specialization has two halves, a label provider that annotates paths from local knowledge and rules that reference the annotation. For this pairing, the local knowledge is the satellite path’s reconfiguration schedule, which the label provider tracks, and each path’s cost class, which static labels record. The same derivation applies to a cellular pairing, where the literature already provides congestion control tuned to wireless access [35] and path preferences for metered cellular links [24]. Table 1 shows the rules, R1 through R4 , along with the motivating findings F1 through F5 from our experiments on testbed nodes equipped with a Starlink and a terrestrial connection. Figure 4 shows how the single-path failures of §2.1 appear on the satellite path. In fig. 4a, nearly every frame delayed past 400 ms sits inside a reconfiguration window (F2). Figure 4b shows the convoy behind each I-frame transmission. The I-frame carries the highest delayed-frame ratio at 14.8%, and the following P-frames decay from 7.2% toward 1%. Frames before it stay near 0.9%, so the blocking runs forward from the I-frame and never behind it (F1).

R1 Budget-based P-frame interleaving addresses the convoy effect of §2.1 (F1). During an I-frame transmission spanning 𝑘 RTT cycles there is slack capacity, namely the difference between what the congestion window carries across those cycles and the I-frame size, given by   𝑆𝐼 𝐵 budget = · cwnd cons − 𝑆𝐼 (1) cwnd cons

where 𝑘 = ⌈𝑆𝐼 /cwnd cons ⌉. This slack carries P-frame packets without adding a transmission round, since the I-frame needs 𝑘 rounds whether or not the unused capacity is filled. §5.2 confirms that I-frame completion is unchanged when d𝑚 × 𝑏𝑅𝑇𝑇𝑙 interleaving is active. We derive cwnd cons = 𝐵𝑊 from LeoCC’s conservative Kalman-filtered bandwidth and minimum RTT estimates [29], since an overestimate would admit P-frame packets that compete with the I-frame instead 8

Media-over-Multipath-QUIC for Realtime Video Applications

Conference’17, July 2017, Washington, DC, USA

Table 1: The four MoMQ rules for SVC conferencing, in descending priority order. Each rule closes one delivery failure of §2.1. # Match Action Closes

of filling its slack. For a typical case with 𝑆𝐼 = 230 KB and cwnd cons = 80 KB, this yields 𝑘 = 3 rounds and 𝐵 budget = 10 KB, roughly one P-frame per I-frame transmission. The action of R1 is a plain priority grant, because interleaving is not an action type. A relay-side budget tracker admits a prioritized P-frame into the current congestion-window round only while 𝐵 budget has room, and a zero budget admits nothing, so the mechanism cannot make things worse.

PRIORITY (highest) pending_iframe= true R2 frame_type=IDR and PATH_PREFERENCE leo_state=reconf cost_class=metered R3 depends_on EXISTS PATH_AFFINITY R1 frame_type=P and

R2 Reconfiguration-aware scheduling addresses the reconfiguration collision of §2.1, which dominates the tail (F2). Dropping the affected frame is no escape, because a lost Iframe invalidates its entire GOP, so delivery must be ensured rather than abandoned (F5). Rather than building a prediction model, we exploit the deterministic schedule directly. The label provider of this specialization is a reconfiguration marker. During negotiation the subscriber labels the satellite path, and from then on the marker injects leo_state=reconf into the match context during a danger zone of ±100 ms around each scheduled reconfiguration time, on its own clock and with no per-event signaling. While the annotation is present, I-frames prefer the backup path, and P-frames continue on the satellite path, where a disrupted frame costs one retransmission delay rather than a stalled GOP. The window is conservative against the measured start jitter and the typical event duration. Because four danger zones per minute occupy 800 ms in total, or 1.3% of time, the additional backuppath usage is small.

R4 catch-all

PATH_PREFERENCE cost_class=free

Convoy effect Reconf. collision Dependency violation Backup overuse

application-agnostic, because the annotations describe conditions the relay observes or computes locally, and the application’s own keys stay opaque. Rule composition follows the per-dimension merge of §3. An enhancement-layer P-frame arriving during a danger zone while an I-frame is in flight matches R1 , R3 , and R4 , whose priority, affinity, and preference merge into its directive. The priority decides when the frame is dequeued and the affinity decides which path it takes, at once rather than in sequence. An I-frame in the same danger zone exercises the preference merge instead, where the higher rule priority of R2 overrides the catch-all preference of R4 . Every dimension of the outcome is resolved by exactly one rule, and only the scheduler’s advisory override remains discretionary. The policy uses three of the four action types directly, and the fourth, BALANCING, acts through its conservative SINGLE_PATH default.

R3 Dependency-aware co-location addresses the dependency violation of §2.1. The mechanism routes each frame to the same path as the frame it depends on, using a bounded history of recent Object-to-path assignments. No dependency crosses a GOP boundary, so a history of one GOP’s worth of entries covers every reference the rule can encounter. If the referenced Object is absent from the history, or its recorded path has become unavailable, the frame falls through to default selection, so a stale history degrades placement rather than delivery.

5 EVALUATION 5.1 Experimental Setup Our testbed consists of a Starlink terminal alongside a university campus WiFi connection in Europe, connected to a server in a commercial datacenter in Germany, roughly 700 km away. The Starlink terminal provides LEO satellite connectivity with throughput between 50 and 200 Mbps and RTT between 25 and 80 ms depending on satellite position and reconfiguration state. The WiFi connection is the secondary path and emulates a metered cellular backup link, so traffic on it carries a per-byte cost. We vary this topology at both ends (§5.2). A second relay runs in a commercial datacenter in Finland, and a second subscriber site in western Canada holds its own satellite and terrestrial path pair. We transmit a 100-second 1080p video encoded with SVC [52] using 1-second GOPs at 50 fps. The encoding uses the threetemporal-layer structure described in §2.1, with each GOP

R4 Cost-sensitive path preference addresses the backup

overuse of §2.1. Unlike the first three mechanisms, it encodes a cost constraint rather than a measured timing failure. The mechanism labels each path with a cost_class attribute and defaults to the cost-free path unless a higher-priority rule overrides it. The latency-oriented schedulers of §2.1 treat the metered path as general-purpose overflow. Under this rule set it carries only what a higher-priority rule sends there, chiefly I-frames inside danger zones. Two of the rule set’s match keys are not publisher metadata. pending_iframe and leo_state are the relay annotations that the match model of §3 admits, injected by the budget tracker while an I-frame is in flight and by the reconfiguration marker during danger zones. The relay remains 9

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

anchored by a single I-frame, and §A.1 tabulates the perframe-type sizes at this operating point. The choice of 1second GOPs reflects common conferencing practice. Shorter GOPs recover faster from loss but raise bitrate through more frequent I-frames, while longer GOPs are more efficient but amplify the impact of each I-frame loss. We compare seven configurations over these two paths. Two single-path baselines carry MoQT over regular QUIC on one link alone. Four transport-only MPQUIC configurations run the state-of-the-art popular schedulers, namely Round-Robin, MinRTT, BLEST, and Redundant, which together span the byte-level design space from cyclic distribution and lowest-RTT preference to blocking avoidance and full duplication. MoMQ installs the four rules of §4.1, so the only difference between MoMQ and the transport-only configurations is that Object metadata reaches the path decision. We test four congestion control algorithms, namely Cubic [23], BBRv3 [8], Copa [2], and LeoCC [29], the last only on Starlink since it is designed for LEO links. In multipath configurations each path runs its own controller, LeoCC on Starlink and Cubic on WiFi (§4). Because the relay terminates the upstream MoQT session rather than tunneling it, these controllers run in series with the publisher’s own control loop rather than nested inside it, so the interaction that degrades tunneled multipath transports does not arise [45]. The single-path baselines use the best controller for each link, Copa on WiFi and LeoCC on Starlink, which §A.5 establishes by comparing all four controllers per link. All measurements record per-packet RTT timestamps at millisecond precision. Frame completion time (FCT), the duration from first packet transmission to last packet acknowledgment of a frame, captures delivery latency at the transport level. Minimum buffer length, the smallest playback buffer ensuring stutter-free playback, captures the quality of experience at the receiver. Backup-path usage, the fraction of traffic carried by the metered path, captures the cost of a configuration. Each configuration is measured over 10 runs of the same source video, yielding 100 buffer datapoints and ≈5 000 frames per configuration. In addition to means, we also report percentiles since a small number of extreme events, such as a single I-frame and reconfiguration collision, can dominate user experience while leaving the mean nearly unchanged. Each topology still measures one subscriber site with one satellite and terrestrial path pair, so the absolute numbers are specific to that vantage point. §5.2 compares across the relay and subscriber variations to establish which of the conclusions are generalizable.

5.2

seven configurations through the Germany relay. Figure 5a plots the buffer distributions and fig. 5b the FCT percentiles. Even the stronger of the two single-path baselines, Copa over WiFi, misses the 150 ms interactive target [26] by more than a factor of two on both tail FCT and playback buffer. LeoCC on Starlink trails further, because every reconfiguration lands on its only path and stretches its worst tails past half a second. Transport-only multipath does not close this gap. In fig. 5a, every scheduler’s buffer latency sits above the 150 ms target, and none improves meaningfully on single-path WiFi. MinRTT routes ≈90% of traffic to the lower-RTT WiFi path, and when a 230 KB I-frame fills the 82 KB WiFi congestion window, the overflow packets spill onto Starlink at 45 ms RTT. The receiver then waits for these slower packets before the I-frame can be decoded, and the resulting cross-path headof-line blocking leaves MinRTT behind single-path WiFi on every metric. Round-Robin distributes each I-frame’s packets cyclically, so about half arrive via WiFi at 15 ms while the rest arrive via Starlink at 45 ms, and the systematic 30 ms per-round reordering penalty accumulates across three or more rounds. It is the worst configuration overall. BLEST avoids Starlink whenever it estimates blocking would occur, which makes it in practice a smarter single-path WiFi scheduler, and its small edge comes at ≈92% usage of the metered path. Redundant duplicates every packet on both paths and matches single-path WiFi at twice the bandwidth cost. The residual tails of the four schedulers share one cause, an I-frame in flight when the satellite path reconfigures (§2.1). In fig. 5b, every baseline crosses the 150 ms target between its median and its P99. MoMQ reaches a P99.9 of 114.1 ms, a 70.3% reduction from the best transport-only scheduler (BLEST) and 71.5% from the best single-path baseline (Copa over WiFi), and its playback buffer undercuts the best baseline by 61.5%. It is the only configuration that meets the interactive target on both tail latency and buffer, and it does so with 11.3% of traffic on the metered backup against 90– 100% for the latency-oriented transport schedulers. Its median FCT sits a few milliseconds above BLEST’s, the cost of keeping bulk traffic on the flat-rate satellite path rather than the faster metered one. All seven configurations hold the same two paths and the same per-path controllers, so the 70.3% tail reduction comes from MoMQ mapping Objects to paths by their metadata. Contribution of scheduling rules. Activating the four rules of §4.1 incrementally on the live testbed lowers the median buffer from ≈248 ms under the cost-sensitive default ( R4 ) alone to ≈128 ms with the full set, while backup-path usage grows only from 0.3% to the 11.3% reported above. The activation steps add interleaving ( R1 ), reconfiguration avoidance ( R2 ), and dependency co-location ( R3 ) in turn.

Performance Results

Transport-level performance. Table 2 reports frame completion time, playback buffer, and backup-path usage for all 10

Min. playback buffer (ms)

Media-over-Multipath-QUIC for Realtime Video Applications

Conference’17, July 2017, Washington, DC, USA

full system and the reconfiguration-avoidance configuration form a tight cluster near 110 ms, while cost-sensitive and interleaving remain above 217 ms, so reconfiguration avoidance alone removes roughly 100 ms of tail latency. Without it, an I-frame and reconfiguration collision sets the P99.9 of the whole distribution. Figure 6b isolates I-frame FCT. Cost-sensitive and interleaving have nearly identical I-frame distributions, which confirms that P-frame interleaving does not affect I-frame scheduling. Interleaved P-frames travel in the slack capacity of the I-frame’s congestion-window rounds without altering the I-frame’s own path assignment. Separation begins with reconfiguration avoidance, whose rerouting during danger zones sends 6.7% of I-frames over WiFi and produces the low-FCT step in the 16–50 ms range. This compresses I-frame P99 from 286 ms to 119 ms, since a rerouted I-frame avoids both the outage and the congestionwindow collapse that follows it. Full MoMQ trims a further 5 ms through dependency co-location. Figure 6c shows that P-frame tail compression drives the buffer improvements. Under cost-sensitive scheduling, Pframes have a P99/P50 ratio of 3.5×, driven by head-of-line blocking while multi-round I-frames are transmitted. Interleaving cuts P-frame P99 from 122 ms to 54 ms. Reconfiguration avoidance compresses it further to 43 ms by eliminating the cascading effect of collisions on subsequent P-frames. The last activation step, dependency co-location, brings the ratio to 1.2×, so almost all P-frames complete in a single congestion-window round without queueing behind larger frames. Interleaving cuts P-frame P99 by 56% and reconfiguration avoidance cuts I-frame P99 by 58%, each on a frame type the other leaves unchanged, so both rules are needed to meet the interactive target.

(a)

700 550 400

338

250

367

445 360

334

332

128

150 ms target

100

Copa LeoCC MinRTTRound- BLESTRedund.MoMQ (WiFi) (Star.) Robin 400

Copa (WiFi)

542

LeoCC (Starlink)

(b)

480

MinRTT

695

Round-Robin 385

BLEST Redundant 114

MoMQ 0

394 median

200

400

P99

P99.9 600

Frame completion time (ms)

Figure 5: MoMQ against single-path and transport-only multipath baselines. (a) Minimum playback buffer with the 150 ms interactive target marked. (b) Frame completion time for all configurations as median, P99, and P99.9.

§A.6.1 tabulates each activation step, and a controlled simulation confirms that the contributions are statistically robust and near-additive, with all pairwise comparisons significant at 𝑝 < 0.001 (§A.6.2). To locate each rule’s effect, fig. 6 decomposes per-frame completion time by frame type across an extended measurement campaign. In fig. 6a, the three configurations that enable WiFi offloading show a distinct step near 8–14 ms, corresponding to P-frames routed via WiFi with a one-way delay of about 8 ms. The cost-sensitive default, which confines all traffic to Starlink, produces no such step and begins near 25 ms. The inset of fig. 6a magnifies the tail above P97, where the four configurations split into two clusters at P99.9. The

Path diversity and relay location. The evaluation so far uses the Germany relay. We vary the topology in two directions, increasing the relay distance and moving the subscriber to a site whose two paths converge, and find that distance leaves the gains intact while path diversity is indispensable. Both variations move exactly one endpoint of the multipath segment where MoMQ operates (§3), while the publisher and its single-path hop toward the relay stay fixed, so no new path elsewhere in the delivery chain can influence the comparison. We first move the relay to Finland, roughly 1 800 km from the subscriber and 2.5× the original distance, and verify with traceroute beforehand that the WiFi and Starlink paths do not share routers. The two paths remain distinct through separate transit networks all the way to the relay, with one-way delays of approximately 30 ms via WiFi and 50 ms via Starlink. We repeat the comparison against the two single-path baselines and BLEST, the strongest transport-only scheduler in table 2. MoMQ reduces P99.9 by 52–70%, needs less than half

Table 2: Frame completion time, playback buffer, and backuppath usage for the seven configurations through the Germany relay. Configuration

Med. (ms)

P99 (ms)

P99.9 (ms)

Buf. (ms)

Backup use

Copa / WiFi LeoCC / Starlink MPQUIC MinRTT MPQUIC Round-Robin MPQUIC BLEST MPQUIC Redundant MoMQ

25.2 32.6 25.9 31.8

235.0 258.4 284.6 345.2

399.8 541.7 479.5 694.9

338.5 367.6 360.2 445.3

100% 0% 89.7% 47.6%

24.8 25.1 28.2

225.1 229.7 85.6

384.7 394.5 114.1

332.4 334.2 127.9

91.8% 100% 11.3% 11

Conference’17, July 2017, Washington, DC, USA 100%

We then move the subscriber to western Canada, roughly 6 000 km from the relay, with the subscriber again connected via both Starlink and a terrestrial path. The relay stays in Germany, since relocating it near the subscriber would replace the upstream delivery path rather than stretch the subscriberto-relay segment whose path diversity is under test. The advantage nearly disappears. MoMQ improves on BLEST by only 5.0% in median FCT and 6.6% in median buffer, far below the roughly 70% reductions with the Germany relay. Table 11 in §A.7 aligns traces hop by hop and confirms that the two paths converge onto a shared backbone at Chicago, so the subscriber sees only one path to the relay. From there both paths follow the same backbone sequence through Newark, London, and Hamburg, and a repeated MPLS label on those hops supports a shared core segment. The traces rejoin inside the destination datacenter before the target host. Once traffic enters this shared long-haul segment, both paths experience nearly the same queueing and propagation conditions, so multipath scheduling has little leverage. Reconfiguration avoidance ( R2 ) contributes little because the shared core tail masks reconfiguration events, and P-frame interleaving ( R1 ) gains nothing when both paths deliver frames at comparable latencies. MoMQ’s rules assume path diversity that does not exist on this topology. Figure 7a tracks the median playback buffer of MoMQ and BLEST across the three topologies, where MoMQ stays near the interactive target through Germany and Finland and then converges with BLEST at Canada. Moving the relay from Germany to Finland raises P-frame medians by 55–94%, because added propagation delay has a larger relative effect on small, fast frames. I-frame medians, tails, and buffers rise far less, and MoMQ stays ahead on every metric in both locations. Figure 7b overlays the full FCT distributions for Finland and Canada. The Finland curves cross, where BLEST holds a slightly lower median and MoMQ a much shorter tail, whereas the Canada curves track each other through the body of the distribution once the paths converge. The gains survive a 2.5× increase in relay distance without rule changes and fall to 5–7% once the paths share a backbone, so path diversity, not relay proximity, is the deployment precondition.

(a)

tail (P97+)

100%

CDF

Shreedhar and Zhou et al.

99%

50%

P-frames via WiFi

98% 100

150

200

250

0% 0

50

100

150

200

250

CDF

100%

(b)

50% 6.7% of I-frames rerouted (R2) 0% 0

50

100

150

200

250

300

CDF

100%

(c) + Interleaving (R1) + Reconf Avoid. (R2) Cost-Sensitive (R4) Full MoMQ (+R3)

50%

0% 0

25

50

75

100

FCT (ms)

125

150

175

200

Figure 6: Frame completion time under incremental rule activation (250 runs and ≈750 000 frames per configuration). (a) All frames (P97 magnified). (b) I-frame FCT. (c) P-frame FCT.

the playback buffer of any baseline, and again leaves the metered path nearly idle at 9.3% (table 3). MoMQ finishes nearly all I-frames below 150 ms, while all three baselines extend to 400–550 ms (§A.6.3 shows the full distributions). The P-frame median of MoMQ again sits above BLEST, since bulk traffic stays on the flat-rate satellite path, whose one-way delay exceeds that of the metered path by 20 ms. The rule contributions reproduce as well. Interleaving ( R1 ) cuts the buffer from ≈284 ms under the cost-sensitive default to ≈235 ms, reconfiguration avoidance ( R2 ) brings it to ≈175 ms, and the full rule set reaches ≈164 ms. The policy carries over unmodified, since its rules reference metadata fields and path labels rather than absolute latency thresholds, and the configuration ranking is unchanged.

6

Table 3: Baseline comparison with the relay in Finland, at 2.5× the original relay distance. P-frame and I-frame medians are in ms. Configuration

PF med.

IF med.

P99.9 (ms)

Buf. (ms)

Backup use

Copa / WiFi LeoCC / Starlink MPQUIC BLEST MoMQ

34.3 53.5 33.7 45.1

142.3 186.6 132.9 95.9

364.5 450.2 275.3 132.4

396.6 440.1 371.5 164.3

100.0% 0.0% 84.3% 9.3%

DISCUSSION AND CONCLUSION

Multipath transport gives endpoints a choice of paths, and MoQT gives relays named Objects with metadata. We presented MoMQ, which connects the two by letting an application install declarative object-to-path mapping rules at the relay. The rules match metadata the relay never interprets and express delivery preferences against abstract path labels, so the relay acts on media semantics while containing no media logic. In a case study on SVC conferencing over Starlink and WiFi (§4), four rules built from two match operators 12

Media-over-Multipath-QUIC for Realtime Video Applications

400

MoMQ BLEST

425 372

332

300 200

164 128

Finland MoMQ Finland BLEST Canada MoMQ Canada BLEST

455

150 ms

FCT (ms)

Median buffer (ms)

500

300

150

Conference’17, July 2017, Washington, DC, USA

holds the same path diversity toward its first relay, so the rule interface could extend upstream to cover the delivery chain end to end. A subscriber whose access networks reach different relays would instead need rules that span relays, where path selection becomes relay selection. (v) MoMQ steers Objects the encoder has already produced and leaves the encoding unchanged. The path state a subscriber receives through PATH_STATE_REPORT messages could equally drive Track selection, so one control loop would carry both delivery steering and bitrate adaptation. The broadest extension is beyond video. The rule derivation of the case study (§4.1) applies wherever an application has heterogeneous data importance, inter-object dependencies, and cost-asymmetric paths. A cloud gaming service can mark frames rendered in response to player input, a conference bridge the current speaker’s Objects, and a live broadcast the featured camera’s feed. Each policy amounts to a label vocabulary and a few rules over the same five wire elements, and in each case the application supplies the domain knowledge while the relay learns none of it. This design opens the question of how many applications’ delivery policies become this small once the network offers a place to express them.

150 ms

100 0

0

Germany Finland

Canada

(700 km)

(6000 km)

(1800 km)

a) Median playback buffer

0%

50%

CDF

100%

b) Frame completion time

Figure 7: MoMQ against BLEST across relay and subscriber distance. (a) Median playback buffer at each location, with the 150 ms interactive target marked. (b) All-frame FCT distributions for the Finland and Canada topologies, where color marks location and line style marks configuration.

reduced P99.9 frame completion time from ≈385 ms under the best transport-only scheduler to ≈114 ms (§5.2). No other configuration met the 150 ms interactive budget. The same rules cut metered-path usage from ≈92% to ≈11%, and they retained their advantage without retuning at 2.5× the relay distance. The measured characterization of Starlink’s reconfiguration timing and duration (§4.1) also provides a reference for protocol work over LEO links. The results also mark the design’s boundaries, and each suggests an extension. (i) The gains require genuinely disjoint paths, since the advantage fell from ≈70% to ≈5% when the Canada subscriber’s paths converged onto a shared backbone. A subscriber cannot see such convergence from local interface state, so path-disjointness detection would let a relay decline rules that cannot improve delivery. (ii) MoMQ schedules only as well as the installed rules, which the relay validates syntactically rather than semantically. Nothing in the design, however, fixes where a rule set originates. A CDN operator could curate rule sets with its customers, a session could instantiate a rule set shipped as a transport add-on, or automated generation from application-declared objectives could remove the authoring burden. (iii) Relays are assumed cooperative. Advisory semantics accommodate benign deviation, where a relay overrides a rule under resource pressure, but the protocol neither detects nor prevents malicious deviation. The metadata and rules a relay receives also reveal the application’s encoding structure and the subscriber’s cost preferences. The evaluation is similarly bounded to one constellation, one SVC operating point, and a single subscriber per relay. Different codecs, constellations, and production loads would shift the value of individual rules, though not the interface that expresses them. (iv) MoMQ schedules only the subscriber’s last hop (§3), and it assumes both paths meet at a single relay. A mobile publisher, such as a news broadcast van uplinking over cellular and satellite,

REFERENCES [1] Jaya Allamsetty. 2024. AV1 and more. . . how does Jitsi Meet pick video codecs? Jitsi Blog, https://jitsi.org/blog/av1-and-more-how-does-jitsimeet-pick-video-codecs/. Accessed August 2026. [2] Venkat Arun and Hari Balakrishnan. 2018. Copa: Practical Delay-Based Congestion Control for the Internet. In 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’18). USENIX Association, Renton, WA, 329–342. [3] Florian Aschenbrenner, Tanya Shreedhar, Oliver Gasser, Nitinder Mohan, and Jörg Ott. 2021. From Single Lane to Highways: Analyzing the Adoption of Multipath TCP in the Internet. In 2021 IFIP Networking Conference (IFIP Networking). 1–9. doi:10.23919/ IFIPNetworking52078.2021.9472785 [4] Abdelhak Bentaleb, Bayan Taani, Ali C. Begen, Christian Timmerer, and Roger Zimmermann. 2019. A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP. IEEE Communications Surveys & Tutorials 21, 1 (2019), 562–585. doi:10.1109/ COMST.2018.2862938 [5] Steven Blake, David Black, Mark Carlson, Elwyn Davies, Zheng Wang, and Walter Weiss. 1998. An Architecture for Differentiated Services. RFC 2475. Internet Engineering Task Force. doi:10.17487/RFC2475 [6] Olivier Bonaventure, Christoph Paasch, and Gregory Detal. 2017. Use Cases and Operational Experience with Multipath TCP. RFC 8041. Internet Engineering Task Force. doi:10.17487/RFC8041 [7] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker. 2014. P4: Programming ProtocolIndependent Packet Processors. ACM SIGCOMM Computer Communication Review 44, 3 (2014), 87–95. doi:10.1145/2656877.2656890 [8] Neal Cardwell, Yuchung Cheng, Kevin Yang, David Morley, Soheil Hassas Yeganeh, Priyaranjan Jha, Yousuk Seung, Van Jacobson, Ian Swett, Bin Wu, and Victor Vasiliev. 2023. BBRv3: Algorithm Bug Fixes and Public Internet Deployment. IETF 117, Presentation to CCWG. 13

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

[9] Andreas Casparsen, Jonas Ellegaard Jakobsen, Jimmy Jessen Nielsen, Petar Popovski, and Israel Leyva-Mayorga. 2026. Statistical Characterization and Prediction of E2E Latency over LEO Satellite Networks. npj Wireless Technology 2 (2026), 36. doi:10.1038/s44459-026-00044-z Also arXiv:2601.08439. [10] Hendrik Cech, Patrick Bokelmann, and Nitinder Mohan. 2026. Tokens, Not Packets: Rethinking the Multipath QUIC Scheduling Interface. In Proceedings of the Applied Networking Research Workshop (ANRW). ACM, 140–146. doi:10.1145/3822163.3827925 [11] Hendrik Cech, Nitinder Mohan, and Jörg Ott. 2026. Dissecting the StarLink: Characterizing Queuing and Flow Dynamics in the Starlink Network. In Proceedings of the ACM SIGCOMM 2026 Conference. ACM. To appear. [12] Shubham Chaudhary, Navneet Mishra, Keshav Gambhir, Tanmay Rajore, Arani Bhattacharya, and Mukulika Maity. 2025. COMPACT: Content-aware Multipath Live Video Streaming for Online Classes using Video Tiles. In Proceedings of the 16th ACM Multimedia Systems Conference (MMSys). ACM, 201–213. doi:10.1145/3712676.3714451 [13] David D. Clark and David L. Tennenhouse. 1990. Architectural Considerations for a New Generation of Protocols. In Proceedings of the ACM SIGCOMM 1990 Conference. ACM, 200–208. doi:10.1145/99508.99553 [14] Cloudflare. 2026. An API for MoQ: Provision Your Own Isolated Relays. The Cloudflare Blog, https://blog.cloudflare.com/moq-relays/. Accessed August 2026. [15] Quentin De Coninck and Olivier Bonaventure. 2017. Multipath QUIC: Design and Evaluation. In Proceedings of the 13th International Conference on Emerging Networking Experiments and Technologies (CoNEXT ’17). ACM, 160–166. doi:10.1145/3143361.3143370 [16] Renan Dincer. 2025. MoQ: Refactoring the Internet’s Real-Time Media Stack. The Cloudflare Blog, https://blog.cloudflare.com/moq/. Accessed August 2026. [17] Mathis Engelbart, Mike Kosek, Lars Eggert, and Jörg Ott. 2025. From req/res to pub/sub: Exploring Media over QUIC Transport for DNS. In Proceedings of the 24th ACM Workshop on Hot Topics in Networks (HotNets). ACM, 419–426. doi:10.1145/3772356.3772416 [18] Simone Ferlin, Özgü Alay, Olivier Mehani, and Roksana Boreli. 2016. BLEST: Blocking Estimation-based MPTCP Scheduler for Heterogeneous Networks. In 2016 IFIP Networking Conference (Networking) and Workshops. IEEE, 431–439. doi:10.1109/IFIPNetworking.2016.7497206 [19] Sadjad Fouladi, John Emmons, Emre Orbay, Catherine Wu, Riad S. Wahby, and Keith Winstein. 2018. Salsify: Low-Latency Network Video through Tighter Integration between a Video Codec and a Transport Protocol. In 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’18). USENIX Association, 267–282. [20] Andrew C. Freeman. 2025. Toward Accessible and Safe Live Streaming Using Distributed Content Filtering with MoQ. In 2025 IEEE International Conference on Multimedia and Expo Workshops (ICMEW). IEEE, 1–6. doi:10.1109/ICMEW68306.2025.11152153 LIVES Workshop. [21] Alexander Frömmgen, Amr Rizk, Tobias Erbshäußer, Mira Weller, Boris Koldehofe, Alejandro Buchmann, and Ralf Steinmetz. 2017. A Programming Model for Application-Defined Multipath TCP Scheduling. In Proceedings of the 18th ACM/IFIP/USENIX Middleware Conference. ACM, 134–146. doi:10.1145/3135974.3135979 [22] Aashish Gottipati and Lili Qiu. 2025. Dynamic Pacing for Real-time Satellite Traffic. arXiv preprint. arXiv:2507.09798. [23] Sangtae Ha, Injong Rhee, and Lisong Xu. 2008. CUBIC: A New TCPFriendly High-Speed TCP Variant. ACM SIGOPS Operating Systems Review 42, 5 (July 2008), 64–74. doi:10.1145/1400097.1400105 [24] Bo Han, Feng Qian, Lusheng Ji, and Vijay Gopalakrishnan. 2016. MP-DASH: Adaptive Video Streaming Over Preference-Aware Multipath. In Proceedings of the 12th International Conference on Emerging Networking EXperiments and Technologies (CoNEXT). ACM, 129–143.

doi:10.1145/2999572.2999606 [25] Philipp Hancke. 2023. The Hidden AV1 Gift in Google Meet. webrtcHacks, https://webrtchacks.com/the-hidden-av1-gift-in-googlemeet/. Accessed August 2026. [26] ITU-T. 2003. One-Way Transmission Time. ITU-T Recommendation G.114. [27] Cullen Jennings, Suhas Nandakumar, and Richard Barnes. 2026. End-toEnd Secure Objects for Media over QUIC Transport. Internet-Draft draftietf-moq-secure-objects-01. Internet Engineering Task Force. Work in Progress. [28] Masahiro Kozuka and Yasuo Okabe. 2023. A Policy-Based Path Selection Mechanism in QUIC Multipath Extension. In 2023 IEEE 47th Annual Computers, Software, and Applications Conference (COMPSAC). IEEE, 1255–1259. doi:10.1109/COMPSAC57700.2023.00190 [29] Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Jihao Li, Xin Xie, Yuanjie Li, Jun Liu, and Jianping Wu. 2025. LeoCC: Making Internet Congestion Control Robust to LEO Satellite Dynamics. In Proceedings of the ACM SIGCOMM 2025 Conference. ACM, 129–146. doi:10.1145/ 3718958.3750491 [30] Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Weisen Liu, Yijie Liu, Xin Xie, Yuanjie Li, and Jun Liu. 2024. Mind the Misleading Effects of LEO Mobility on End-to-End Congestion Control. In Proceedings of the 23rd ACM Workshop on Hot Topics in Networks (HotNets). ACM, 34–42. doi:10.1145/3696348.3696867 [31] Goodsol Lee, Junhong Min, Seyeon Kim, Juheon Yi, Kwang Taik Kim, Mung Chiang, Sangtae Ha, Kyunghan Lee, and Saewoong Bahk. 2026. QCON: Seamless QoE-Aware 5G Streaming via Multi-Connectivity. In Proceedings of the 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI). USENIX Association. [32] Xianshang Lin, Yunfei Ma, Junshao Zhang, Yao Cui, Jing Li, Shi Bai, Ziyue Zhang, Dennis Cai, Hongqiang Harry Liu, and Ming Zhang. 2022. GSO-Simulcast: Global Stream Orchestration in Simulcast Video Conferencing Systems. In Proceedings of the ACM SIGCOMM 2022 Conference. ACM, 826–839. doi:10.1145/3544216.3544228 [33] Yanmei Liu, Yunfei Ma, Quentin De Coninck, Olivier Bonaventure, Christian Huitema, and Mirja Kühlewind. 2026. Managing Multiple Paths for a QUIC Connection. Internet-Draft draft-ietf-quic-multipath21. Internet Engineering Task Force. Work in Progress, RFC Editor Queue. [34] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. 2008. OpenFlow: Enabling Innovation in Campus Networks. ACM SIGCOMM Computer Communication Review 38, 2 (April 2008), 69–74. doi:10.1145/1355734.1355746 [35] Zili Meng, Yaning Guo, Chen Sun, Bo Wang, Justine Sherry, Hongqiang Harry Liu, and Mingwei Xu. 2022. Achieving Consistent Low Latency for Wireless Real-Time Communications with the Shortest Control Loop. In Proceedings of the ACM SIGCOMM 2022 Conference. ACM, 193–206. doi:10.1145/3544216.3544225 [36] Oliver Michel, Satadal Sengupta, Hyojoon Kim, Ravi Netravali, and Jennifer Rexford. 2025. Scalable Video Conferencing Using SDN Principles. In Proceedings of the ACM SIGCOMM 2025 Conference. ACM, 1213–1231. doi:10.1145/3718958.3750489 [37] Nitinder Mohan, Andrew E. Ferguson, Hendrik Cech, Rohan Bose, Prakita Rayyan Renatin, Mahesh K. Marina, and Jörg Ott. 2024. A Multifaceted Look at Starlink Performance. In Proceedings of the ACM Web Conference 2024 (WWW ’24). ACM, 2723–2734. doi:10.1145/ 3589334.3645328 [38] Suhas Nandakumar, Victor Vasiliev, Ian Swett, and Alan Frindell. 2026. Media over QUIC Transport. Internet-Draft draft-ietf-moq-transport-19. Internet Engineering Task Force. Work in Progress. 14

Media-over-Multipath-QUIC for Realtime Video Applications

Conference’17, July 2017, Washington, DC, USA

[39] Arvind Narayanan, Xumiao Zhang, Ruiyang Zhu, Ahmad Hassan, Shuowei Jin, Xiao Zhu, Xiaoxuan Zhang, Denis Rybkin, Zhengxuan Yang, Zhuoqing Morley Mao, Feng Qian, and Zhi-Li Zhang. 2021. A Variegated Look at 5G in the Wild: Performance, Power, and QoE Implications. In Proceedings of the ACM SIGCOMM 2021 Conference (SIGCOMM ’21). ACM, 610–625. doi:10.1145/3452296.3472923 [40] Felicián Németh, Zoltán Szatmáry, István Pelle, and Tamás Lévai. 2025. MoQ Resilience: Implicit Fast Failover. In Proceedings of the 3rd Workshop on Emerging Multimedia Systems (EMS). ACM, 61–63. doi:10.1145/3746441.3748235 [41] Erik Nygren, Ramesh K. Sitaraman, and Jennifer Sun. 2010. The Akamai Network: A Platform for High-Performance Internet Applications. ACM SIGOPS Operating Systems Review 44, 3 (2010), 2–19. doi:10.1145/ 1842733.1842736 [42] OpenMOQ Software Consortium. 2026. OpenMOQ Software Consortium. https://openmoq.org/. Accessed August 2026. [43] Christoph Paasch, Simone Ferlin, Özgü Alay, and Olivier Bonaventure. 2014. Experimental Evaluation of Multipath TCP Schedulers. In Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing (CSWS ’14). ACM, 27–32. doi:10.1145/2630088.2631977 [44] Jia Pan, Anup Agarwal, Işıl Dillig, and Venkat Arun. 2026. Syntra: Synthesizing Cross-Layer Controllers for Low-Latency Video Streaming. In Proceedings of the 23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI). USENIX Association. [45] Marcus Pieška, Andreas Kassler, Anna Brunstrom, Veselin Rakočević, and Markus Amend. 2024. Performance Impact of Nested Congestion Control on Transport-Layer Multipath Tunneling. Future Internet 16, 7 (2024), 233. doi:10.3390/fi16070233 [46] Alexander Rabitsch, Per Hurtig, and Anna Brunstrom. 2018. A StreamAware Multipath QUIC Scheduler for Heterogeneous Paths. In Proceedings of the Workshop on the Evolution, Performance, and Interoperability of QUIC (EPIQ). ACM, 29–35. doi:10.1145/3284850.3284855 [47] Costin Raiciu, Christoph Paasch, Sebastien Barre, Alan Ford, Michio Honda, Fabien Duchene, Olivier Bonaventure, and Mark Handley. 2012. How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP. In 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’12). USENIX Association, 399–412. [48] Alejandro Ramírez-Arroyo, O. S. Peñaherrera-Pulla, and Preben Mogensen. 2026. Toward Reliable Connectivity: Measurement-Driven Assessment of Starlink and OneWeb Non-Terrestrial and 5G Terrestrial Networks. IEEE Open Journal of the Communications Society 7 (2026), 3956–3973. doi:10.1109/OJCOMS.2026.3682548 [49] Jerome H. Saltzer, David P. Reed, and David D. Clark. 1984. End-to-End Arguments in System Design. ACM Transactions on Computer Systems 2, 4 (Nov. 1984), 277–288. doi:10.1145/357401.357402 [50] Sandesh Dhawaskar Sathyanarayana, Kyunghan Lee, Dirk Grunwald, and Sangtae Ha. 2023. Converge: QoE-driven Multipath Video Conferencing over WebRTC. In Proceedings of the ACM SIGCOMM 2023 Conference. ACM, 637–653. doi:10.1145/3603269.3604822 [51] Michael Scharf and Alan Ford. 2013. Multipath TCP (MPTCP) Application Interface Considerations. RFC 6897. Internet Engineering Task Force. doi:10.17487/RFC6897 [52] Heiko Schwarz, Detlev Marpe, and Thomas Wiegand. 2007. Overview of the Scalable Video Coding Extension of the H.264/AVC Standard. IEEE Transactions on Circuits and Systems for Video Technology 17, 9 (2007), 1103–1120. doi:10.1109/TCSVT.2007.905532 [53] Hang Shi, Yong Cui, Feng Qian, and Yuming Hu. 2019. DTP: Deadlineaware Transport Protocol. In Proceedings of the 3rd Asia-Pacific Workshop on Networking (APNet). ACM, 1–7. doi:10.1145/3343180.3343191 [54] Xiang Shi, Lin Wang, Fa Zhang, Biyu Zhou, and Zhiyong Liu. 2020. PStream: Priority-Based Stream Scheduling for Heterogeneous Paths

in Multipath-QUIC. In 2020 29th International Conference on Computer Communications and Networks (ICCCN). IEEE, 1–8. doi:10.1109/ ICCCN49398.2020.9209682 [55] Tanya Shreedhar, Nitinder Mohan, Sanjit K. Kaul, and Jussi Kangasharju. 2018. QAware: A Cross-Layer Approach to MPTCP Scheduling. In 2018 IFIP Networking Conference (IFIP Networking) and Workshops. IEEE, 1–9. doi:10.23919/IFIPNetworking.2018.8696843 [56] Varun Singh, Saba Ahsan, and Jörg Ott. 2013. MPRTP: Multipath Considerations for Real-time Media. In Proceedings of the 4th ACM Multimedia Systems Conference (MMSys). ACM, 190–201. doi:10.1145/ 2483977.2484002 [57] Yuhong Song, Changlong Li, and Qing Li. 2026. Consistency-Aware Multipath Transport (CAMP) toward Interactive Multimodal LLM-Based Systems. Internet-Draft draft-song-tsvwg-camp-00. Internet Engineering Task Force. Work in Progress. [58] Yeon sup Lim, Erich M. Nahum, Don Towsley, and Richard J. Gibbens. 2017. ECF: An MPTCP Path Scheduler to Manage Heterogeneous Paths. In Proceedings of the 13th International Conference on Emerging Networking Experiments and Technologies (CoNEXT ’17). ACM, 147–159. doi:10.1145/3143361.3143376 [59] Hammas Bin Tanveer, Mike Puchol, Rachee Singh, Antonio Bianchi, and Rishab Nithyanand. 2023. Making Sense of Constellations: Methodologies for Understanding Starlink’s Scheduling Algorithms. In Proceedings of the 2023 ACM Conference on Emerging Networking Experiments and Technologies (CoNEXT ’23) Companion. ACM, 37–43. doi:10.1145/3624354.3630586 [60] Tencent. 2026. TQUIC: A High-Performance, Lightweight, and CrossPlatform Library for the IETF QUIC Protocol. https://github.com/ Tencent/tquic. Accessed: 2026-08-07. [61] Lin Wang, Ze Wang, Zeyi Deng, Jingjing Zhang, and Yue Gao. 2026. ALCS: An Adaptive Latency Compensation Scheduler for Multipath TCP in Satellite-Terrestrial Integrated Networks. IEEE Transactions on Mobile Computing 25, 1 (2026), 660–673. doi:10.1109/ TMC.2025.3594896 [62] Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, and Ajay Luthra. 2003. Overview of the H.264/AVC Video Coding Standard. IEEE Transactions on Circuits and Systems for Video Technology 13, 7 (July 2003), 560–576. doi:10.1109/TCSVT.2003.815165 [63] Mo Zanaty, Espen Berger, and Suhas Nandakumar. 2025. Video Frame Marking RTP Header Extension. RFC 9626. Internet Engineering Task Force. doi:10.17487/RFC9626 [64] Zhilong Zheng, Yunfei Ma, Yanmei Liu, Furong Yang, Zhenyu Li, Yuanbo Zhang, Jiuhai Zhang, Wei Shi, Wentao Chen, Ding Li, Qing An, Hai Hong, Hongqiang Harry Liu, and Ming Zhang. 2021. XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services. In Proceedings of the ACM SIGCOMM 2021 Conference. ACM, 418–432. doi:10.1145/3452296.3472893 [65] Yuhan Zhou, Tingfeng Wang, Liying Wang, Nian Wen, Rui Han, Jing Wang, Chenglei Wu, Jiafeng Chen, Longwei Jiang, Shibo Wang, Honghao Liu, and Chenren Xu. 2024. AUGUR: Practical Mobile Multipath Transport Service for Low Tail Latency in Real-Time Streaming. In Proceedings of the 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI). USENIX Association, 1901–1916.

A SUPPLEMENTARY MATERIAL A.1 Encoding Parameters Table 4 gives the per-frame-type breakdown behind the size asymmetry of fig. 1, including the packet count each frame type occupies at the QUIC maximum datagram size used 15

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

Table 5: The five wire-level elements MoMQ adds to MoQT.

throughout the evaluation. An I-frame occupies 161 datagrams while no P-frame needs more than 11, so an I-frame spans several congestion-window rounds on either access link and every P-frame fits within one.

Element

Code

Purpose

ENABLE_MOMQ

0x10

Table 4: Typical frame sizes for 1080p SVC at 50 fps with QPbased quality differentiation (QP 18/26/42 for Layer 0/1/2).

PATH_MAPPING_RULE

0x50

Frame type

PATH_MAPPING_RESULT

0x51

PATH_STATE_REPORT

0x52

PATH_LABEL_UPDATE

0x53

Setup parameter sent by both endpoints to activate the extension Subscriber installs or removes a rule by identifier Relay accepts or rejects a rule operation Relay reports its paths, their status, and their labels Subscriber annotates a path with local knowledge

I-frame (IDR) Layer 0 P-frame Layer 1 P-frame Layer 2 P-frame

A.2

Size

Packets (1430 B)

Frequency

≈230 KB ≈15 KB ≈10 KB ≈8 KB

161 11 7 6

1 per GOP 12 per GOP 12 per GOP 25 per GOP

the preferences take effect without a further round trip once a second path is added. A MoMQ control message on a session that never negotiated the parameter is a protocol violation that closes the session. A PATH_MAPPING_RULE carries a rule identifier, an operation that is either INSTALL or REMOVE, a counted list of Match Entries, and a counted list of Action Entries. INSTALL creates a rule or replaces the rule with the same identifier, REMOVE deletes it, and the relay discards every rule when the session ends. A Match Entry is a key, one of the two operators of table 6, and a value, while an Action Entry is one of the four types of table 7 followed by a length and its parameters. Two operators keep the match language small enough that every relay supports the full matching capability at bounded forwarding-path cost. The length field lets a relay skip an action type it does not implement.

Object Format and Wire Elements MoQT Object

Track Alias

MoQT Object header Subgroup Group ID Object ID Priority ID MoMQ Object metadata

frame_type

temporal_layer

depends_on

Object payload media payload

Figure 8: Layout of a MoQT Object carrying MoMQ metadata, with the metadata block between the unchanged Object header and the payload.

Table 6: The two match operators.

Figure 8 shows where the metadata that rules match against sits inside a MoQT Object. The MoQT Object header is untouched, carrying the Track Alias, Group ID, Subgroup ID, Object ID, and publisher priority that the base protocol already defines. MoMQ adds one block between that header and the payload, holding the key-value pairs the publisher attaches when it creates the Object, such as frame_type, temporal_layer, and depends_on. Keys are UTF-8 strings and values are compared as opaque byte strings, so the relay reads this block for matching and never descends into the payload beneath it. Since matching never touches the payload, the media may stay encrypted end to end. Four such pairs add roughly 40–80 bytes to an Object whose payload spans 5–230 KB. Table 5 lists the five elements of §3 and their code points. Each message is a flat record of counted lists, and every field is a variable-length integer, a fixed-width code, or an opaque byte string, so a relay parses all five elements without interpreting a single application-supplied value. ENABLE_MOMQ is negotiated independently of multipath, so a subscriber can install rules while the session still runs on a single path, and

Value

Name

Semantics

0x00

EQUALS

0x01

EXISTS

Exact byte-for-byte match between the metadata value and the specified value The metadata key is present in the Object

Table 7: Action types for expressing delivery preferences. Type

Name

Description

0x01

PRIORITY

0x02

BALANCING

0x03

PATH_PREFERENCE

0x04

PATH_AFFINITY

Scheduling urgency, with higher values more urgent SINGLE_PATH or MULTI_PATH distribution Prefer paths whose labels match a key-value pair Co-locate with a previously forwarded Object

A PATH_STATE_REPORT carries a sequence number and a counted list of path entries, each holding a path identifier, a status that is ACTIVE, DEGRADED, or UNAVAILABLE, 16

Media-over-Multipath-QUIC for Realtime Video Applications

Conference’17, July 2017, Washington, DC, USA

A.3

88% ≤ 100 ms

median 58 ms

20 𝘯 = 𝟣𝟢𝟥  = 𝟥𝟣 ms IQR 49--81 ms

15 10 5 0 20

60

100

140

180

Reconfiguration duration (ms)

Figure 9: Starlink reconfiguration event durations across 103 events in 30 minutes of 1 ms-rate probing.

Recommended Relay Resource Limits

Table 8 gives concrete values for the per-session caps that §3 recommends. The caps exist because a subscriber that installs rules is an authenticated participant at the transport level yet a potential adversary at the scheduling level, so the relay bounds what one session can consume before rule state or evaluation cost becomes an attack vector. A multi-tenant relay additionally normalizes priorities across sessions, so one session’s priority escalation cannot starve another’s traffic.

A.5

Resource

Limit

Rationale

Rules per session

100

Match entries per rule

10

Actions per rule

20

Key length

128 bytes

Value length

1024 bytes

Installation rate

10 per second

An order of magnitude above the four-rule policy of §4.1 Bounds the metadata one match decision inspects Bounds the merge work per directive Keys are short identifiers Values may carry long identifiers Adapts rules to path changes, defeats flooding

Single-Path Congestion-Control Baselines

Figure 10 compares the congestion controllers of §5.2 on each link in isolation, so the single-path baselines of the headline comparison rest on the best controller for each link rather than an arbitrary one. On WiFi, Copa needs the lowest median playback buffer at 338.5 ms against 381.1 ms for BBRv3 and 410.8 ms for Cubic, and its FCT stays close behind at a 25.2 ms median and a 235.0 ms P99. On Starlink, LeoCC needs the lowest buffer at 367.6 ms against 397.3 ms for Copa, 452.9 ms for BBRv3, and 475.1 ms for Cubic, and it holds the shortest tail with a P99.9 FCT of 541.7 ms against 681.1 ms for the next best. The delay-based and LEO-aware controllers each win on their own link, so Copa carries the single-path WiFi baseline and LeoCC the single-path Starlink baseline throughout §5.

Table 8: Recommended per-session resource limits for a MoMQ relay.

A.4

25

Events

and that path’s labels. The sequence number is monotonic, so a subscriber drops any report older than the last one it processed. A PATH_LABEL_UPDATE carries a path identifier and a counted list of labels, each a key and a value. A subscriber-assigned label overrides a relay-assigned label with the same key, and subsequent reports echo it back. A PATH_MAPPING_RESULT carries the rule identifier it answers, one of five status codes, namely OK, REJECTED, NOT_AUTHORIZED, INVALID_RULE, and NOT_FOUND, and an optional reason string. A NOT_AUTHORIZED response deliberately carries no reason, so a subscriber cannot probe the relay’s authorization policy through error responses.

A.6

Reconfiguration Event Duration

Figure 9 gives the full duration distribution behind the boundedoutage claim of §4.1. Across 103 events, durations range from 22 ms to 172 ms with a median of 58 ms and an interquartile range of 49–81 ms. A 100 ms deferral window covers 88% of events, so anticipating a reconfiguration and briefly steering around it costs little. 17

Rule Ablation Detail

A.6.1 Incremental Activation on the Live Testbed. Incremental rule activation reveals complementary contributions (table 9). The cost-sensitive default ( R4 ) alone achieves a median buffer of 247.6 ms while using almost none of the backup path. Adding P-frame interleaving ( R1 ) reduces the buffer to 198.4 ms by relieving head-of-line blocking during multiround I-frame transmission. Adding reconfiguration avoidance ( R2 ) provides the largest single improvement, with the buffer at 151.9 ms and P99.9 dropping from 233.7 ms to 117.5 ms, as collisions between I-frames and reconfigurations are proactively eliminated. Dependency co-location ( R3 ) brings the buffer to 127.9 ms by eliminating cross-path reordering of enhancement-layer frames. Backup-path usage grows in step from 0.3% to 11.3%, because each rule sends the backup path exactly the traffic that benefits from it.

Conference’17, July 2017, Washington, DC, USA

Min. playback buffer (ms)

800

Shreedhar and Zhou et al.

The primary metric is the p1–p99 jitter buffer, the difference between the 99th and 1st percentiles of per-frame delivery deviation within each run, corresponding to the playback buffer needed to absorb 98% of frame-level timing variation. This metric is more robust to single-frame outliers than the minimum-maximum buffer used in the live evaluation, making it better suited to cross-run statistical comparison at scale.

WiFi Starlink

600 475

400

200

0

411

453 381

397 338

368

Table 10: Simulated playback buffer under rule removal (𝑛 = 250 runs per configuration).

150 ms

Cubic

BBRv3

Copa

Configuration

Median 𝜎 (ms) (ms)

MoMQ baseline w/o R3 (co-location) w/o R1 (interleaving) w/o R1 and R3

237.4 342.2 395.9 501.5

LeoCC

Figure 10: Minimum playback buffer per congestion controller on each link in isolation, grouped by controller. Solid boxes are WiFi and hatched boxes are Starlink, and LeoCC runs on Starlink only. Boxes span the interquartile range with the median printed inside, whiskers the 1.5 IQR extent, and diamonds individual outliers. The dashed line marks the 150 ms interactive target, and the Starlink outliers reach 1.3 s.

Buffer P99.9 FCT Backup (ms) (ms) use

Cost-sensitive default ( R4 ) + Interleaving ( R1 ) + Reconf. avoidance ( R2 ) + Dependency co-location ( R3 )

247.6 198.4 151.9 127.9

277.3 233.7 117.5 114.1

Cohen’s 𝑑

37.5 n/a 80.9 +44.3 72.6 +66.7 116.3 +111.6

n/a 1.77 2.97 3.09

With the baseline rule set, MoMQ achieves a median p1– p99 buffer of 237.4 ms (table 10). Removing dependency colocation increases the buffer by 44.3%, as enhancement-layer frames split across paths with asymmetric RTTs force the receiver to buffer early-arriving frames. Removing P-frame interleaving is more damaging at 66.7%, which confirms that the convoy effect from multi-round I-frame transmission dominates tail latency. Removing both yields a 111.6% increase, almost exactly the sum of the individual degradations, since 44.3 + 66.7 = 111.0. This near-additive behavior confirms that interleaving and co-location address independent problems with negligible interaction.

Table 9: Incremental rule activation on the live testbed. Rule set

Δ%

0.3% 6.2% 9.4% 11.3%

1.0

A.6.2 Controlled Simulation. The live testbed cannot isolate mechanisms under reproducible conditions, so we complement it with a controlled simulation that isolates the steadystate contributions of P-frame interleaving ( R1 ) and dependency co-location ( R3 ). Reconfiguration events are not modeled, so reconfiguration avoidance ( R2 ) is evaluated only on the live testbed, and the cost-sensitive default ( R4 ) remains fixed across all simulated configurations. The simulation models two asymmetric paths whose parameters are drawn from the testbed characterization in §2. The primary path has a base delay of 40 ms, delay jitter of 5 ms, packet loss of 0.2%, and capacity of 80 Mbps. The backup path has a base delay of 15 ms, delay jitter of 2 ms, packet loss of 0.1%, and capacity of 50 Mbps. SVC parameters match the live setup, with LeoCC on the satellite path and Cubic on the backup. Each of the 50 iterations executes five repetitions of four configurations in interleaved roundrobin order, generating 250 runs per configuration. The four configurations form a 2 × 2 factorial design around R1 and R3 .

CDF

0.8 0.6 0.4

MoMQ (all rules) w/o Rule 3 (co-location) w/o Rule 1 (interleaving) w/o Rules 1+3

0.2 0.0 100

200

300

400

500

600

700

800

p1--p99 jitter buffer (ms)

Figure 11: CDF of p1–p99 jitter buffer across 250 runs per configuration.

The CDF (fig. 11) shows four clearly separated distributions. The 95th percentile of the baseline at 303 ms falls below the 5th percentile of the configuration without R1 and R3 at 327 ms, so the two distributions overlap by less than 5%. Cohen’s 𝑑 confirms large effect sizes above 1.7 for all baseline comparisons, and pairwise win rates reinforce the ordering. 18

Media-over-Multipath-QUIC for Realtime Video Applications

Conference’17, July 2017, Washington, DC, USA 100%

MoMQ outperforms the variant without co-location in 90.0% of run-level comparisons, the variant without interleaving in 99.1%, and the variant without both in 99.3%.

CDF

(a)

tail (P90+)

100% 95%

50%

100

200

300

400

500

0%

MoMQ (all rules) w/o Rule 3 (co-location) w/o Rule 1 (interleaving) w/o Rules 1+3

0

100

200

300

400

100%

CDF

500

400

500

(b)

50%

0%

300

0

100

200

300

400

500

100%

10

20

30

40

50

CDF

Cumulative median of medians (ms)

90%

Number of iterations (cumulative)

0% 0

Figure 12 tracks the cumulative median-of-medians across iterations, where every estimate converges to within ±5 ms of its final value by roughly iteration 30 and remains stable through iteration 50. The four curves maintain consistent separation throughout, ruling out the possibility that the ordering is an artifact of finite sample size. Across 250 independent trials per configuration, interleaving contributes more than co-location, their effects are near-additive, and all pairwise comparisons are significant at 𝑝 < 0.001 with Cohen’s 𝑑 ≥ 1.77, so the rules address genuinely independent problems.

Hop Terr.

sea-b4-link sea-b1-link

6

12 13

terrestrial only interfaces differ

chi-bb2-link ewr-bb2 ldn-bb2 hbg-bb2 hbg-b2

7 8 9 10 11

14 15 16 17 18

identical identical identical identical identical

ic-383976 / -75 core22 / core21 core11 core spine

12 13 14 15

19 20 21 22

adjacent adjacent identical identical

40

60

80

FCT (ms)

100

120

140

A.6.3 Finland FCT Distributions. Figure 13 shows the full FCT distributions with the Finland relay, where the structural patterns of fig. 6 hold at 2.5× the relay distance. In fig. 13a and its tail inset, the four distributions rise together through the body and separate in the tail, where the MoMQ curve terminates before 200 ms while the three baselines stretch toward 550 ms. Figure 13b locates the separation in the Iframes, whose MoMQ curve sits left of every baseline across the whole distribution. Figure 13c shows the price, since Copa and BLEST deliver the median P-frame slightly earlier than MoMQ, consistent with the medians of table 3, yet the MoMQ P-frame distribution closes by roughly 70 ms while the baselines run past 100 ms.

Match

Starlink

20

Figure 13: FCT distributions with the Finland relay. (a) All frames, with the tail above P90 magnified in the inset. (b) Iframe FCT. (c) P-frame FCT.

Table 11: Hop alignment of the Starlink and terrestrial traceroutes from the Canada subscriber. Each row is one router with the hop at which each trace reaches it, and paired names give the Starlink and terrestrial unit where the traces hit adjacent equipment. Router

(c) MoMQ BLEST LeoCC (Star.) Copa (WiFi)

50%

Figure 12: Convergence of the cumulative median-ofmedians over 50 iterations.

600

A.7

Traceroute Alignment for the Canada Experiment

Table 11 aligns the raw hops of the two traceroutes behind the path-convergence analysis of §5.2, with hostnames shortened to their router identifiers. In the Seattle rows the traces reach the same router name on different interface addresses, 213.155.141.32 on the Starlink trace against 62.115.132.157 on the terrestrial one, and only the terrestrial trace passes sea-b4-link. From chi-bb2-link at 62.115.132.154 onward the hostnames and addresses are identical on both traces, and the bb2 hops expose the same MPLS label (415780) on both. The datacenter ingress rows differ only in adjacent equipment before the traces share core11 and the destination-side 19

Conference’17, July 2017, Washington, DC, USA

Shreedhar and Zhou et al.

spine router. Of the nine hops the Starlink trace takes from Chicago to the destination, seven reach the same router at

the same address as the terrestrial trace and the other two reach adjacent equipment.

20

Related documents

• LiveEdit: Towards Real-Time Diffusion-Based Streaming Video Editing#327586
• FlashDecoder: Real-Time Latent-to-Pixel Streaming Decoder with Transformers#373448
• LiveVLM: Efficient Online Video Understanding via Streaming-Oriented KV Cache and Retrieval#160885
• DA-Lion: Efficient Neural Video Representation via Direction-Aware Optimization#1048447
• ASTRA: Low-Overhead Runtime Architecture for STReam Adaptation in Video Analytics#997544