Skip to content

RFC: Define End-To-End parameters #1285

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

RFC: Define End-To-End parameters #1285

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e5dac7c
RFC: Define End-To-End parameters
afrind Oct 6, 2025
5955e56
Merge branch 'main' into afrind-end-to-end-params
afrind Oct 8, 2025
cb80fbd
clarify some publisher only/subscriber only params
afrind Nov 10, 2025
a928dc7
Merge branch 'main' into afrind-end-to-end-params
afrind Dec 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 33 additions & 8 deletions draft-ietf-moq-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1531,24 +1531,23 @@ for the peer, or a new request with a Request ID that is not the next in
sequence or exceeds the received MAX_REQUEST_ID, it MUST close the session with
`INVALID_REQUEST_ID`.

## Parameters {#params}
## Message Parameters {#params}

Some messages include a Parameters field that encodes optional message
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
Copy link
Collaborator

@ianswett ianswett Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@afrind afrind Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

@ianswett ianswett Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

unknown message parameters MUST close the session with `PROTOCOL_VIOLATION`.
Copy link
Collaborator

@ianswett ianswett Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Senders MUST NOT repeat the same parameter type in a message unless the
parameter definition explicitly allows multiple instances of that type to
be sent in a single message. Receivers SHOULD check that there are no
unauthorized duplicate parameters and close the session as a
`PROTOCOL_VIOLATION` if found. Receivers MUST allow duplicates of unknown
parameters.
unexpected duplicate parameters and close the session as a
`PROTOCOL_VIOLATION` if found.

The Parameters in SUBSCRIBE, PUBLISH_OK and FETCH MUST NOT cause the publisher
to alter the payload of the objects it sends, as that would violate the track
uniqueness guarantee described in {{track-scope}}.

Receivers ignore unrecognized parameters.

The number of parameters in a message is not specifically limited, but the
total length of a control message is limited to 2^16-1 bytes.

Expand All @@ -1561,6 +1560,16 @@ messages and for all other message types. SETUP message parameter types
are defined in {{setup-params}}. Version-specific parameter types are defined
in {{version-specific-params}}.

### Parameter Scope

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,
Copy link
Collaborator

@ianswett ianswett Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,

Copy link
Collaborator Author

@afrind afrind Nov 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

while others relate to the Track or subscription and are considered End-to-End,
Copy link
Collaborator

@fluffy fluffy Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@afrind afrind Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.
Comment on lines +1709 to +1711
Copy link
Contributor

@michalhosna michalhosna Oct 8, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

@afrind afrind Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

@fluffy fluffy Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@afrind afrind Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### Version Specific Parameters {#version-specific-params}

Each version-specific parameter definition indicates the message types in which
Expand Down Expand Up @@ -1681,6 +1690,9 @@ The AUTHORIZATION TOKEN parameter MAY be repeated within a message as long as
the combination of Token Type and Token Value are unique after resolving any
aliases.

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

#### DELIVERY TIMEOUT Parameter {#delivery-timeout}

The DELIVERY TIMEOUT parameter (Parameter Type 0x02) MAY appear in a
Expand Down Expand Up @@ -1717,6 +1729,9 @@ successfully delivered within the timeout period before sending any data
for that Object, taking into account priorities, congestion control, and
any other relevant information.

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

#### MAX CACHE DURATION Parameter {#max-cache-duration}

The MAX_CACHE_DURATION parameter (Parameter Type 0x04) MAY appear in a PUBLISH,
Expand All @@ -1729,6 +1744,9 @@ multi-object stream will expire earlier than Objects later in the stream. Once
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
Copy link
Collaborator

@ianswett ianswett Nov 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

{{parameter-scope}}).

#### PUBLISHER PRIORITY Parameter {#subscriber-priority}

The PUBLISHER PRIORITY parameter (Parameter Type 0x0E) specifies the priority of
Expand All @@ -1740,6 +1758,9 @@ subscription inherit this priority, unless they specifically override it.

The subscription has Publisher Priorty 128 if this parameter is omitted.

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


#### EXPIRES Parameter {#expires}

Expand All @@ -1760,6 +1781,10 @@ simultaneously.
If the EXPIRES parameter is 0 or is not present in a message, the subscription
does not expire or expires at an unknown time.

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


## CLIENT_SETUP and SERVER_SETUP {#message-setup}

The `CLIENT_SETUP` and `SERVER_SETUP` messages are the first messages exchanged
Expand Down