RFC: Define End-To-End parameters #1285

afrind · 2025-10-06T23:07:33Z

A strawman that could address #1278

Make unknown message params a PROTOCOL_VIOLATION
Make all subscriber message params hop-by-hop
Define publisher message parameter scope case-by-case:

e2e:
PUBLISHER_PRIORITY
MAX_CACHE_DURATION
DELIVERY_TIMEOUT
[GROUP_ORDER]
[DYNAMIC_GROUPS]

hbh:
AUTH_TOKEN
EXPIRES
[LARGEST_OBJECT]
[FORWARD]

A strawman that could address #1278 1. Make unknown message params a PROTOCOL_VIOLATION 2. Make all subscriber message params hop-by-hop 3. Define publisher message parameter scope case-by-case: e2e: PUBLISHER_PRIORITY MAX_CACHE_DURATION DELIVERY_TIMEOUT [GROUP_ORDER] [DYNAMIC_GROUPS] hbh: AUTH_TOKEN EXPIRES [LARGEST_OBJECT] [FORWARD]

fluffy · 2025-10-08T16:39:38Z

I think we should allow unknown messages that are passed between end subscriber and publisher but that seems a different issue. Perhaps we need a separate issue for this part of it.

michalhosna · 2025-10-08T16:43:36Z

draft-ietf-moq-transport.md

+as noted in the parameter definition.  End-to-End Parameters sent in PUBLISH,
+SUBSCRIBE_OK, TRACK_STATUS_OK or FETCH_OK MUST be cached by Relays and included
+in future downstream subscriptions or fetches for that Track.


Are the parameters immutable for the lifetime of a given track?

If parameters are mutable, how should the caching work? Only the last one is valid? What should existing connections see?

What about multi-publishers? Must all of them send the same values for e2e params?

Oh this is a good question. Can a publisher send REQUEST_UPDATE and change either parameters or extensions/track properties, or the properties are immutable?

Ian and I were proposing that if you get a new one if a message, it overrides whatever was in cache before for that property. And when downstreams requests, it gets latest in cache with no upstream check to see if the cache i fresh.

I think mutability makes sense for some of these but not others, so it might be on a case-by-case what you are allowed to change (with unknown=allow). I do worry a little bit about how that intersects our immutable Track model and what the edge cases might be.

fluffy

I think we need to get our extensibility story agreed on before we can do this part of it.

ianswett

Thanks Alan, I took a closer look at this after the WG discussion in Montreal, and I think it's fairly close.

ianswett · 2025-11-09T20:40:49Z

draft-ietf-moq-transport.md

-elements.
+Some messages include a Parameters field that encodes optional message elements.
+All parameters included in a message MUST be defined in the negotiated version
+of MOQT or negotiated via Setup Parameters.  An endpoint that receives an


There's one wrinkle I realize, which is that we are using Parameters in Setup to negotiate which Parameters are supported, but we need to allow for unknown Parameters in Setup.

Hmm I think I was trying to distinguish "message" params from "setup" params, but might need to be more crisp.

Alternatively, we could decide that Setup Messages use Extension Headers of some sort, but that feels odd somehow.

ianswett · 2025-11-09T20:41:31Z

draft-ietf-moq-transport.md

+Some messages include a Parameters field that encodes optional message elements.
+All parameters included in a message MUST be defined in the negotiated version
+of MOQT or negotiated via Setup Parameters.  An endpoint that receives an
+unknown message parameters MUST close the session with `PROTOCOL_VIOLATION`.


Suggested change

unknown message parameters MUST close the session with `PROTOCOL_VIOLATION`.

unknown Parameter MUST close the session with `PROTOCOL_VIOLATION`.

draft-ietf-moq-transport.md

ianswett · 2025-11-09T20:44:27Z

draft-ietf-moq-transport.md

 After sending a NEW_GROUP_REQUEST upstream, the request is considered
 outstanding until the Largest Group increases.

