]> Nokia

yu.you@nokia.com

Nokia

serhan.guel@nokia.com

Networked Media

ali.begen@networked.media

Nokia

zaheduzzaman.sarker@nokia.com

Web and Internet Transport Media Over QUIC media over quic range filter moq moqt In Media over QUIC Transport (MOQT), subscribers can use Range Filters to select specific subgroups, objects, or priorities within a subscribed track. However, these subscription filters are static once established and can only be modified through explicit subscriber control signaling. This document proposes an extension to the Range Filter design that binds conditional evaluation logic directly to specific Range Filter sets. By introducing dynamic conditions to Range Filter configurations, a relay can autonomously adapt the intra-track forwarding behavior based on real-time network conditions, avoiding the round-trip delay of explicit subscriber update signaling. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Media over QUIC Transport (MOQT) supports subscription filters in SUBSCRIBE requests to indicate which objects within a track are to be forwarded. Range Filters allow subscribers to restrict delivery based on subgroup identifiers, object identifiers, publisher priorities, or specific metadata properties. However, current MOQT subscription filters are static once established. If a subscriber wishes to change the adaptation policy (e.g., dropping an enhancement subgroup due to network congestion), it requires a closed-loop procedure: detecting the throughput drop, computing a new filter, signaling via REQUEST_UPDATE, and waiting for the relay to apply it. This reaction delay introduces a risk of temporary overdelivery and queue build-up. This document extends Range Filters with conditional logic that allows relays to evaluate pre-authorized conditions and determine which SetIDs remain active at runtime. It defines a new RANGE_FILTER_CONDITION parameter that explicitly binds a specific Range Filter SetID to a condition. If the condition for a particular SetID is met, the relay keeps that SetID active in the Range Filter expression; otherwise, that SetID is ignored. This enables autonomous, relay-side intra-track adaptation without requiring further signaling from the subscriber.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Inline RANGE_FILTER_CONDITION Parameter The inline design for conditional filtering embeds all necessary algorithm configuration fields directly within a new message parameter, making it a self-contained solution for intra-track adaptation.

Relationship to Existing SetID Range Filters in MOQT (Section 5.1.3 of ) already define a SetID field (8 bits) within each filter parameter (SUBGROUP_FILTER, OBJECTID_FILTER, PRIORITY_FILTER, OBJECT_PROPERTY_FILTER, TRACK_PROPERTY_FILTER). Filter parameters sharing the same SetID are combined with logical AND, and different SetID groups are combined with logical OR. This document does not redefine SetID. RANGE_FILTER_CONDITION references an existing SetID value to bind conditional evaluation logic to a specific filter group that was already declared in the same message.

Parameter Definition To enable conditional functionality, this document introduces a new Message Parameter: RANGE_FILTER_CONDITION. This parameter applies conditional activation rules to an intra-track filter set identified by a SetID. The parameter MAY appear in SUBSCRIBE, PUBLISH_OK, or REQUEST_UPDATE messages. Multiple instances MAY be present, each referencing a different SetID. The same SetID MUST NOT appear in more than one RANGE_FILTER_CONDITION within the same message. The RANGE_FILTER_CONDITION parameter has the following wire format: The fields are defined as follows:

Set ID (8 bits):

Identifies the Range Filter set being made conditional. This value MUST match a SetID used in at least one Range Filter parameter in the same message. The field is 8 bits, consistent with the SetID encoding defined in MOQT Range Filters.

Algorithm ID (vi64):

Identifies the conditional evaluation algorithm to be used. This document defines Algorithm 0. Other algorithms MAY be defined in future specifications.

Throughput threshold (vi64):

Algorithm 0 specific. The minimum estimated downstream throughput in kbps required for the relay to keep this SetID active in the Range Filter OR-combination. When bandwidth is constrained, the relay determines which conditional SetIDs remain active according to the bandwidth allocation algorithm ().

Set throughput fraction (vi64):

