Skip to content
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.

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

Adding an Extensible Object Header #502

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
94 changes: 94 additions & 0 deletions draft-ietf-moq-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -984,6 +984,21 @@ client MUST set the PATH parameter to the `path-abempty` portion of the
URI; if `query` is present, the client MUST concatenate `?`, followed by
the `query` portion of the URI to the parameter.

#### REQUESTED-EXTENSION parameter {#requested-extensions}

The REQUESTED-EXTENSION parameter (key 0x02) allows the client to request
Copy link
Contributor

Choose a reason for hiding this comment

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

I struggle to understand how this header is useful unless all relay's in the chain forward it upstream towards the publisher for those that are related to the media content.

Are we envisioning both next hop extension as well as whole chain extensions?

Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: maybe underscore instead of hyphen as a seperator.

So long as extensions are either confirmed supported or cache/forward unmodified, I think there can be value. For example, perhaps the extension applies to last mile delivery, the ingest node doesn't necessarily need to understand it. That said, there are some sharp edges here in how extensions are defined, and what the expectations are.

the server to acknowledge support for multiple Extension Header types
{{object-extensions}} which are required for operation. The value is a
concatenation of varints, each describing an integer extension header type.
Copy link
Collaborator

Choose a reason for hiding this comment

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

concatenation of varints

I think an example might help illustrate.

This parameter is optional. If this parameter is present in the
CLIENT_SETUP message, then the server MUST respond with a
REQUESTED-EXTENSION parameter in its SERVER_SETUP message. This parameter
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should the server setup reply be a different parameter? It's odd to call it 'REQUESTED_EXTENSION' in on the acknowledgement side.

MUST list the subset of those extensions previously requested by the client
which the server supports. If the server does not support any of the
requested extensions, then it MUST respond with a parameter value length of 0.
The client can then choose to continue or disconnect the session, at its
discretion.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I am not too sure of the purpose of this parameter.
I am struggling understand what it means to say "server supports" .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Imagine in the future we introduce a new header which signals to a relay that it should transmit this object in its own QUIC stream (for whatever reason). By "supporting" this header, the publisher is signalling that it is aware of any relay processing rules which that header may invoke.

Copy link
Collaborator

Choose a reason for hiding this comment

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

How about we have something along the lines in the core transport ( below formulation ,may be, exactly what you have, but i am writing it down in a single place to see if we all can agree)

Relay Extension Processing Rules

  1. If a relay understands an extension, it follows the rules as described by the specification that defines the extension, when processing such an extension. Such rules may be to modify the extension ( by updating or by removing it), for example.
  2. If the extension specification requires a given relay to understand an extension but relay doesn't support such an extension, it is treated as protocol violation.
  3. Else the MUST forwards the received extension as-is to downstream relays/subscribers.

Now on the point on how to know if a relay understands an extension or not , there are couple of options

  1. Reserve code points for such extensions OR
  2. Use setup parameters to identify extensions

Extensions are per object property. I am not totally sure if we need stream level extensions at the moq layer though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Suhas - I agree on point 1 (processing rules are defined by whatever spec defines the extension).

but relay doesn't support such an extension, it is treated as protocol violation.

A protocol violation can only be triggered by behaviors defined by the MOQT spec. It cannot be a protocol violation to not support some future optional extension. It may be a protocol violation of the 3rd party spec that defines the extension, but that spec will need to deal with that outcome as these are, after all, optional extensions as far as MOQT is concerned.

Now on the point on how to know if a relay understands an extension or not ,

We have the setup negotiation already in place. This informs the client whether the server "supports" a given extension. By 'support' we mean that it understands any processing rules that are defined by the 3rd party spec. This can give the client some confidence that the server is likely to act in compliant manner regarding that extension.

## GOAWAY {#message-goaway}
The server sends a `GOAWAY` message to initiate session migration
({{session-migration}}) with an optional URI.
Expand Down Expand Up @@ -1511,6 +1526,12 @@ MUST be sent according to its `Object Forwarding Preference`, described below.
* Object Status: As enumeration used to indicate missing
objects or mark the end of a group or track. See {{object-status}} below.

* Object Extension Count: The number of Object Extensions present. A value of 0
indicates that no Object Extension Headers are present.

