Problem
moq-lite marks the end of a subscriber's initial announce set: ANNOUNCE_INIT on lite-01/02, and ANNOUNCE_OK's Active Count on lite-05+. A subscriber can therefore tell "the publisher has told me everything it currently has" apart from "the publisher has told me nothing yet".
moq-transport has no counterpart. SUBSCRIBE_NAMESPACE is acknowledged by REQUEST_OK, but that only says the request was accepted; the NAMESPACE entries follow it on the stream with nothing marking how many there are or when the initial batch ends. moq-lite-03/04 have the same gap for the same reason (ANNOUNCE_OK arrived in lite-05).
Why it matters
Anything that needs to conclude "this path is not announced" has to guess. Concretely, in #2762 origin::Consumer::request_broadcast waits for the initial announce set before falling through to the dynamic handler (or Unroutable), which is race-free on lite-01/02 and lite-05+ and unavoidably racy on moq-transport and lite-03/04: the request can conclude before an announcement that was already in flight. That PR documents the limitation rather than pretending otherwise, and the affected cross-version test asserts resolution only on the versions with a boundary.
The same gap will constrain announce-only entries (#2756) and dynamic announce interest (#2610) on the IETF path, where "the peer has nothing at this prefix" is the answer a handler needs.
Options
- An IETF extension parameter carrying an initial-namespace count, mirroring ANNOUNCE_OK's
Active Count. Fits alongside the existing MoQ Cluster extension (draft-lcurley-moq-cluster), which already negotiates relay-specific behavior on the moq-transport wire.
- Or an explicit end-of-initial-set marker message, which is more wire but does not require the publisher to know the count up front.
Either is a spec change, so it belongs in a draft PR rather than a code one. Filed from the adversarial review of #2762 (both Codex and the Codex PR-review bot flagged the ordering; the underlying cause is that there is no boundary to order against).
(written by Fable 5)
Problem
moq-lite marks the end of a subscriber's initial announce set: ANNOUNCE_INIT on lite-01/02, and ANNOUNCE_OK's
Active Counton lite-05+. A subscriber can therefore tell "the publisher has told me everything it currently has" apart from "the publisher has told me nothing yet".moq-transport has no counterpart. SUBSCRIBE_NAMESPACE is acknowledged by REQUEST_OK, but that only says the request was accepted; the NAMESPACE entries follow it on the stream with nothing marking how many there are or when the initial batch ends. moq-lite-03/04 have the same gap for the same reason (ANNOUNCE_OK arrived in lite-05).
Why it matters
Anything that needs to conclude "this path is not announced" has to guess. Concretely, in #2762
origin::Consumer::request_broadcastwaits for the initial announce set before falling through to the dynamic handler (orUnroutable), which is race-free on lite-01/02 and lite-05+ and unavoidably racy on moq-transport and lite-03/04: the request can conclude before an announcement that was already in flight. That PR documents the limitation rather than pretending otherwise, and the affected cross-version test asserts resolution only on the versions with a boundary.The same gap will constrain announce-only entries (#2756) and dynamic announce interest (#2610) on the IETF path, where "the peer has nothing at this prefix" is the answer a handler needs.
Options
Active Count. Fits alongside the existing MoQ Cluster extension (draft-lcurley-moq-cluster), which already negotiates relay-specific behavior on the moq-transport wire.Either is a spec change, so it belongs in a draft PR rather than a code one. Filed from the adversarial review of #2762 (both Codex and the Codex PR-review bot flagged the ordering; the underlying cause is that there is no boundary to order against).
(written by Fable 5)