Adding an Extensible Object Header

[wilaw]

This PR adds an extensible header to Objects, as well as updating the SETUP parameters to allow negotiation of required extension header parameters. Extensible headers have types which are IANA registered. A new Extensible header is defined and reserved with type 0x0, allowing name/value data to be passed in a manner compatible with HTTP headers. A new example is added showing serialization of an Object with an extensible header.

Fixes: #433

[afrind]

Individual Comment:

This seems generally ok. Perhaps there's an optimization where Object encodings don't carry even the count field unless at least one extension is negotiated.

The wider problem I see with this design is that extension negotiation is hop-by-hop (HTTP has similar problems with SETTINGS). What happens when, say, the publisher and relay negotiate use of an extension, but one of the subscribers to the relay does not?

[wilaw]

The wider problem I see with this design is that extension negotiation is hop-by-hop

Fair comment. We have the same problem with our MOQT version. It is negotiated hop-by-hop and there is nothing currently to enforce a MOQT version (or a extension support) across a delivery chain.

One solution on the extension side would be that Object Extensions, from a relay perspective, are always optional within a given moqt version. If we require an new Object header in a future version, then whichever spec defines that new version would also define the new object header as a first-class header and not an extension. We could remove the SETUP component. Any node (relay, or end subscriber) could test for the presence of the Extension , in much the same way that a HTTP server tests for the presence of a request header.

[suhasHere]

I understand the MUST. But I wonder if we should add a indicator in each extension to include if it needs to be forwarded as well. These extension headers must not be modified by the relays either to be complete. Since some of the extensions are useful to downstream.

[wilaw]

The assumption is that these extensions headers must always be forwarded and must not be modified by any relay. I could add language stating that explicitly?

[mengelbart]

I think explicit language to state that extensions must be forwarded would be useful. Maybe it's enough to replace "MUST be parsed" with "MUST be forwarded"?

[ianswett]

I think we should say that headers MUST be forwarded and MUST NOT be modified if that's what we intend.

I'd like to have these authenticated when using MoQ per-object encryption, but that's a different draft.

[suhasHere]

agree with @ianswett and @mengelbart .. Making it explicit is good in these cases.

I see GroupId, ObjectId and Extension Header can fall in to this category.

Secure objects uses ObjectId and GroupId to be authenticated and encrypted end to end, for example.

I am sure there will some use-cases that would have extensions whose scope is hop by hop too. I will be totally ok to have an scope field in the extension that identifies if it is between original-publisher and end-subscriber or not.

[wilaw]

Given that we have no means, as Alan has pointed out, of propagating header requirements beyond the immediate hop, it means that if any relay wants to use the extension header then all relays must forward them and not modify them. I have therefore modified the language to read that

Extension headers MUST be forwarded and MUST NOT be modified by relays.

[suhasHere]

I am fine with this as a starting place. If we may decide to support a way to indicate HBH vs E2E extensions, then we can address how to best solve it.

Starting with MoQ Relays forwarding extensions as-is seems fine to get some implementation experience.

Also https://datatracker.ietf.org/doc/draft-mzanaty-moq-loc/ and https://datatracker.ietf.org/doc/html/draft-jennings-moq-secure-objects-01 defines extensions that might be more than hbh scoped for example.

[suhasHere]

I don't think we need this defined ? Can you please share your thoughts on why we need this ?

[wilaw]

This default extension header provides a simple way to add ad-hoc name/value pairs to any object. This is similar to the ability of clients and servers to define custom request and response headers in HTTP-land. That functionality has proven extremely useful and efficient in enabling rapid development, testing and deployment of solutions without having to go to IANA registries or revise specifications. I'd like a similar capability within MOQT hence Extension Header Type Zero.

[suhasHere]

Thanks for the context. Still i don't see if this adds much value in end to end context.

[wilaw]

Based on your and others feedback, I have removed (via commit e176497) the Extension header type 0 definition. It can be added back in the future if necessary.

[suhasHere]

Header Value should be opaque bytes.

[wilaw]

Clarification - opaque to whom - the relays? Object headers values are not opaque to relays and nor are Extension Header values. If an application wants to hide content from a relay then it needs to place it in the Object payload (which is opaque) and not the headers.

[suhasHere]

If a relay supports an extension and needs it for some thing, it can parse it. If not, it forwards it as-is. This will enable experimentation and also support real-usecase where relay needs to use the information.

My inclination is each extension document defines its scope and usage.

[afrind]

I think Suhas and Will are saying the same thing here. There's language above that says you MUST forward unmodified.

[suhasHere]

Thanks @wilaw for this PR. I like the direction of this PR and have few clarification questions/nits.