Algorithm 0 specific. Relative weight for bandwidth allocation, expressed as an integer 1 <= N <= 10. Each conditional SetID receives bandwidth proportional to its fraction: target = B_total x fraction / sum_F. Fractions are relative weights, not absolute percentages. For example, fractions of 6, 4, 3 (sum_F = 13) allocate approximately 46%, 31%, and 23% respectively. This allows conditional SetIDs to be added or removed without requiring other conditional SetIDs to update their fractions.

Activate switching (vi64):

Controls whether conditional evaluation is active for this SetID. When set to 0, the relay ignores the conditional state for this SetID and includes it in the base MOQT OR-combination exactly as ordinary Range Filters do. When set to a non-zero value N, the relay activates condition-based admission for conditionally bound SetIDs as soon as at least N RANGE_FILTER_CONDITION entries for this subscription have been received. Activation takes effect at the next Group boundary.

Set rank (8 bits):

Degradation priority when estimated bandwidth is constrained, expressed as an 8-bit unsigned integer in the range 1-255. The default value is 1. Values of 0 and outside this range MUST result in a REQUEST_ERROR with error code INVALID_FILTER. Lower values indicate higher priority (protected from degradation). When bandwidth is sufficient, all conditional SetIDs remain active. When bandwidth is constrained, lower-priority conditional SetIDs (higher numeric rank) are deactivated first, while higher-priority conditional SetIDs maintain their target allocation.

Alternative 1: Reference Design The inline parameter design described in embeds all algorithm fields directly in RANGE_FILTER_CONDITION. This produces a self-contained parameter but duplicates the algorithm parameter structure that Sender-Side Track Switching (SSTS) defines in its SWITCHING-SET-ASSIGNMENT parameter, which has an identical set of fields (Algorithm ID, Throughput threshold, Set throughput fraction, Activate switching, Set rank). A more composable design separates the algorithm configuration from the filter binding. Under this design, a single common parameter "CONDITIONAL-SET-ASSIGNMENT" carries the algorithm fields and is shared by both intra-track conditional filtering and inter-track SSTS switching. RANGE_FILTER_CONDITION is then reduced to a binding that maps a Range Filter SetID to a Conditional set ID: CONDITIONAL-SET-ASSIGNMENT replaces the SWITCHING-SET-ASSIGNMENT parameter currently defined in SSTS. The fields and semantics are identical; only the name and scope change. For SSTS use, the subscriber assigns a subscription to a conditional set by including CONDITIONAL-SET-ASSIGNMENT in SUBSCRIBE or PUBLISH_OK, exactly as it would have used SWITCHING-SET-ASSIGNMENT. For intra-track conditional filtering, the subscriber additionally includes one RANGE_FILTER_CONDITION per SetID to bind each Range Filter group to a Conditional set ID. This design has the following properties:

• Algorithm parameters are defined once in CONDITIONAL-SET-ASSIGNMENT and shared across use cases. Multiple RANGE_FILTER_CONDITION entries can reference the same Conditional set ID if they share algorithm configuration, or different IDs if they require different thresholds or ranks.
• RANGE_FILTER_CONDITION becomes a lightweight binding with a fixed, minimal wire footprint (one 8-bit SetID and one varint).
• A single relay implementation handles both conditional intra-track filtering and inter-track SSTS switching through the same CONDITIONAL-SET-ASSIGNMENT evaluation logic.
• Future algorithms defined for SSTS are automatically available for conditional intra-track filtering without any changes to this specification.

The trade-off is that the subscriber must include two parameter types "CONDITIONAL-SET-ASSIGNMENT" and "RANGE_FILTER_CONDITION", rather than one, and the relay must correlate them. This is a minor implementation cost relative to the elimination of duplicated parameter definitions across two specifications.

Alternative 2: Self-Contained Design The reference-based design maps existing SetIDs to dynamic conditions. A second alternative is a self-contained design that introduces a new parameter, CONDITIONAL_FILTER_SET, which explicitly carries a list of alternative filter configurations for a single subscription. In this design, the relay interprets the provided configurations as mutually exclusive alternatives. The relay monitors the specified metric and autonomously selects and applies exactly one configuration from the set whose condition is satisfied.

