The Rewind Subscription Filter

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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

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

In MOQT [MOQT], tracks are delivered via atomic Objects that are organized into Groups, which serve as join points, and Subgroups, that imply dependency between Objects and serve as the units to be fed into QUIC or Webtransport streams.¶

Subscribers can send SUBSCRIBE messages to receive messages that arrive at, or are created by, the publisher in the future. Such messages are delivered either one stream per Subgroup, or in QUIC Datagrams, as dictated by the original publisher. The stream mapping allows Objects that are no longer of use to the subscriber to not be sent or retransmitted without blocking later Objects.¶

Subscribers can also send FETCH messages to retrieve Objects from the past. The requested Object range is delivered on a single stream and cannot omit Objects that exist at the original pulbsher. If the entirely of the Object range is not in cache, a relay will have to issue its own FETCH upstream to satisfy the subscriber.¶

Because the subscriber may not know the live edge at request time, a variant of FETCH known as "Joining FETCH" instructs the publisher to use the current live edge as the end of the Object range. A "Relative Joining FETCH" defines the start of the Object range relative to the live edge. For instance, a Relative Joining FETCH might request two Groups prior to the live edge, which would deliver the two latest complete Groups as well as all Objects in the current Group before the live edge. Joining FETCH uses the same delivery semantics as other FETCH: all Objects are delivered in order on a single stream.¶

In some use cases, this behavior is not optimal. The subscriber might not need the delivery guarantees associated with FETCH if Objects will arrive too late to be useful. Furthermore, if some of the FETCHed Objects are available in cache, they might have to wait for other, blocking Objects to be delivered from upstream.¶

This document describes the Subscribe Rewind extension, which specifies a new Subscription Filter type "Rewind", allowing the subscriber to request SUBSCRIBE semantics for some groups before the live edge. The publisher only honors the request if it is able to do so from cache.¶

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

Each endpoint sends the MAX_REWIND option in its SETUP message. The MAX_REWIND option contains an integer that indicates the maximum number of groups that the peer migth request in a Rewind subscription filter. If zero, the peer may only request the current group. If absent, the peer MUST NOT send the Rewind subscription filter. This option is half-duplex; if an endpoint does not send the option, but receives it, it MAY use the Rewind Subscription Filter.¶

An endpoint might populate the MAX_REWIND option by reporting how many Groups it habitually stores in cache to answer FETCH or service subscribers that are behind on delivery. Other heuristics are also possible.¶

A subscriber sends a SUBSCRIBE message and can include a Rewind Subscription Filter instead of some other Subscription filter type. A value of zero indicates it would like to receive the entire current group; a larger value indicates it would also like to receive the most recent complete groups as well.¶

If the subscriber wants the Groups even if SUBSCRIBE semantics are not available, it MAY also send a Joining FETCH message. The object range MAY be larger or smaller than specified in the Rewind filter.¶

Upon receipt of a Rewind filter, the publisher MAY treat it as a Largest Object filter. It will typically do so if the track is not in cache. If it does not do so, it sends a "StartGroup" parameter in the SUBSCRIBE_OK. StartGroup is an integer that indicates the number of Groups before the LargestObject parameter that will be served via SUBSCRIBE.¶

Groups included in the StartGroup range will be delivered using SUBSCRIBE semantics: datagrams or Subgroup streams, subject to the delivery timeout and group order specified in the SUBSCRIBE negotiation. Groups serviced via the Rewind filter are not delivered by any Joining FETCH associated with this SUBSCRIBE, though can be delivered by Standalone FETCH messages. In some cases, this means the Joining FETCH delivers an empty range.¶

4. Publisher restrictions

The publisher MUST NOT include a Group in a range defined by the StartGroup unless:¶

• There are objects in cache for the group.¶

• The DELIVERY_TIMEOUT parameters for the SUBSCRIBE indicate the Group can still be sent.¶

If the publisher is a Relay, it must also meet one of the following conditions for the objects populating the cache from that Group:¶

• The cache was fully populated by FETCH message(s) that cover the entire Object ID range of the Group;¶

• The cache was fully populated by an active upstream SUBSCRIBE with a Largest Object before the Group;¶

• The cache was populated by FETCH message(s) that continuously covers a range starting at Object ID 0, and an active upstream SUBSCRIBE has Largest Object equal to or less than the end of that range.¶

The publisher is not required to verify that it has all objects in the Group to include it a StartGroup range. In particular, Groups delivered via SUBSCRIBE might be missing objects and are still eligible for Rewind.¶

The publisher MAY choose to report fewer groups than what meet these conditions. It might do so because the volume of data implied would consume too many resources, because it knows the current group is about to end, or due to any other policy.¶

As with any other SUBSCRIBE, if a publisher receives two streams for the same Subgroup from upstream, and cannot account for all object IDs between the end of one and the beginning of another, it MUST NOT deliver them on the same stream. It MAY simply omit the stream with higher object IDs.¶

The publisher MUST NOT send StartGroup > 0 if it knows it is servicing a track with Group IDs that are not strictly increasing.¶

5. Options and Parameters

Subscription Filter {
  Filter Type (vi64) = 0x16,
  Start Group (vi64),
}

6. Security Considerations

To the extent this reduces head-of-line-blocking and replaces upstream FETCHes to satisfy Joining FETCH at the relay, it can reduce resource consumption at publishers.¶

However, SUBSCRIBE semantics consume more QUIC or Webtransport streams. Past Groups might contain a lot of data, and FETCH delivery is contained on a single stream to simplify the flow control of this data. Publishers, who are aware of the content of their cache, SHOULD limit the range encoded by the START_GROUP parameter when is likely to overwhelm the channel or the subscriber.¶

7. IANA Considerations

Please add 0x16 (START_GROUP) to the Message Parameters registry.¶

There is no Setup Option registry, but if one arises, please add 0x16 (MAX_REWIND) to it.¶

8. Normative References

[MOQT]

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

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

Acknowledgments

Ian Swett designed many components of this proposal. Numerous members of the MOQ Working Group provided comments that refined our thinking.¶

Author's Address