Conditional Range Filters for Media over QUIC Transport

3.1. Relationship to Existing SetID

Range Filters in MOQT (Section 5.1.3 of [I-D.ietf-moq-transport]) 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.¶

3.2. 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:¶

RANGE_FILTER_CONDITION {
  Set ID (8),
  Algorithm ID (vi64),
  Throughput threshold (vi64),
  Set throughput fraction (vi64),
  Activate switching (vi64),
  Set rank (8)
}

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 (Section 4.2.2).¶

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.¶

3.3. Alternative 1: Reference Design

The inline parameter design described in Section 3.2 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) [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 {
  Conditional set ID (vi64),
  Algorithm ID (vi64),
  Throughput threshold (vi64),
  Set throughput fraction (vi64),
  Activate switching (vi64),
  Set rank (8)
}

RANGE_FILTER_CONDITION {
  Set ID (8),
  Conditional set ID (vi64)
}

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.¶

3.4. 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.¶

CONDITIONAL_FILTER_SET {
  Parameter Type (vi64) = 0x44,
  Set ID (vi64),
  Switching Metric (vi64),
  Switching Offset (uint8),
  Configuration Count (vi64),
  Configuration (..) ...,
}

Configuration {
  Config ID (vi64),
  Metric Threshold (vi64),
  Filter Parameter Count (vi64),
  Filter Parameters (..) ...,
}

3.5. 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.¶

4.1. 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.¶

4.2. Algorithm 0: Throughput-Based Conditional Set Admission

active_set_ids = {}
reserved_bw = 0
B_available = B_total
for each set in ascending rank order:
  set.target     = B_total x set.fraction / sum_F
  B_available    = max(0, B_total - reserved_bw)
  if set.threshold <= min(set.target, B_available):
    active_set_ids += set.set_id
    reserved_bw += set.threshold

5.1. 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.¶

5.2. Step 2: Bind Conditions with RANGE_FILTER_CONDITION (Algorithm 0)

RANGE_FILTER_CONDITION (SetID=1):
  Algorithm ID           = 0
  Throughput threshold   = 2000  (kbps)
  Set throughput fraction = 6
  Activate switching     = 2
  Set rank               = 1

RANGE_FILTER_CONDITION (SetID=2):
  Algorithm ID           = 0
  Throughput threshold   = 2500  (kbps)
  Set throughput fraction = 4
  Activate switching     = 2
  Set rank               = 2

Activate switching = 2 means condition-based admission activates once both conditional RANGE_FILTER_CONDITION entries are registered. sum_F = 6 + 4 = 10.¶

5.3. 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.¶

6.1. Typical SUBSCRIBE workflow

+------------+                               +-------+
| Subscriber |                               | Relay |
+------------+                               +-------+
  |                                              |
  |    SUBSCRIBE (Standard Range Filters,        |
  |               RANGE_FILTER_CONDITIONs)       |
  |--------------------------------------------->|
  |                                              |
  |                  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.¶

6.2. 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.¶

+------------+                +-------+                  +-----------+
| Subscriber |                | Relay |                  | Publisher |
+------------+                +-------+                  +-----------+
  |                               |                            |
  | SUBSCRIBE_TRACKS              |                            |
  | (Track Namespace Prefix)      |                            |
  |                               |                            |
  |------------------------------>|                            |
  |                               | 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).¶

6.3. 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.¶

+------------+                +-------+                  +-----------+
| Subscriber |                | Relay |                  | Publisher |
+------------+                +-------+                  +-----------+
  |                               |                            |
  | SUBSCRIBE_TRACKS              |                            |
  | (Track Namespace Prefix)      |                            |
  |------------------------------>|                            |
  |                               | 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.¶

7.1. 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.¶

7.2. 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:¶

SUBGROUP_FILTER {
  Type=0x25, Length, [SetID], Range...,
  [Algorithm ID (vi64)],
  [Throughput threshold (vi64)],
  ...
}

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 ([I-D.ietf-moq-transport], 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.¶

7.3. 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.¶

7.4. Extension negotiation

Per Section 10.3 of [I-D.ietf-moq-transport], 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 (Section 3.3) or the self-contained design (Section 3.4), may instead rely on Setup Options defined in the Sender-Side Track Switching (SSTS) extension [SSTS] 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 Section 3.2. 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 [I-D.ietf-moq-transport]) 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 [I-D.ietf-moq-transport], 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.¶

10.1. Normative References

[I-D.ietf-moq-transport]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-19, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-19>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

10.2. Informative References

[SSTS]

"Sender-Side Track Switching for Media over QUIC Transport", n.d., <https://github.com/wilaw/moqt-ssts/blob/main/draft-wilaw-moq-moqt-ssts.md>.