Parameter Definition The CONDITIONAL_FILTER_SET parameter (Type 0x44) has the following structure:

• Set ID: Uniquely identifies the conditional filter set within the session scope, allowing it to be updated or removed via REQUEST_UPDATE.
• Switching Metric: Identifies the relay-observable metric used for selection, such as throughput (kbps), RTT (ms), or ECN marking rate.
• Switching Offset: Specifies the switching point. A value of 0 indicates an immediate "hard switch." A non-zero value indicates a "soft switch," where the new configuration is applied starting from a future Subgroup ID (Current ID + Offset).
• Configuration Count: The number of alternative filter configurations included in this set.

Each Configuration entry within the set defines a specific threshold and the filters to apply when active:

• Config ID: An identifier for the specific configuration within the set.
• Metric Threshold: The condition value for the selected Switching Metric. For throughput, the relay selects the configuration with the highest threshold that does not exceed the currently observed metric.
• Filter Parameters: A list of standard MOQT filter parameters (e.g., SUBGROUP_FILTER, OBJECTID_FILTER) to be applied when this configuration is active.

Unlike the OR-preserving design, this model uses set-replacement logic. If RTT is the metric and three configurations are defined with thresholds of 80ms, 150ms, and 250ms, the relay selects only the one that matches the current RTT range, stripping all other data

Summary of Design Alternatives This draft explores three distinct architectural approaches for conditional filtering.

1. Inline Design: Embeds algorithm parameters directly into a new message parameter that activates or deactivates existing Range Filter SetIDs based on real-time metrics.
2. Reference-Based Design: Reuses the common algorithm structure from SSTS by mapping standard Range Filter SetIDs to shared conditional logic configurations.
3. Self-Contained Design: Defines an independent parameter carrying an internal list of mutually exclusive filter profiles and their corresponding metric thresholds.

The Inline Design is suggested as the option requiring the least changes to the current MOQT specification. It functions as a purely additive message parameter that references existing SetID values already defined in the base protocol, thereby avoiding the need to modify existing parameters or reorganize the structures of other extensions like SSTS.

Relay Evaluation and Bandwidth Allocation Most of the text in this section is adapted from Sender-Side Track Switching for Media over QUIC Transport , specifically the "Bandwidth Allocation Algorithm" material at <https://github.com/wilaw/moq-transport/blob/patch-1/draft-ietf-moq-tran sport.md#bandwidth-allocation-allocation-algorithm>.

General Behavior With this parameter, the subscriber pre-authorizes the relay to autonomously adjust intra-track forwarding within the subscribed track. When RANGE_FILTER_CONDITION entries are present and activate switching is non-zero, the relay evaluates each conditionally bound SetID at each permitted switching point (Group boundary) and determines whether that SetID remains active. The relay then applies the standard MOQT OR-combination across all active conditional SetIDs together with any unconditional SetIDs. In other words, RANGE_FILTER_CONDITION changes whether a SetID participates in the OR expression; it does not change the meaning of SetID itself. When activate switching is 0 for all conditional SetIDs, or no RANGE_FILTER_CONDITION is present, the relay applies the standard MOQT Range Filter OR-combination behavior unchanged.

Algorithm 0: Throughput-Based Conditional Set Admission

Relay State The relay maintains the following state for each subscription that carries one or more RANGE_FILTER_CONDITION parameters with Algorithm ID 0:

• B_total: Estimated downstream bandwidth capacity for the subscriber connection. The relay MUST maintain a bandwidth estimate per downstream subscriber. The measurement interval SHOULD be at least the Group duration of the subscribed track. The estimate is obtained from the QUIC congestion control state (e.g., pacing rate, congestion window, smoothed RTT) and MAY be supplemented by external sources. The exact mechanism is implementation-specific.
• sum_F: Sum of all Set throughput fraction values across all registered RANGE_FILTER_CONDITION entries for this subscription. Updated when entries are added or removed.
• set.threshold: The Throughput threshold for each conditional SetID.
• set.fraction: The Set throughput fraction for each conditional SetID.
• set.rank: The Set rank for each conditional SetID.
• active_set_ids: The set of conditional SetIDs currently admitted into the MOQT OR-combination for this subscription.

