Conditional Range Filters for Media over QUIC Transport
draft-yuyou-conditional-filtering-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yu You , Serhan Gül , Ali C. Begen , Zaheduzzaman Sarker | ||
| Last updated | 2026-08-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yuyou-conditional-filtering-00
Media Over QUIC Y. You
Internet-Draft S. Gül
Intended status: Standards Track Nokia
Expires: 18 February 2027 A. Begen
Networked Media
A. Sarker
Nokia
17 August 2026
Conditional Range Filters for Media over QUIC Transport
draft-yuyou-conditional-filtering-00
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://yuyou.github.io/conditional_filtering/. Status information
for this document may be found at https://datatracker.ietf.org/doc/
draft-yuyou-conditional-filtering/.
Discussion of this document takes place on the Media Over QUIC
Working Group mailing list (mailto:moq@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at
https://www.ietf.org/mailman/listinfo/moq/.
Source for this draft and an issue tracker can be found at
https://github.com/yuyou/conditional_filtering.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
You, et al. Expires 18 February 2027 [Page 1]
Internet-Draft Conditional Range Filters August 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. The Inline RANGE_FILTER_CONDITION Parameter . . . . . . . . . 4
3.1. Relationship to Existing SetID . . . . . . . . . . . . . 4
3.2. Parameter Definition . . . . . . . . . . . . . . . . . . 4
3.3. Alternative 1: Reference Design . . . . . . . . . . . . . 6
3.4. Alternative 2: Self-Contained Design . . . . . . . . . . 7
3.4.1. Parameter Definition . . . . . . . . . . . . . . . . 8
3.5. Summary of Design Alternatives . . . . . . . . . . . . . 9
4. Relay Evaluation and Bandwidth Allocation . . . . . . . . . . 9
4.1. General Behavior . . . . . . . . . . . . . . . . . . . . 9
4.2. Algorithm 0: Throughput-Based Conditional Set
Admission . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Relay State . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Bandwidth Allocation Algorithm . . . . . . . . . . . 11
4.2.3. Relay Procedure . . . . . . . . . . . . . . . . . . . 11
5. Example: OR-Preserving Conditional Layer Admission . . . . . 12
5.1. Step 1: Define the Range Filters . . . . . . . . . . . . 12
5.2. Step 2: Bind Conditions with RANGE_FILTER_CONDITION
(Algorithm 0) . . . . . . . . . . . . . . . . . . . . . . 12
You, et al. Expires 18 February 2027 [Page 2]
Internet-Draft Conditional Range Filters August 2026
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Call flow . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Typical SUBSCRIBE workflow . . . . . . . . . . . . . . . 14
6.2. Standard Publisher-initiated SUBSCRIBE_TRACKS workflow
(V19) . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Publisher-initiated workflow with
RANGE_FILTER_CONDITION . . . . . . . . . . . . . . . . . 17
7. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 18
7.1. OR-Preserving Admission Versus Set Replacement . . . . . 18
7.2. Alternative: Embedding Conditions in Existing Range Filter
Parameters . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Handling Filtered Subgroups: Prior Subgroup ID Gap . . . 19
7.4. Extension negotiation . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. 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.
You, et al. Expires 18 February 2027 [Page 3]
Internet-Draft Conditional Range Filters August 2026
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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.
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:
You, et al. Expires 18 February 2027 [Page 4]
Internet-Draft Conditional Range Filters August 2026
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
You, et al. Expires 18 February 2027 [Page 5]
Internet-Draft Conditional Range Filters August 2026
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)
}
You, et al. Expires 18 February 2027 [Page 6]
Internet-Draft Conditional Range Filters August 2026
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.
You, et al. Expires 18 February 2027 [Page 7]
Internet-Draft Conditional Range Filters August 2026
3.4.1. Parameter Definition
The CONDITIONAL_FILTER_SET parameter (Type 0x44) has the following
structure:
CONDITIONAL_FILTER_SET {
Parameter Type (vi64) = 0x44,
Set ID (vi64),
Switching Metric (vi64),
Switching Offset (uint8),
Configuration Count (vi64),
Configuration (..) ...,
}
* 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:
Configuration {
Config ID (vi64),
Metric Threshold (vi64),
Filter Parameter Count (vi64),
Filter Parameters (..) ...,
}
* 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.
You, et al. Expires 18 February 2027 [Page 8]
Internet-Draft Conditional Range Filters August 2026
* 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
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. Relay Evaluation and Bandwidth Allocation
Most of the text in this section is adapted from Sender-Side Track
Switching for Media over QUIC Transport [SSTS], 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>.
4.1. General Behavior
With this parameter, the subscriber pre-authorizes the relay to
autonomously adjust intra-track forwarding within the subscribed
track.
You, et al. Expires 18 February 2027 [Page 9]
Internet-Draft Conditional Range Filters August 2026
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
4.2.1. 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.
You, et al. Expires 18 February 2027 [Page 10]
Internet-Draft Conditional Range Filters August 2026
4.2.2. 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:
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
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.
4.2.3. 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 (Section 4.2.2) at
the next Group boundary.
You, et al. Expires 18 February 2027 [Page 11]
Internet-Draft Conditional Range Filters August 2026
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.
5. 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.
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)
You, et al. Expires 18 February 2027 [Page 12]
Internet-Draft Conditional Range Filters August 2026
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.
You, et al. Expires 18 February 2027 [Page 13]
Internet-Draft Conditional Range Filters August 2026
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. 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.
6.1. Typical SUBSCRIBE workflow
You, et al. Expires 18 February 2027 [Page 14]
Internet-Draft Conditional Range Filters August 2026
+------------+ +-------+
| 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.
You, et al. Expires 18 February 2027 [Page 15]
Internet-Draft Conditional Range Filters August 2026
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).
You, et al. Expires 18 February 2027 [Page 16]
Internet-Draft Conditional Range Filters August 2026
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.
You, et al. Expires 18 February 2027 [Page 17]
Internet-Draft Conditional Range Filters August 2026
7. Design Rationale
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:
You, et al. Expires 18 February 2027 [Page 18]
Internet-Draft Conditional Range Filters August 2026
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.
You, et al. Expires 18 February 2027 [Page 19]
Internet-Draft Conditional Range Filters August 2026
* *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.
You, et al. Expires 18 February 2027 [Page 20]
Internet-Draft Conditional Range Filters August 2026
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.
8. 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.
9. IANA Considerations
* A new Setup Option Type for RANGE_FILTER_CONDITION (suggested
value: 0x09) in the "MOQ Setup Options" registry (Section 15.4 of
[I-D.ietf-moq-transport]), 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
[I-D.ietf-moq-transport]), 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.
10. References
You, et al. Expires 18 February 2027 [Page 21]
Internet-Draft Conditional Range Filters August 2026
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>.
Acknowledgments
IETF MOQ Working Group.
Authors' Addresses
Yu You
Nokia
Email: yu.you@nokia.com
Serhan Gül
Nokia
Email: serhan.guel@nokia.com
Ali Cengiz Begen
Networked Media
Email: ali.begen@networked.media
ANM Zaheduzzaman Sarker
Nokia
Email: zaheduzzaman.sarker@nokia.com
You, et al. Expires 18 February 2027 [Page 22]