moq-subscriber-count: use a fire-and-forget message, not a parameter

Restructure the moq-transport extension from a Message Parameter on
SUBSCRIBE/REQUEST_UPDATE to a dedicated SUBSCRIBER_COUNT control
message on the subscription's request stream.

In moq-transport a REQUEST_UPDATE consumes a Request ID (Section 10.1)
and obliges the receiver to answer with REQUEST_OK/REQUEST_ERROR
(Section 10.9). Refreshing a once-per-second telemetry value through
it would be a request/response transaction whose stated purpose is to
modify the subscription -- a poor fit. The dedicated message rides the
existing request stream, consumes no Request ID, and elicits no
response. (Request ID exhaustion is not the concern: MAX_REQUEST_ID /
REQUESTS_BLOCKED were removed in -18.)

The asymmetry with moq-lite is deliberate: moq-lite's SUBSCRIBE_UPDATE
is already fire-and-forget (no response, no ID), so the field-based
design there is fine and is unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: kixelated

draft-lcurley-moq-subscriber-count.md

@@ -23,8 +23,9 @@ informative:
 
 --- abstract
 
-This document defines a Subscriber Count parameter for MoQ Transport {{moqt}}.
-The parameter carries the number of subscribers a subscription represents and telescopes up the relay fan-out tree, so a publisher can learn its total downstream audience across any number of relay hops by reading a single value on its upstream subscription.
+This document defines a SUBSCRIBER_COUNT message for MoQ Transport {{moqt}}.
+The message carries the number of subscribers a subscription represents and telescopes up the relay fan-out tree, so a publisher can learn its total downstream audience across any number of relay hops by reading a single value on its upstream subscription.
+It is a fire-and-forget telemetry message that consumes no Request ID and elicits no response.
 
 --- middle
 
@@ -37,14 +38,15 @@ A publisher in {{moqt}} often wants to know how many subscribers are receiving a
 This is straightforward when a subscriber connects directly, but {{moqt}} is designed around relays: a relay aggregates many downstream subscriptions for the same Track into a single upstream subscription toward the origin (its "fan-out" tree).
 The origin sees one upstream subscription per relay, not the individual subscribers behind it, so it cannot count its true audience without out-of-band coordination.
 
-This document defines a Subscriber Count parameter that rides on the subscription itself.
-Each subscription reports how many subscribers it represents.
+This document defines a SUBSCRIBER_COUNT message that reports, per subscription, how many subscribers it represents.
 A relay sets the count on its single upstream subscription to the **sum** of the counts of the downstream subscriptions it aggregates.
 Because the count is a sum reduced up the existing subscription tree, it telescopes for free: at the origin, the count on each upstream subscription is the total number of subscribers reachable through that relay, transitively, across any number of hops.
 
-The count is a property of the subscriber side of the subscription.
-In {{moqt}} a relay already merges subscriber-supplied parameters when it aggregates downstream subscriptions (subscriber properties fan *in*), so this parameter follows the existing aggregation path rather than introducing a new one.
-It changes as subscribers join and leave and is refreshed with REQUEST_UPDATE ({{moqt}} Section 10.9).
+The count changes as subscribers join and leave, so it is sent repeatedly over the life of a subscription.
+This is pure telemetry: the count never modifies the subscription, and the publisher only observes it.
+For that reason it is carried in a dedicated, fire-and-forget message rather than in REQUEST_UPDATE ({{moqt}} Section 10.9).
+A REQUEST_UPDATE consumes a Request ID ({{moqt}} Section 10.1) and obliges the receiver to answer with a REQUEST_OK or REQUEST_ERROR ({{moqt}} Section 10.9) — a request/response transaction whose purpose is to *modify* the subscription, which is a poor fit for a value pushed once per second that changes nothing.
+The SUBSCRIBER_COUNT message instead rides the subscription's existing request stream, consumes no Request ID, and elicits no response.
 
 
 # Setup Negotiation