Bandwidth Allocation Algorithm On a periodic update interval or at a minimum at each Group boundary, the relay executes the following algorithm to determine which conditional SetIDs remain active: The relay then forwards Objects that pass the Range Filters associated with any SetID in active_set_ids, combined using the standard MOQT OR semantics, together with any unconditional SetIDs. If no conditional SetID satisfies its threshold, the relay forwards only the unconditional SetIDs, if any. If the subscription contains no unconditional SetIDs, the relay MAY forward no Objects; this behavior SHOULD be documented by the relay implementation. The rank ordering ensures higher-priority conditional SetIDs (lower rank value) are admitted first. The use of reserved_bw makes admission monotonic: once a higher-priority conditional SetID has been admitted, lower-priority SetIDs are evaluated only against the bandwidth that remains after honoring those earlier admissions. Lower-priority conditional SetIDs therefore absorb any shortfall by being deactivated from the OR-combination.

Relay Procedure When the relay receives a subscription with one or more RANGE_FILTER_CONDITION parameters:

1. Register each conditional SetID and its associated Algorithm parameters.
2. Store B_total, sum_F, set.threshold, set.fraction, set.rank, and active_set_ids as subscription state.
3. If activate switching is non-zero and the number of registered RANGE_FILTER_CONDITION entries for this subscription is >= the activate switching value, begin active SetID admission by applying the bandwidth allocation algorithm () at the next Group boundary.

When a REQUEST_UPDATE is received:

• A RANGE_FILTER_CONDITION with Length = 0 removes the conditional state for the referenced SetID.
• A RANGE_FILTER_CONDITION with non-zero Length replaces the entire conditional state for the referenced SetID.
• Conditional SetIDs not referenced in REQUEST_UPDATE remain unchanged.

When the subscription is terminated (PUBLISH_DONE or cancellation), the relay removes all associated RANGE_FILTER_CONDITION state.

Example: OR-Preserving Conditional Layer Admission A subscriber receives a scalable video track containing three subgroups: Subgroup 0 (base layer), Subgroup 1 (enhancement layer 1), and Subgroup 2 (enhancement layer 2). The subscriber defines three SetID groups that remain OR-combined in the normal MOQT sense. The base layer is always included. Conditional evaluation determines which enhancement layers stay active at any given time.

Step 1: Define the Range Filters Using the standard MOQT SUBGROUP_FILTER parameter (SetID is 8 bits per MOQT Section 5.1.3):

• SUBGROUP_FILTER (SetID = 0): Range 0-0. Delivers the base layer. This SetID is unconditional.
• SUBGROUP_FILTER (SetID = 1): Range 1-1. Delivers enhancement layer 1.
• SUBGROUP_FILTER (SetID = 2): Range 2-2. Delivers enhancement layer 2.

Step 2: Bind Conditions with RANGE_FILTER_CONDITION (Algorithm 0) Activate switching = 2 means condition-based admission activates once both conditional RANGE_FILTER_CONDITION entries are registered. sum_F = 6 + 4 = 10.

Result The relay applies the bandwidth allocation algorithm at each Group boundary:

• B_total = 7000 kbps: SetID=1 is allocated 7000 * 6 / 10 = 4200, which satisfies its 2000 kbps threshold. The remaining budget is 5000 kbps. SetID=2 is then allocated 7000 * 4 / 10 = 2800, which satisfies its 2500 kbps threshold. The relay therefore forwards SetID 0, SetID 1, and SetID 2.

Note: The subscriber should set fractions and thresholds such that, at the expected B_total, each desired layer's threshold is within its allocated fraction. The example above illustrates the mechanics; real deployments may calibrate threshold and fraction values so the intended set of layers remains active at expected bandwidth levels. In a typical deployment:

