MOQT FETCH Pacing

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 4 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

Standard congestion control algorithms attempt to download data as quickly as possible. Because throughput between a relay and client is typically much higher than the encoded rate of the content, data retrieved via a FETCH message in MOQT can arrive in bursts far exceeding what is needed for playback. This burstiness contributes to buffer bloat and packet loss on the intermediary network. A better goal for a delivery system is not to download as fast as possible, but to download as fast as needed. In the context of Adaptive Bitrate Switching (ABR), "as needed" means a rate that avoids triggering unnecessary downward bitrate switches while still delivering enough data to allow the client to switch up when appropriate. Delivering data at this pace, rather than as fast as possible, has been shown to improve throughput and reduce retransmissions and Round-Trip-Time (RTT) [SAMMY].¶

This draft defines a mechanism for a client to negotiate support for a pacing extension during SETUP, and to activate that behavior via a new parameter accompanying a FETCH message.¶

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. FETCH PACING SETUP Extension

This draft defines a new MOQT extension, FETCH PACING, negotiated per [MOQT] Section 3.2. Support for the extension is advertised via a new Boolean Setup Option, FETCH_PACING_SUPPORTED, included in the SETUP message. An endpoint that implements this specification MUST include FETCH_PACING_SUPPORTED in its SETUP message; an endpoint that omits it MUST be treated as not supporting the extension. Once both peers have sent and received SETUP, each endpoint determines whether FETCH Pacing is part of the negotiated feature set: the extension is considered active for the session only if both the client and the peer serving the FETCH included FETCH_PACING_SUPPORTED.¶

4. PACING_RATE Message Parameter

Once negotiated, a client activates pacing on a FETCH message by including a new Message Parameter, PACING_RATE. The value of PACING_RATE is a varint as defined by [MOQT] Sect 1.4.1. Variable-Length Integers. This rate signal is an integer in the range (0-126). A value outside of that range MUST result in the publisher rejecting the FETCH with a REQUEST_ERROR message.¶

The rate signal is interpreted as defined in SCONE [SCONE] Section 5.1. The rate follows a logarithmic scale defined as:¶

Base rate (b_min) = 100 Kbps¶

Bitrate at value n = b_min * 10^(n/20)¶

where n is an integer between 0 and 126 represented by the value of the PACING_RATE parameter.¶

An endpoint that receives a FETCH message containing PACING_RATE from a client with which the extension was negotiated MUST pace delivery of the requested Objects at approximately the indicated rate. The timebase of this pacing SHOULD be at least the Group duration of the track being paced. Different relays will offer slightly different behavior and clients SHOULD NOT depend on precise pacing for their application success.¶

If the PACING_RATE parameter is absent, the endpoint MUST deliver Objects using its default, unpaced behavior. A client MUST NOT send PACING_RATE unless FETCH Pacing was successfully negotiated in SETUP; per Section 3.3 of [MOQT], sending an unnegotiated Message Parameter risks session termination.¶

The PACING_RATE parameter does not persist across FETCH instances and MUST be repeated with each new FETCH message in which pacing is required. Since FETCH provides no update mechanism, the pacing rate cannot be modified or removed once set. A client wishing to modify the pacing rate MUST cancel their FETCH request and issue a new FETCH message with the updated pacing value.¶

A relay MAY propagate a pacing parameter upstream only if it is assured that its downstream clients will FETCH that track at that rate or lower.¶

5. Security Considerations

Pacing signals are client provided and therefore might be abused by malicious clients. These clients can only send values in the range 0-126 as values outside this range will result in a REQUEST_ERROR, so range-based attacks are limited.¶

If a client sets a pacing rate far below the encoded bitrate of the track, for example setting a 100kbps limit on an hour of content encoded at 10Mbps, then there will be two consequences:¶

• An edge relay will pull the content to the edge with an upstream fetch, cache it and then release it slowly to the client. This can result in increased cache space pressure on the edge relay.¶

• The relay will spend more time delivering content than it otherwise would have, consuming additional resources.¶

These scenarios are similar to a client SUBSCRIBING to content with forward=0 and can be mitigated by general protective measures. For example, a relay could terminate a FETCH that is taking too long to drain with a REQUEST_ERROR.¶

Additionally, if the mechanism by which the relay paces the content is inefficient, then a client can cause additional work for the relay by activating pacing on FETCH requests. Relays that cannot offer efficient pacing might choose to not offer pacing during SETUP.¶

6. IANA Considerations

This document requests that IANA add two new entries to registries defined in [MOQT].¶

7. References

Authors' Addresses