-
Notifications
You must be signed in to change notification settings - Fork 24
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
base: main
Are you sure you want to change the base?
Changes from all commits
a5208af
0af94ca
8ccf41c
e9d83ce
7b150f7
8b5c167
358c5d7
ab407f7
3759564
e176497
6f31642
915ff95
ae71406
7488980
f2fba0c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1174,7 +1174,24 @@ the `query` portion of the URI to the parameter. | |
|
||
#### MAX_SUBSCRIBE_ID {#max-subscribe-id} | ||
|
||
The MAX_SUBSCRIBE_ID parameter (Parameter Type 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber. The default value is 0, so if not specified, the peer MUST NOT create subscriptions. | ||
The MAX_SUBSCRIBE_ID parameter (Parameter Type 0x02) communicates an initial | ||
value for the Maximum Subscribe ID to the receiving subscriber. The default | ||
value is 0, so if not specified, the peer MUST NOT create subscriptions. | ||
|
||
#### REQUESTED-EXTENSION parameter {#requested-extensions} | ||
|
||
The REQUESTED-EXTENSION parameter (key 0x03) allows the client to request | ||
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. | ||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not too sure of the purpose of this parameter. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Now on the point on how to know if a relay understands an extension or not , there are couple of options
Extensions are per object property. I am not totally sure if we need stream level extensions at the moq layer though. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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).
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.
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} | ||
|
||
|
@@ -2095,6 +2112,12 @@ Track or Datagram. | |
* 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Like to understand what do we mean by concatenation here ? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). | ||
|
||
|
@@ -2132,6 +2155,30 @@ Any object with a status code other than zero MUST have an empty payload. | |
Though some status information could be inferred from QUIC stream state, | ||
that information is not reliable and cacheable. | ||
|
||
|
||
#### Object Extension Header {#object-extensions} | ||
Object Extension Headers are visible to relays. Extension Headers SHOULD be | ||
forwarded and SHOULD NOT be modified by relays. The purpose of Extension | ||
Headers is to facilitate the future evolution of the transport protocol. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 Datagram Message {#object-datagram} | ||
|
||
An `OBJECT_DATAGRAM` message carries a single object in a datagram. | ||
|
@@ -2149,6 +2196,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 (..), | ||
|
@@ -2199,6 +2248,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 (..), | ||
|
@@ -2296,6 +2347,8 @@ Each object sent on a fetch stream after the FETCH_HEADER has the following form | |
Subgroup ID (i), | ||
Object ID (i), | ||
Publisher Priority (8), | ||
Extension Count (i), | ||
[Extension headers (...)], | ||
Object Payload Length (i), | ||
[Object Status (i)], | ||
Object Payload (..), | ||
|
@@ -2354,6 +2407,38 @@ STREAM_HEADER_SUBGROUP { | |
} | ||
~~~ | ||
|
||
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} | ||
|
@@ -2391,6 +2476,10 @@ TODO: fill out currently missing registries: | |
* Announce Error codes | ||
* Announce Cancel Reason 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this space be greased or any particular picking algorithm? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an example might help illustrate.