• B_total = 7000 kbps: The relay keeps SetID=1 and SetID=2 active. Combined with unconditional SetID=0, subgroups 0, 1, and 2 are forwarded.
• B_total = 4000 kbps: The relay keeps SetID=1 active but not SetID=2. Combined with unconditional SetID=0, subgroups 0 and 1 are forwarded.
• B_total = 1500 kbps: No conditional enhancement SetID is admitted. The relay still forwards the unconditional base layer in SetID=0.

By structuring the SetIDs as independently admitted OR terms evaluated against bandwidth thresholds, the subscriber eliminates round-trip signaling delays while preserving the existing SetID combination semantics.

Call flow

1. A typical SUBSCRIBE workflow for conditional range-filter evaluation.
2. A publisher-initiated subscription workflow based on SUBSCRIBE_TRACKS and Namespace Prefix Matching.
3. A publisher-initiated subscription workflow where RANGE_FILTER_CONDITION is carried in PUBLISH_OK.

Typical SUBSCRIBE workflow | | | | SUBSCRIBE_OK | |<---------------------------------------------| | | | +-----------------------------+ | | 1. Measure B_total | | | 2. Evaluate Conditions | | | 3. Admit Active SetIDs | | +-----------------------------+ | | | Forward Objects (Active SetIDs) | |<=============================================| | | ~ Bandwidth Fluctuates ~ | | | +-----------------------------+ | | Group Boundary Re-eval: | | | Update active SetIDs | | +-----------------------------+ | | | Forward Objects (Updated Active SetIDs) | | (w/ PRIOR_SUBGROUP_ID_GAP if skipped) | |<=============================================| | | ]]>

• Initial setup: The subscriber sends SUBSCRIBE with multiple SetID groups (using standard Range Filters) and binds them using RANGE_FILTER_CONDITION.
• Continuous evaluation: The relay autonomously executes the evaluation loop (measuring throughput, comparing thresholds, and admitting or deactivating conditional SetIDs).
• Dynamic adaptation: At the next group boundary, the relay can deactivate lower-priority conditional SetIDs and, when subgroups are skipped, uses PRIOR_SUBGROUP_ID_GAP to make intentional omissions explicit.

Standard Publisher-initiated SUBSCRIBE_TRACKS workflow (V19) The following call flow illustrates a publisher-initiated subscription workflow based on SUBSCRIBE_TRACKS and Namespace Prefix Matching. | | | | Namespace Prefix Matching | | | against authorized tracks | | |--------------------------->| | |<---------------------------| | | Matched Track List | | | | | | PUBLISH (Track A) | |<==============================|============================| | PUBLISH_OK (or REQUEST_OK) | | |==============================>|============================| | | PUBLISH (Track B) | |<==============================|============================| | PUBLISH_OK (or REQUEST_OK) | | |==============================>|============================| | | | |<==== Objects (Filtered) ======|============================| | (with PRIOR_GAP prop) | | ]]>

• Discovery and matching: The subscriber requests a Track Namespace Prefix on a bidirectional stream using SUBSCRIBE_TRACKS. The relay or publisher performs Namespace Prefix Matching across known authorized tracks.
• Publisher-initiated delivery: For each matched track, the publisher (directly or through the relay) initiates a new stream and sends PUBLISH. The subscriber accepts each stream with PUBLISH_OK (or REQUEST_OK), establishing the subscription.
• Filter refinement: In this workflow, SUBSCRIBE_TRACKS MAY carry optional Range Filter and/or Conditional Filter parameters to limit delivered objects, either statically (fixed ranges) or dynamically (runtime condition evaluation).

Publisher-initiated workflow with RANGE_FILTER_CONDITION The following call flow illustrates a publisher-initiated workflow where the subscriber returns RANGE_FILTER_CONDITION in PUBLISH_OK. | | | | Namespace Prefix Matching | | | against authorized tracks | | |--------------------------->| | |<---------------------------| | | Matched Track List | | | | | | PUBLISH (Track A) | |<==============================|============================| | PUBLISH_OK | | | + RANGE_FILTER_CONDITION | | |==============================>|============================| | | Apply returned conditions | | | before forwarding objects | |<==== Objects (filtered) ==================================>| | | | | | PUBLISH (Track B) | |<==============================|============================| | PUBLISH_OK | | | + RANGE_FILTER_CONDITION | | |==============================>|============================| | | Apply returned conditions | | | before forwarding objects | |<==== Objects (filtered) ==================================>| | | | ]]>