* Object Extensions : an optional concatenation of Object Extension Headers. See
{{object-extensions}} below.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd like to talk about ideas to bit pack the extension indictors to save space but conceptually good with this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Like to understand what do we mean by concatenation here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Meaning a series of Object Extension headers, serialized in sequence without any delimiters between them.


* Object Payload: An opaque payload intended for an End Subscriber and SHOULD
NOT be processed by a relay. Only present when 'Object Status' is Normal (0x0).

Expand Down Expand Up @@ -1557,6 +1578,35 @@ are sent on a new stream. This is to avoid the status message being lost
in cases such as a relay dropping a group and reseting the stream the
group is being sent on.

#### Object Extension Header {#object-extensions}
Object Extension Headers are visible to relays. Extension Headers MUST be
forwarded and MUST NOT be modified by relays. The purpose of Extension
Headers is to facilitate the future evolution of the transport protocol.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't see the last sentence here is needed.

Object Extension Headers are serialized as defined below:

~~~
Extension Header {
wilaw marked this conversation as resolved.
Show resolved Hide resolved
Header Type (i),
[Header Value (i)]
[Header Length (i),
Header Value (..)]
}
~~~
{: #object-extension-format title="Object Extension Header Format"}

* Header type: an unsigned integer, encoded as a varint, identifying the type
of extension and also the subsequent serialization. Header types in the range
0x00 - 0x20 inclusive are followed by a single varint encoded value. Header
types 0x21 and above are followed by a varint encoded length and then the
header value. Header types are registered in the IANA table 'MOQ Extension
Headers'. See {{iana}}.

### Object Message Formats

Every Track has a single 'Object Forwarding Preference' and the Original
Publisher MUST NOT mix different forwarding preferences within a single track.
If a subscriber receives different forwarding preferences for a track, it
SHOULD close the session with an error of 'Protocol Violation'.

## Object Stream

Expand All @@ -1577,6 +1627,8 @@ OBJECT_STREAM Message {
Group ID (i),
Object ID (i),
Publisher Priority (8),
Extension Count (i),
Copy link
Collaborator

Choose a reason for hiding this comment

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

This adds 1 byte to every object including those with no extensions. I'd rather we handle this as a flag embedded in the stream header type (eg: STREAM_HEADER_SUBGROUP=0x02-03. If the LSB is 1 then Extension Count and one or more extensions are present).

[Extension headers (...)],
wilaw marked this conversation as resolved.
Show resolved Hide resolved
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
Expand Down Expand Up @@ -1613,6 +1665,8 @@ OBJECT_DATAGRAM Message {
Group ID (i),
Object ID (i),
Publisher Priority (8),
Extension Count (i),
[Extension headers (...)],
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
Expand Down Expand Up @@ -1661,6 +1715,8 @@ The Object Status field is only sent if the Object Payload Length is zero.
{
Group ID (i),
Object ID (i),
Extension Count (i),
[Extension headers (...)],
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
Expand Down Expand Up @@ -1702,6 +1758,8 @@ The Object Status field is only sent if the Object Payload Length is zero.
~~~
{
Object ID (i),
Extension Count (i),
[Extension headers (...)],
Object Payload Length (i),
[Object Status (i)],
Object Payload (..),
Expand Down Expand Up @@ -1771,6 +1829,38 @@ OBJECT_STREAM {
}
~~~

Sending a group on one stream, with the first object containing an
Extension Header.

~~~
Stream = 2

STREAM_HEADER_GROUP {
Subscribe ID = 2
Track Alias = 2
Group ID = 0
Publisher Priority = 0
}
{
Object ID = 0
Extension Count = 1
{ Type = 0
Length = 21
{ Name length = 15
Name value = "example-traceID"
Payload = "123456"
}
}
Object Payload Length = 4
Payload = "abcd"
}
{
Object ID = 1
Object Payload Length = 4
Payload = "efgh"
}

~~~


# Security Considerations {#security}
Expand Down Expand Up @@ -1806,6 +1896,10 @@ TODO: fill out currently missing registries:
* Subscribe Error codes
* Announce Error codes
* Message types
* MOQ Extension headers - we wish to reserve extension types 0-127 for
standards utilization where space is a premium, 128 - 16383 for
standards utilization where space is less of a concern, and 16384 and
above for first-come-first-served non-standardization usage.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this space be greased or any particular picking algorithm?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 on greasing - let's get these reserved now and people adding them in their implementation from day one


TODO: register the URI scheme and the ALPN

Expand Down