+When sent by a publisher, this parameter is not End-To-End (see


Isn't this sent by a Subscriber?

ianswett · 2025-11-09T20:47:24Z

draft-ietf-moq-transport.md

 Objects have expired from cache, their state becomes unknown, and a relay that
 handles a downstream request that includes those Objects re-requests them.

+When sent by a publisher, this parameter is End-To-End (see


Nit: This is correct, but given the Publisher is the only one who sends it, how about:

Suggested change

When sent by a publisher, this parameter is End-To-End (see

MAX CACHE DURATION is only sent by a publisher, and is End-To-End (see

ianswett · 2025-11-09T20:49:15Z

draft-ietf-moq-transport.md

+
+Message Parameters sent by the subscriber are always intended for the peer
+endpoint and are not forwarded by Relays.  Some message parameters sent by the
+publisher are intended for the peer endpoint and are not forwarded by Relays,


Suggested change

publisher are intended for the peer endpoint and are not forwarded by Relays,

publisher are scoped to the Session and are not forwarded by Relays,

With #1374 I assume all publisher parameters are scoped to a message, while "Extension Headers" (eg: properties) are end-to-end.

afrind · 2025-11-09T22:21:35Z

draft-ietf-moq-transport.md

-elements.
+Some messages include a Parameters field that encodes optional message elements.
+All parameters included in a message MUST be defined in the negotiated version
+of MOQT or negotiated via Setup Parameters.  An endpoint that receives an


Hmm I think I was trying to distinguish "message" params from "setup" params, but might need to be more crisp.

draft-ietf-moq-transport.md

afrind · 2025-11-09T22:24:36Z

draft-ietf-moq-transport.md

+
+Message Parameters sent by the subscriber are always intended for the peer
+endpoint and are not forwarded by Relays.  Some message parameters sent by the
+publisher are intended for the peer endpoint and are not forwarded by Relays,


With #1374 I assume all publisher parameters are scoped to a message, while "Extension Headers" (eg: properties) are end-to-end.

afrind · 2025-11-09T22:25:48Z

draft-ietf-moq-transport.md

+as noted in the parameter definition.  End-to-End Parameters sent in PUBLISH,
+SUBSCRIBE_OK, TRACK_STATUS_OK or FETCH_OK MUST be cached by Relays and included
+in future downstream subscriptions or fetches for that Track.


Oh this is a good question. Can a publisher send REQUEST_UPDATE and change either parameters or extensions/track properties, or the properties are immutable?

afrind · 2025-11-09T22:26:52Z

draft-ietf-moq-transport.md

+When sent by a publisher, this parameter is not End-To-End (see
+{{parameter-scope}}).
+


Suggested change

When sent by a publisher, this parameter is not End-To-End (see

{{parameter-scope}}).

fluffy

Mostly look good but I have one big concern. Making what we called properties in the presentation just be a type of parameter ( that is an end-to-end parameter ) seem like it will make it hard to describe all the way that they don't follow the rules of normal parameters. I think we should call them properties.

draft-ietf-moq-transport.md

fluffy · 2025-11-10T02:55:12Z

draft-ietf-moq-transport.md

+Message Parameters sent by the subscriber are always intended for the peer
+endpoint and are not forwarded by Relays.  Some message parameters sent by the
+publisher are intended for the peer endpoint and are not forwarded by Relays,
+while others relate to the Track or subscription and are considered End-to-End,


I don't love End-to-end as the name here. The point of these is you do not have to negotiation support for them in the setup and unknown ones are allowed. That is going to make the text really hard for the non end to end parameters. The issue is they only flow one way and end-to-end might suggest they can flow both ways. I did like separating them totally from parameters (other than same code point space) and calling them properties. I think that makes it easier to understand how they are different. Another option might be "track properties" but then I don't want to have to refer to the other ones as "non track propties" everywhere we use them.

I agree it will be easier to explain and conceptualize if we don't call everything "parameters" and have this distinction between end-to-end and not.

fluffy · 2025-11-10T02:56:32Z

draft-ietf-moq-transport.md

+as noted in the parameter definition.  End-to-End Parameters sent in PUBLISH,
+SUBSCRIBE_OK, TRACK_STATUS_OK or FETCH_OK MUST be cached by Relays and included
+in future downstream subscriptions or fetches for that Track.


Ian and I were proposing that if you get a new one if a message, it overrides whatever was in cache before for that property. And when downstreams requests, it gets latest in cache with no upstream check to see if the cache i fresh.

fluffy · 2025-11-10T02:59:47Z

draft-ietf-moq-transport.md


+When sent by a publisher, this parameter is End-To-End (see
+{{parameter-scope}}).
+


This just high lights that we should have two separate things of subscriber group order and publisher group order.

We tried spitting it that way and the PR was incredibly awkward, so we let it roll with the current spelling. Perhaps as this group of extensibility PRs comes into focus we can take another swing at splitting this.

I'd still love to get rid of Group Order, but that's TBD.

draft-ietf-moq-transport.md

ianswett

I think this is close enough, but happy to refine it.

afrind · 2025-11-13T20:05:12Z

I think we should land #1374 first, then rework this one to use Track Extensions instead of "end-to-end" parameters.

afrind requested review from suhasHere and vasilvv as code owners October 6, 2025 23:07

afrind added the Design Issues or PRs that change how MoQ works including the wire format. label Oct 6, 2025

afrind requested a review from ianswett as a code owner October 6, 2025 23:07

michalhosna reviewed Oct 8, 2025

View reviewed changes

fluffy requested changes Oct 8, 2025

View reviewed changes

Merge branch 'main' into afrind-end-to-end-params

5955e56

afrind added the Needs Discussion Tags for issues which need discussion, ideally at an interim or IETF meeting. label Oct 20, 2025

ianswett reviewed Nov 9, 2025

View reviewed changes

ianswett added the Extensibility Related to extensions, upgrades and greasing label Nov 9, 2025

afrind commented Nov 9, 2025

View reviewed changes

fluffy requested changes Nov 10, 2025

View reviewed changes

clarify some publisher only/subscriber only params

cb80fbd

ianswett approved these changes Nov 12, 2025

View reviewed changes

afrind added the Parked Issue we may discuss later or close as OBE label Nov 13, 2025

Merge branch 'main' into afrind-end-to-end-params

a928dc7

	unknown message parameters MUST close the session with `PROTOCOL_VIOLATION`.
	unknown Parameter MUST close the session with `PROTOCOL_VIOLATION`.

	When sent by a publisher, this parameter is End-To-End (see
	MAX CACHE DURATION is only sent by a publisher, and is End-To-End (see

	publisher are intended for the peer endpoint and are not forwarded by Relays,
	publisher are scoped to the Session and are not forwarded by Relays,

		When sent by a publisher, this parameter is not End-To-End (see
		{{parameter-scope}}).

RFC: Define End-To-End parameters #1285

Are you sure you want to change the base?

RFC: Define End-To-End parameters #1285

Uh oh!

Conversation

afrind commented Oct 6, 2025

Uh oh!

fluffy commented Oct 8, 2025

Uh oh!

michalhosna Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fluffy left a comment

Choose a reason for hiding this comment

Uh oh!

ianswett left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

afrind Nov 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

afrind Nov 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fluffy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ianswett left a comment

Choose a reason for hiding this comment

Uh oh!

afrind commented Nov 13, 2025

Uh oh!

Reviewers

Assignees

michalhosna Oct 8, 2025 •

edited

Loading

afrind Nov 9, 2025 •

edited

Loading

afrind Nov 9, 2025 •

edited

Loading