• No filter parameters in SUBSCRIBE_TRACKS: The subscriber requests only a Track Namespace Prefix.
• Condition conveyed in acceptance: For each received PUBLISH stream, the subscriber responds with PUBLISH_OK carrying RANGE_FILTER_CONDITION.
• Per-track activation: The relay applies the returned conditions to that accepted stream and forwards only objects that satisfy the resulting active SetID combination.

Design Rationale

OR-Preserving Admission Versus Set Replacement Two high-level designs are possible for conditional intra-track filtering. In a set-replacement design, the relay interprets conditional SetIDs as mutually exclusive alternatives and selects exactly one active SetID. That model can be convenient for layered examples, but it changes the base MOQT meaning of SetID because SetIDs no longer behave as OR-combined filter groups once conditional logic is enabled. The inline design instead uses an OR-preserving admission design. Under this model, conditional logic determines only whether a SetID participates in the existing OR expression at a given switching point. The AND semantics within a SetID and the OR semantics across SetIDs remain unchanged. This preserves compatibility with existing Range Filter processing, avoids introducing a special-case interpretation of SetID, and lets unconditional and conditional SetIDs coexist naturally in the same subscription. The main trade-off is that subscribers describe adaptation as incremental admission or removal of OR terms, rather than as a single explicit "current SetID". That requires examples and algorithms to be phrased in terms of active SetID combinations. This document prefers that trade-off because it keeps the extension additive and avoids redefining core MOQT Range Filter behavior.

Alternative: Embedding Conditions in Existing Range Filter Parameters An alternative design would embed the conditional evaluation fields (Algorithm ID, Throughput threshold, Set throughput fraction, Activate switching, Set rank) directly into the existing Range Filter parameters SUBGROUP_FILTER, OBJECTID_FILTER, PRIORITY_FILTER, OBJECT_PROPERTY_FILTER, and TRACK_PROPERTY_FILTER, rather than introducing a separate RANGE_FILTER_CONDITION parameter. Under this approach, a subscriber would signal the condition inline with the filter that it governs, for example: This approach is not adopted for the following reasons. SetID is a grouping mechanism, not a per-filter attribute. A single SetID typically comprises multiple Range Filter parameters that are AND-combined (e.g., a SUBGROUP_FILTER and an OBJECTID_FILTER with the same SetID). The conditional activation logic applies to the entire SetID group, not to any individual filter within it. Embedding condition fields in each Range Filter parameter would require either repeating the fields identically across every parameter sharing the same SetID, or designating one parameter as the canonical carrier while others are implicitly governed by it. Both approaches introduce ambiguity and implementation complexity without benefit. Modifying base MOQT parameters raises the change bar. SUBGROUP_FILTER and related parameters are defined and registered in the MOQT base specification (, Section 15.7). Extending their wire format would require a change to or an update of that specification rather than a new parameter registration. A standalone parameter type, by contrast, is a purely additive change. Separation of concerns is architecturally preferable. Range Filter parameters define the content selection criterion (which subgroup IDs, object IDs, priorities, or property values pass). The RANGE_FILTER_CONDITION parameter defines the activation condition (under what network state the SetID is active). Keeping these concerns in separate parameters preserves the ability to use Range Filters independently of any conditional logic, and allows future algorithms to be introduced without touching the base filter format. For these reasons, RANGE_FILTER_CONDITION is defined as a standalone parameter that references an existing SetID by value.

Handling Filtered Subgroups: Prior Subgroup ID Gap When a relay dynamically filters out a subgroup due to network conditions, a subscriber receiving the stream might notice a numerical leap in Group IDs or Object IDs. To explicitly communicate that these missing objects were intentionally skipped by a conditional filter rather than lost to network congestion, we propose a new PRIOR_SUBGROUP_ID_GAP Object Property.

