moq-relay-hops: carry HOP_PATH on NAMESPACE via an extended Parameters field#48
Conversation
…pagate NAMESPACE (moqt Section 10.16), the message that delivers advertisements on a SUBSCRIBE_NAMESPACE response stream, has no Parameters field, so HOP_PATH had no way to travel the subscriber-driven relay path the extension targets. Define an extended NAMESPACE message that appends a Parameters field (gated on the RELAY_HOPS setup negotiation) and carry HOP_PATH there as well as on PUBLISH_NAMESPACE. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Sorry @kixelated, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis change updates the draft-lcurley-moq-relay-hops.md specification. It clarifies that both PUBLISH_NAMESPACE and NAMESPACE messages are treated as namespace advertisements, expands Setup Negotiation rules so negotiated sessions must carry HOP_PATH on both message types and honor EXCLUDE_HOP, and introduces a new section defining an extended NAMESPACE message format with an appended Parameters field. The MOQT Message Parameters registration table is updated to reflect where HOP_PATH and EXCLUDE_HOP are carried. Changes
Related issues: None specified. Related PRs: None specified. Suggested labels: documentation, spec-change Suggested reviewers: lcurley Poem A rabbit hops through session's gate, ✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Problem
The Relay Hops extension relies on namespace advertisements carrying a
HOP_PATHparameter as they propagate through a relay mesh. But in the subscriber-driven flow, advertisements propagate downstream as NAMESPACE messages (moqt Section 10.16) — the response toSUBSCRIBE_NAMESPACE— and that message has noParametersfield (onlyType,Length,Track Namespace Suffix). SoHOP_PATHhad nowhere to ride on the reactive path, which is exactly the relay-mesh scenario the extension targets.PUBLISH_NAMESPACE(0x6) andSUBSCRIBE_NAMESPACE(0x50) do carry aParametersfield, soHOP_PATHon the former andEXCLUDE_HOPon the latter were already fine.Fix
This extension now defines an extended NAMESPACE message that appends
Number of Parameters+Parametersafter the (self-delimiting)Track Namespace Suffix, used only on a session that negotiated Relay Hops.HOP_PATHis carried there as well as onPUBLISH_NAMESPACE.PUBLISH_NAMESPACEand reactiveNAMESPACEresponses).RELAY_HOPSnegotiation; relays includeHOP_PATHon everyPUBLISH_NAMESPACEandNAMESPACE. Graceful-degradation wording updated since a non-negotiating session omits the wholeParametersfield on NAMESPACE.PUBLISH_NAMESPACEor an extendedNAMESPACE.HOP_PATH"Carried In" updated toPUBLISH_NAMESPACE, NAMESPACE.EXCLUDE_HOPneeded no change.Extending a base-protocol message's wire format from an extension is safe here because it is gated on the per-session SETUP negotiation — both endpoints agree on whether NAMESPACE carries the trailing
Parametersfield before any NAMESPACE is sent.Draft builds cleanly (
kramdown-rfc ... OK,xml2rfc-txt ... OK).🤖 Generated with Claude Code