IETF MOQ WG: MoQT relay diagnostics follow-up from IETF 126 / issue #1692
Altanai B posted to the MOQ working group mailing list on August 10, 2026. Hello Ian and Cullen, I wanted to follow up on my note about MoQT relay diagnostics and issue #1692. https://github.com/moq-wg/moq-transport/iss…
Message Snapshot
- List:
moq@ietf.org - Thread subject: MoQT relay diagnostics follow-up from IETF 126 / issue #1692
- Message subject: [Moq] Re: MoQT relay diagnostics follow-up from IETF 126 / issue #1692
- Author: Altanai B
- Published: 2026-08-10T18:39:19.000Z
- Source tag:
ietf-mailing-list - Message URL: Open in IETF Mail Archive
Summary
Altanai B posted to the MOQ working group mailing list on August 10, 2026. Hello Ian and Cullen, I wanted to follow up on my note about MoQT relay diagnostics and issue #1692. https://github.com/moq-wg/moq-transport/iss…
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
Hello Ian and Cullen, I wanted to follow up on my note about MoQT relay diagnostics and issue #1692. https://github.com/moq-wg/moq-transport/issues/1692 I�m very interested in taking the first pass at a short design sketch covering the main use cases, privacy and authorization considerations, and the possible protocol…
Plain-Text Body
Hello Ian and Cullen, I wanted to follow up on my note about MoQT relay diagnostics and issue #1692. https://github.com/moq-wg/moq-transport/issues/1692
I�m very interested in taking the first pass at a short design sketch covering the main use cases, privacy and authorization considerations, and the possible protocol mechanisms. As a first step, here is the short design sketch covering the main use cases.
draft-moq-relay-diagnostics
MOQT deployments typically place one or more relays between publishers and subscribers. When delivery stalls, degrades, or fails, a client observes only its own leg of the path, and often cannot determine whether the cause lies with the original publisher, an intermediate relay, path conditions, authorization policy, or its own behavior. This document collects use cases and requirements for exposing a limited, relay-controlled set of diagnostic information to authorized MOQT clients.
TODO: describe what a client can and cannot observe today, and the failure modes that are indistinguishable from the client's vantage point.
The goal is diagnostics that are actionable at runtime and interoperable across implementations, not a general-purpose telemetry channel within MOQT.
I would really appreciate any guidance on the process for associating the ID ( if that is ok to based on abstract) with the MoQ working group and eventually requesting working-group adoption.
Cordially ,
Altanai Bhttps://www.linkedin.com/in/altanai/
From: Altanai B altanai@outlook.com Sent: Thursday, July 23, 2026 6:03 AM To: fluffy@iii.ca fluffy@iii.ca; ianswett@google.com ianswett@google.com Cc: moq@ietf.org moq@ietf.org Subject: MoQT relay diagnostics follow-up from IETF 126 / issue #1692
Hi Ian and Cullen, Following up on the IETF 126 discussion around MoQT issue #1692, �Way for client to get diagnostic data from relay�: https://github.com/moq-wg/moq-transport/issues/1692
I volunteered to help co-author a draft that could capture the problem statement and propose a few starting-point designs for client-visible relay diagnostics in MoQT. My initial thought is to frame the draft around a small set of use cases first, then compare design options such as:
an explicit diagnostic request/response mechanism on the control path * diagnostic information carried in existing responses or errors where appropriate * relay capability advertisement during setup
I would need a coauthor to help giude with
privacy, authorization and avoiding leakage of operational topology * alignment with qlog/metrics work where the diagnostic data is better treated as logging or telemetry rather than protocol state
Could you let me know what you think the right next step is? For example, start with an individual draft, a short design sketch on the GitHub issue, or a PR against the transport draft if the scope is narrow enough? I�m happy to take a first pass at an outline and circulate it for review.
Cordial…