• Prior Subgroup ID Gap (Property Type: 0x3F): A variable-length integer containing the number of Subgroups prior to the current Subgroup ID (within the current Group) that do not and will never exist because they were conditionally filtered out.

If a relay drops Subgroup 1 but continues forwarding Subgroup 0 and Subgroup 2, it injects PRIOR_SUBGROUP_ID_GAP = 1 into the first Object of Subgroup 2. Relays MUST be permitted to modify this specific gap property to support dynamic conditional filtering.

Extension negotiation Per Section 10.3 of , the SETUP message allows endpoints to agree on the initial configuration before any other control messages are exchanged. Extensions that modify control message semantics, such as RANGE_FILTER_CONDITION, MUST be negotiated through Setup Options before use. The Setup Options defined in this section are intended for the inline design of this extension. Alternative designs, such as the reference-based design () or the self-contained design (), may instead rely on Setup Options defined in the Sender-Side Track Switching (SSTS) extension or require different identifiers for their respective parameters. This document defines two new Setup Options: RANGE_FILTER_CONDITION and MAX_CONDITIONAL_FILTERS.

RANGE_FILTER_CONDITION (Type 0x09):

Declares support for the RANGE_FILTER_CONDITION message parameter defined in . The value is a variable-length integer identifying the version of the conditional filtering algorithm set the endpoint is willing to use. The value indicates the highest Algorithm ID the endpoint is capable of evaluating. An endpoint that includes this option can process RANGE_FILTER_CONDITION parameters for any Algorithm ID up to and including the advertised value. If not present, the endpoint does not support this extension.

MAX_CONDITIONAL_FILTERS (Type 0x0A):

Limits the peer's total number of RANGE_FILTER_CONDITION parameters allowed concurrently for a given subscription or fetch. The default value is 0, so if not specified, the peer MUST NOT send any RANGE_FILTER_CONDITION parameters. If this limit is exceeded, an endpoint MUST reject this with REQUEST_ERROR with error code INVALID_FILTER.

An endpoint that wishes to send RANGE_FILTER_CONDITION parameters MUST verify that the peer's SETUP message includes a RANGE_FILTER_CONDITION Setup Option with a value greater than or equal to the Algorithm ID it intends to use, and a MAX_CONDITIONAL_FILTERS value greater than zero. Because RANGE_FILTER_CONDITION binds to Range Filter SetIDs, an endpoint that sends RANGE_FILTER_CONDITION MUST also ensure that the MAX_FILTER_RANGES Setup Option (Section 10.3.1.6 of ) has been negotiated with a non-zero value; otherwise Range Filters themselves would not be permitted and the referenced SetIDs could not be established. Endpoints that do not support this extension will not include the RANGE_FILTER_CONDITION Setup Option in their SETUP message. As required by Section 10.3 of , endpoints MUST ignore unknown Setup Options, so a peer that receives these options from an endpoint that does not recognize them simply ignores them and does not send RANGE_FILTER_CONDITION parameters in that session.

Security Considerations This extension relies on the existing security framework of MOQT. Conditional filter evaluation must be computationally lightweight to prevent denial-of-service attacks against relays. A malicious subscriber could attempt to overwhelm a relay with highly complex RANGE_FILTER_CONDITION thresholds or excessive conditional SetIDs. Relays SHOULD implement rate limiting on the maximum number of conditionally bound SetIDs a subscriber can declare in a single session.

IANA Considerations

• A new Setup Option Type for RANGE_FILTER_CONDITION (suggested value: 0x09) in the "MOQ Setup Options" registry (Section 15.4 of ), with Specification Required policy.
• A new Setup Option Type for MAX_CONDITIONAL_FILTERS (suggested value: 0x0A) in the "MOQ Setup Options" registry (Section 15.4 of ), with Specification Required policy.
• A new Message Parameter Type for RANGE_FILTER_CONDITION in the "MOQT Message Parameters" registry.
• A new Object Property Type for PRIOR_SUBGROUP_ID_GAP (suggested value: 0x3F) in the "MOQ Properties" registry.

References Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d.

Acknowledgments IETF MOQ Working Group.