A publisher's priority intent does not survive a relay hop. Three separate places contribute, and
they combine so that both an explicitly-stamped priority and a declared default are lost.
1. The serve path hardcodes zero. rs/moq-net/src/ietf/publisher.rs:813 builds the outgoing
group header with:
let msg = ietf::GroupHeader {
track_alias: request_id.0,
group_id: sequence,
sub_group_id: 0,
publisher_priority: 0,
...
This is the only non-test occurrence in the file (the others are all inside #[cfg(test)]), so
whatever priority arrived upstream is replaced with 0 on the way downstream.
2. DEFAULT_PUBLISHER_PRIORITY (0x21) is never parsed. rs/moq-net/src/ietf/properties.rs
implements only TIMESCALE (0x08) and DEFAULT_PUBLISHER_GROUP_ORDER (0x22), so a publisher that
declares a default has it silently dropped.
3. An absent priority flag decodes to a hardcoded 128. rs/moq-net/src/ietf/group.rs:333:
} else {
128 // Default priority when absent
};
rather than the track's declared default.
Why it matters: the use case driving this for us is linear SSAI — audio needs to sit ahead of
every video rendition so it survives congestion that video doesn't. Today that intent is flattened
at the relay, and notably it is flattened even if the publisher pays the per-subgroup byte to stamp
priority explicitly, because of (1).
Context: priority preservation is now a requirement in the moqtest conformance suite — the MoQ
WG interop wiki calls out moqt-nr for not preserving "publisher priority, which is now a
requirement for all conformance tests" — and aiomoqt recently fixed the equivalent forwarding path
on their relay. Found while checking our own relay (stock moq-dev) during the 2026-09-02 draft-18
virtual interop.
Scope note: this is independent of the moq-transport #1770 discussion about whether the default
should be mutable. Regardless of how that lands, whatever priority is in effect should survive the
forward path.
Verified against origin/main today; line numbers are from there.
A publisher's priority intent does not survive a relay hop. Three separate places contribute, and
they combine so that both an explicitly-stamped priority and a declared default are lost.
1. The serve path hardcodes zero.
rs/moq-net/src/ietf/publisher.rs:813builds the outgoinggroup header with:
This is the only non-test occurrence in the file (the others are all inside
#[cfg(test)]), sowhatever priority arrived upstream is replaced with
0on the way downstream.2.
DEFAULT_PUBLISHER_PRIORITY(0x21) is never parsed.rs/moq-net/src/ietf/properties.rsimplements only
TIMESCALE(0x08) andDEFAULT_PUBLISHER_GROUP_ORDER(0x22), so a publisher thatdeclares a default has it silently dropped.
3. An absent priority flag decodes to a hardcoded 128.
rs/moq-net/src/ietf/group.rs:333:rather than the track's declared default.
Why it matters: the use case driving this for us is linear SSAI — audio needs to sit ahead of
every video rendition so it survives congestion that video doesn't. Today that intent is flattened
at the relay, and notably it is flattened even if the publisher pays the per-subgroup byte to stamp
priority explicitly, because of (1).
Context: priority preservation is now a requirement in the moqtest conformance suite — the MoQ
WG interop wiki calls out moqt-nr for not preserving "publisher priority, which is now a
requirement for all conformance tests" — and aiomoqt recently fixed the equivalent forwarding path
on their relay. Found while checking our own relay (stock moq-dev) during the 2026-09-02 draft-18
virtual interop.
Scope note: this is independent of the moq-transport #1770 discussion about whether the default
should be mutable. Regardless of how that lands, whatever priority is in effect should survive the
forward path.
Verified against
origin/maintoday; line numbers are from there.