IETF MOQ WG: Pacing for FETCH

Message Snapshot

• List: moq@ietf.org
• Thread subject: Pacing for FETCH
• Message subject: [Moq] Pacing for FETCH
• Author: Law, Will
• Published: 2026-08-04T12:10:01.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Law, Will posted to the MOQ working group mailing list on August 4, 2026. As a solution to MOQT issue #1453https://github.com/moq-wg/moq-transport/issues/1453, I have a draft<https://wilaw.github.io/moqt-fetch-pacing/…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

As a solution to MOQT issue #1453https://github.com/moq-wg/moq-transport/issues/1453, I have a drafthttps://wilaw.github.io/moqt-fetch-pacing/draft-wilaw-moq-fetch-pacing.html proposing a pacing mechanism for FETCH. Standard congestion control algorithms attempt to download data as quickly as possible. Because thr…

Plain-Text Body

As a solution to MOQT issue #1453https://github.com/moq-wg/moq-transport/issues/1453, I have a drafthttps://wilaw.github.io/moqt-fetch-pacing/draft-wilaw-moq-fetch-pacing.html proposing a pacing mechanism for FETCH.

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) [https://dl.acm.org/doi/10.1145/3603269.3604839].

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. It is implemented as a MOQT extension and uses the rate signal as defined in SCONE.

Issueshttps://github.com/wilaw/moqt-fetch-pacing/issues and feedback welcome.

Cheers Will

---

Chief Architect - Cloud Technology Group Akamai Technologies Switzerland Mobile +41 79 535 07 94