[mengelbart]

I think explicit language to state that extensions must be forwarded would be useful. Maybe it's enough to replace "MUST be parsed" with "MUST be forwarded"?

[ianswett]

One comment about the negotiation approach, and I also am unsure of how to best use this, given it's negotiated hop-by-hop.

[ianswett]

This is a potentially painful way to negotiate extensions. What about making it REQUESTED-EXTENSION and then the server responds with the ones it supports of the requested set? At that point, if the client wants to close the connection because the server doesn't support a required extension, then it can.

[wilaw]

@ianswett - I have modified the PR with this commit to modify the extension negotiation and to rename the parameter to REQUESTED_EXTENSION

The REQUESTED-EXTENSION parameter (key 0x02) 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 a 32-bit 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
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.

[fluffy]

I basically like this but I think some parts that need some discution and some parts I think would be better as separate draft.

[fluffy]

I don't think it makes sense to negotiate object extensions with the relay. This would be like negotiating HTTP header extensions with a socks proxy. Other types of extensions we need too negotiate with server but not these. I think we can just remove this part of the PR.

[wilaw]

This negotiation has now changed slightly. The clients uses the revised REQUESTED-EXTENSION parameter to indicate which extensions it would like and the server responds with the sub-set of those that it does support. The client may then chose to continue or disconnect.

Since we have separate rules that relays MUST always forward all headers and MUST NOT modify them, any negotiation is practically only going to happen at the final hop. I agree that its utility is limited. I would like to remove it, but first I want agreement from those who wanted it in there in the first place.

[fluffy]

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

[RichLogan]

Should we also update the structures shown in the Multi-Object Groups section to show extension count + extensions in the track and group forwarding preference structures?

Track:

moq-transport/draft-ietf-moq-transport.md

Lines 1735 to 1741 in 358c5d7

	{
	Group ID (i),
	Object ID (i),
	Object Payload Length (i),
	[Object Status (i)],
	Object Payload (..),
	}

Group:

moq-transport/draft-ietf-moq-transport.md

Lines 1777 to 1782 in 358c5d7

	{
	Object ID (i),
	Object Payload Length (i),
	[Object Status (i)],
	Object Payload (..),
	}

[tianji-sdo]

A 5G use case to justify the support of the PR (Problem description & Requirements on MoQT per-object metadata header extension):