@@ -60,63 +62,66 @@ SUBSCRIBER_COUNT Setup Option {
 ~~~
 
 The extension is available on a hop only if both endpoints on that hop included this option.
-The extension is negotiated independently on each hop: a relay MAY support it upstream but not downstream, or vice versa, and MUST NOT forward the parameter onto a hop that did not negotiate it.
+The extension is negotiated independently on each hop: a relay MAY support it upstream but not downstream, or vice versa.
 
-This extension only adds an optional parameter to existing messages, so a peer that receives the parameter without having negotiated the extension MUST ignore it rather than treating it as an error.
-Ignoring an un-negotiated count simply collapses that subscription's contribution to the default of `1` (see [Semantics](#semantics)); it does not break delivery.
+Negotiation is mandatory before the message is sent.
+{{moqt}} (Section 10) requires an endpoint that receives an unknown control message type to close the session, so — unlike an optional parameter, which can be ignored — a SUBSCRIBER_COUNT message cannot be sent speculatively.
+An endpoint MUST NOT send SUBSCRIBER_COUNT on a hop that did not negotiate this extension.
 
 
-# Subscriber Count Parameter
-This document defines a new parameter for use in the Parameters field of the SUBSCRIBE ({{moqt}} Section 10.7) and REQUEST_UPDATE ({{moqt}} Section 10.9) messages, encoded as a Key-Value-Pair ({{moqt}} Section 1.4.3).
+# SUBSCRIBER_COUNT Message
+This document defines a new control message, sent on a subscription's request stream ({{moqt}} Section 3.3) by the endpoint that opened it (the subscriber, which for an upstream subscription is the relay).
 
 ~~~
-SUBSCRIBER_COUNT Parameter {
-  Type (vi64) = 0xC0116
-  Value (vi64)              ; Subscriber Count - 1
+SUBSCRIBER_COUNT Message {
+  Type (vi64) = 0xC0117
+  Length (16)
+  Subscriber Count (vi64)   ; encoded as count - 1
 }
 ~~~
 
-The Type `0xC0116` is even, so per {{moqt}} Section 1.4.3 the Value is a single varint with no length prefix.
+The message MUST NOT be the first message on the request stream; it follows the SUBSCRIBE ({{moqt}} Section 10.7) that opened the stream.
+It consumes no Request ID ({{moqt}} Section 10.1), and the receiver MUST NOT respond to it.
+A subscriber MAY send it any number of times over the life of the subscription to refresh the count.
 
-**Value**:
+**Subscriber Count**:
 The number of subscribers this subscription represents, including the subscriber itself, encoded as the count minus one.
 The subscription is the implicit `1`, so the wire value is `Subscriber Count - 1`: a leaf encodes `0`, and a relay encodes its summed total minus one.
 
 Encoding `count - 1` rather than the count itself makes a count of `0` impossible to represent on the wire: the minimum encodable value is `0`, which decodes to a count of `1`.
 A subscription can never report fewer subscribers than itself.
 
-A subscriber MAY include this parameter in SUBSCRIBE and in any REQUEST_UPDATE.
-If the parameter is absent, the wire value is treated as `0`, so the count for that subscription is `1`.
-A leaf subscriber therefore reports `1`, whether by sending a wire value of `0` or by omitting the parameter.
+Until a SUBSCRIBER_COUNT message is received for a subscription, its count is `1`.
+A leaf subscriber that represents only itself therefore need not send the message at all.
 
 
 # Semantics
 The count is a reduction up the subscription tree.
 
 A **leaf subscriber** (one that is not a relay) represents itself: a count of `1`.
-It MAY omit the parameter to mean the same thing.
+It need not send the message to mean this.
 
-A **relay** that aggregates one or more downstream subscriptions for a Track into a single upstream subscription sets the SUBSCRIBER_COUNT on that upstream subscription to the **sum** of the counts of the downstream subscriptions, treating an absent downstream parameter as `1`.
-When a downstream count changes, or a downstream subscription is added or removed, the relay recomputes the sum and, if it changed, refreshes the upstream value with REQUEST_UPDATE.
+A **relay** that aggregates one or more downstream subscriptions for a Track into a single upstream subscription sets the count it reports on that upstream subscription to the **sum** of the counts of the downstream subscriptions, treating a downstream subscription that has not reported as `1`.
+When a downstream count changes, or a downstream subscription is added or removed, the relay recomputes the sum and, if it changed, sends a SUBSCRIBER_COUNT message upstream with the new total.
 
 A relay MUST report at least `1` for any upstream subscription it is holding open, even if it currently has no live downstream subscribers (for example, a subscription briefly retained for reuse).
 The `count - 1` encoding enforces this floor automatically: a sum of `0` still encodes a wire value of `0`, which decodes upstream as `1`.
 A held subscription cannot represent fewer subscribers than itself.
 
-Because each relay reports the sum of its subtree, the value telescopes: at the origin, the SUBSCRIBER_COUNT on a given upstream subscription is the total number of leaf subscribers reachable through that subscription, across any number of relay hops.
+Because each relay reports the sum of its subtree, the value telescopes: at the origin, the count on a given upstream subscription is the total number of leaf subscribers reachable through that subscription, across any number of relay hops.
 A publisher reads its total audience for a Track as the sum of the counts of the subscriptions it is serving.
 
-This parameter alters no delivery behavior.
+The message alters no delivery behavior.
 It MUST NOT influence prioritization, caching, congestion response, or any other distribution decision; it is informational telemetry carried alongside the subscription.
 
 
 # Rate Limiting
-Subscriber churn can change the count rapidly, and at a busy relay each change would otherwise produce an upstream REQUEST_UPDATE.
+Subscriber churn can change the count rapidly, and at a busy relay each change would otherwise produce an upstream SUBSCRIBER_COUNT message.
 
-A relay SHOULD rate-limit REQUEST_UPDATE messages whose only change is the SUBSCRIBER_COUNT, coalescing changes that occur within a short window (on the order of a second) and then forwarding the latest sum.
-Because the parameter carries the current count rather than a delta, a change that reverts within the window — a subscriber that joins and leaves, or leaves and returns — requires no upstream message at all.
+A relay SHOULD rate-limit SUBSCRIBER_COUNT messages per subscription, coalescing changes that occur within a short window (on the order of a second) and then sending the latest sum.
+Because the message carries the current count rather than a delta, a change that reverts within the window — a subscriber that joins and leaves, or leaves and returns — requires no upstream message at all.
 
-A relay MUST NOT coalesce a SUBSCRIBER_COUNT change with, or delay it behind, a REQUEST_UPDATE that also changes delivery-affecting fields; those are forwarded according to {{moqt}} without additional delay.
+Because the message is independent of REQUEST_UPDATE, this rate limiting never delays a genuine subscription change: delivery-affecting updates are forwarded according to {{moqt}} without regard to the count's window.
 
 
 # Security Considerations
@@ -133,7 +138,8 @@ A relay aggregates the values it receives but cannot attest to the honesty of it
 
 **Churn amplification.**
 A subscriber that rapidly joins and leaves could attempt to amplify control traffic toward the origin by forcing repeated count updates.
-The rate-limiting in [Rate Limiting](#rate-limiting) bounds this: the upstream message rate per subscription is capped regardless of downstream churn, and reverts within the window are suppressed entirely.
+The rate-limiting in [Rate Limiting](#rate-limiting) bounds this: the upstream SUBSCRIBER_COUNT rate per subscription is capped regardless of downstream churn, and reverts within the window are suppressed entirely.
+Because the message consumes no Request ID and elicits no response, this churn cannot exhaust an identifier space or force the origin into matching replies.
 
 This extension introduces no other security considerations beyond those described in {{moqt}}.
 
@@ -152,15 +158,17 @@ A high, distinctive value is chosen to avoid the low ranges reserved by {{moqt}}
 |:------|:-----|:----------|
 | 0xC0117 | SUBSCRIBER_COUNT | This Document |
 
-## MOQT Message Parameters
+## MOQT Message Types
 
-This document requests a registration in the "Message Parameters" registry ({{moqt}} Section 15.7).
-The value is **even** so that, per the Key-Value-Pair encoding ({{moqt}} Section 1.4.3), the count is carried as a single varint with no length prefix.
-A high, distinctive value is chosen to avoid the low ranges reserved by {{moqt}} and to minimize collisions with provisional registrations by other extensions; it also avoids the greasing pattern (`0x7f * N + 0x9D`).
+This document registers a control message type.
+{{moqt}} does not yet establish an IANA registry for message types, so this is a provisional codepoint pending such a registry; the value is chosen to be high and distinctive to avoid the low ranges {{moqt}} assigns and to minimize collisions with provisional registrations by other extensions, and it avoids the greasing pattern (`0x7f * N + 0x9D`).
+This is the same value as the SUBSCRIBER_COUNT Setup Option above; Setup Options and message types are independent namespaces, so the shared value is unambiguous.
 
-| Value | Name | Reference |
-|:------|:-----|:----------|
-| 0xC0116 | SUBSCRIBER_COUNT | This Document |
+The Stream column has the meaning defined by {{moqt}} Section 10: "Request" indicates the message is carried on a bidirectional request stream. The message is not marked "First": it never opens a request stream.
+
+| Value | Name | Stream | Reference |
+|:------|:-----|:-------|:----------|
+| 0xC0117 | SUBSCRIBER_COUNT | Request | This Document |
 
 
 --- back