As we have presented in the IETF-121 MoQ session @ Dublin, the 3GPP 5G has standardized the solution of applying the MoQT to address the transmission of encrypted XRM media streams between MoQ server(s) and client(s) via MoQ relay. A MoQ relay is deployed in the 5G UPF. The corresponding 3GPP 5G specifications are TS 23.501 and TS 26.522. In the MoQT-based solution, there is per-object (or so-named per-PDU in 5G term) related metadata that is used to identify the PDU-set (i.e., a set of PDUs) related metadata information to 5G system. These PDU-set meta-info is identified and marked at a 5G UPF (i.e., where a MoQ replay runs) for RAN-based resource scheduling and optimization. Our IETF draft (https://datatracker.ietf.org/doc/draft-defoy-moq-relay-network-handling/) has clearly explained the mechanism.

Because an XRM media stream is encrypted (and so is the RTP header extension associated with an XRM PDU), the PDU-set metadata has to be mapped to the MoQT metadata field in an object header. The MoQ-based solution (as in 3GPP TS 23.501) is repurposing those object header fields, which leads to two problems: mapping accuracy and future extensibility.

Based on the discussions & rough consensus from the IETF-121 MoQ session, we think that the logics as specified in PR#502 , targeting at providing the OBJECT Extension Header, can address exactly the XRM ciphered stream challenges with a new revision of the MoQT draft.

Those logics include REQUESTED-EXTENSION parameter, Object Extensions, as well as {{IANA}} part, and possibly more, in the current PR.

[xdfy]

I'd like to give more details on the use case described in #502 (comment).

There are basically 2 phases: (1) client and server negotiate the use of the extension and (2) the media sender includes XR metadata in the object headers.

For (2), the existing PR text is sufficient for our needs: we can register a MOQ extension header type "A" with IANA (just not sure if we should use the 0-127 space or the 128-16383 space).

For (1), our understanding is that the same MOQ extension header type "A" is used to set a varint value in the REQUESTED-EXTENSION parameter in the SETUP messages.

Additionally, for (1), the 5G XR use case introduces a potentially new interesting aspect: this extension does not relate to a monolithic set of metadata fields. It can include multiple sets of metadata, e.g.:

• So-called "Release-18 (R18) metadata", which is a fixed set of metadata defined in by 3GPP.
• "R19 metadata", which is a second fixed set of metadata defined by 3GPP
• Potentially, both sets may be communicated together, or in some cases only one set may be communicated.

Additionally, some metadata fields of the R18 metadata set are optional.

To address this need, our IETF draft ( https://datatracker.ietf.org/doc/draft-defoy-moq-relay-network-handling/) has defined bitfields (2 varints) that are included in a new TLV parameter in the SETUP messages. Client and server use these varints to negotiate their supported/requested 5G XR metadata set.

This requires registering a new TLV type for use in the SETUP messages. This may be okay if our case of "negotiable extension format" is rare.

For the sake of discussing the MOQ extension mechanism design, here are multiple options for handling this situation, that we can think of (as a starting point -- we don't have a strong preference)

Option A (used in our draft so far) : when adding an extension with a negotiable format, a new TLV type is registered, for use in the SETUP message. The value of the new TLV contains bitfields or any other parameter useful to negotiate the actual content of the per-object metadata of the extension.

Option B (not used in our draft so far) : MOQT defines a new "extension description" TLV that is used in SETUP messages. Its value starts with a varint, which holds the MOQ extension type. The remainder of the TLV value (beyond the initial varint) depends on the extension. Multiple such TLVs can be present in a SETUP message. Such a method would avoid having to register a new TLV by each extension with a negotiable format.

To conclude, option A works and does not require a change in the PR. Option B may make it easier for some future extensions but it would require a small change in the PR.

[gloinul]

Should this space be greased or any particular picking algorithm?

[LPardue]

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

[gloinul]

If this is kept in, it purpose needs to be clarified. But it feels like this is creating an additional extension space.

[wilaw]

Based on your and others comments, I removed (via commit e176497) the Extension header type 0 definition. It can be added back in the future if necessary.

[gloinul]

I am bit worried by the usage of word Optional here? What exactly is optional? Looking below I get the impression that Extension header handling are depending on role of the node but in no case are they truly optional, other than it comes to the publisher including them.

A Relay must forward and not modify
A client must be capable of receiving and ignoring them.

[gloinul]

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?

[afrind]

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.

[afrind]

Individual Review:

1. This needs a rebase because it doesn't include subgroups yet
2. I think we also might want a way to specify an extension per subgroup rather than per object (eg: an extension sent once at the beginning of the stream that applies to all objects that follow).

[afrind]

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.

[afrind]

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

[afrind]

concatenation of varints

I think an example might help illustrate.

[afrind]

Extension headers MUST be forwarded and MUST NOT be modified by relays

I agree if the relay doesn't understand the extension then we need these normative requirements.

I wonder if there's room for a negotiated extension that is solely between the publisher and the first hop, where the first hop is allowed to remove the extension if it not longer has applicability.

[afrind]

transmission of application-specific data

MoQT already allows for the transmission of application specific data -- object payloads. What's unique here is a) there can be some well known structure of the application data and b) it is visible to relays as well as the end consumer.

[afrind]

future evolution of the transport protocol

Maybe reword to "modification of transport protocol behavior"

[afrind]

I think Suhas and Will are saying the same thing here. There's language above that says you MUST forward unmodified.

[afrind]

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).

[wilaw]

@RichLogan

Should we also update the structures shown in the Multi-Object Groups section to show extension count + extensions in the track and group forwarding preference structures?

Yes. Commit ae71406 fixes this.

[suhasHere]

This is coming to be pretty close to finishing. I would like to see the PR based off the main branch to make sure of the encodings

[suhasHere]

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

[wilaw]

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.

[suhasHere]

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.

[wilaw]

@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.

[suhasHere]

Like to understand what do we mean by concatenation here ?

[wilaw]

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

[suhasHere]

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

[wilaw]

Based on feedback in yesterday's interim meeting, I added Commit f2fba0c which relaxes the constraints on relays having to always forward and not modify extension headers. New language reads as

Object Extension Headers are visible to relays. Extension Headers SHOULD be forwarded and SHOULD NOT be modified by relays.

This allows for the identified use cases in which a) an edge relay wishes to remove watermarking infomration before it reaches the final subscriber and b) relays may add data to tracing extensions as the Object moves through the distribution network.

[wilaw]

A request was made by chairs to collate use-cases for extension headers. Documented use-cases are listed below.

1. 5G XR - as per Adding an Extensible Object Header #502 and Adding an Extensible Object Header #502
2. Tracing - https://opentelemetry.io/docs/concepts/signals/traces/
3. LOC - https://datatracker.ietf.org/doc/draft-mzanaty-moq-loc/

If there are more use-cases, please add them.