Relays and extensions

[xdfy]

It could help to add some text on relays support and extension. I'll try to provide some input there, from draft-defoy-moq-relay-network-handling. You may want to look at this draft for more context (this draft considers both stream-based and datagram-based MOQ, but it becomes simpler here because we are only using streams).

• To support future relays, which may rely on metadata not present in the base protocol, an extension mechanism seems necessary.
  • Negotiation within WebTransport-based protocol: negotiation of an extension could use HTTP headers when setting up the WebTransport session with connect (this is similar to how ECN support is negotiated in MASQUE in draft-schinazi-masque-connect-udp-ecn). This makes it possible for a relay to reject a connection establishment, if the extension it needs is missing.
  • Negotiation within raw QUIC-based protocol could use QUIC transport parameters.
  • The interest in using HTTP headers (or QUIC transport parameters) is that the session will only be opened if all extensions are accepted. Other methods can be used (e.g., using a message at the very beginning of the QUIC session), but in this case the session will be created and closed immediately if the negotiation fails.
  • One open question is whether a MOQ relay could/should participate actively to the negotiation, beyond rejecting a request it does not like. For example, it could add a header in the CONNECT request forwarded to the server, to add an extension it needs.
• Even with relays that can work with metadata currently defined in the base protocol, I wonder how it would work with optional metadata. Some relays may accept optional metadata (i.e., provide a certain level of service when a metadata field is present, and provide another level of service when it is not present). But what if a relay needs a timestamp to properly provide its service? One possibility is to define and use an extension, which specifies that certain optional metadata fields are mandatory when this extension is used.
• What an extension can do could include:
  • Defining new frames, defining where these new frames can be used (e.g., in independent streams or within existing streams, such as "before media data frames").
  • Mandating the use of optional fields or frames
  • Specifying whether new frames are encrypted end-to-end or only authenticated.
• Also should we specify somewhere that unknown frames should be ignored?

[kixelated]

Hey @xdfy, I read your draft and in particular agree with section 2.1. That's the motivation behind the HEADERS frame, although a better name would be RELAY since that's the intended usage. My general philosophy is that relays should default to being dumb (ex. a generic QUIC proxy) but have the potential to augment their behavior based on easy to parse content.

I completely agree that we need a way of supporting new behavior. There's a few different options, like versioning the protocol, negotiating extensions in the handshake, or just adding new fields to existing frames (ex. HTTP headers). This section of the draft is completely missing at the moment and I don't have any insight on the best approach.

[xdfy]

Thanks @kixelated.

For "default behavior" (or endpoint-driven behavior), the endpoint can enable or improve relay behavior by placing certain metadata in HEADERS, and it appropriate for a class of relays (including CDN caches). All the endpoints need to know is that, probably, there are some relays on the path that can use certain metadata to provide a common type of service, similarly to what is done with HTTP caching metadata. Protocol versioning seems appropriate to add new metadata in this case.

For non-default (or more specialized) behavior, using (simple) extension negotiation enables driving endpoints decision to set, or not, metadata to obtain a service. For example, XR support in wireless networks is rather specialized. Without extension information, to make use of this feature, a server would have to set the necessary metadata on all streams, since in general any stream can be carried over a wireless access network. Exchanging extension information can tell the server whether or not this metadata is needed.

A fully endpoint-driven behavior seems to align with the HTTP approach very well (which is the general philosophy you mentioned, I believe). We could always say, for example, that all XR clients/servers MOQ implementations will define their own default behavior, which is to send metadata that enables XR support through MOQ relays. On the other side, using extension negotiation clarifies interworking between network/relay and endpoints. For example, a client or server could detect early on that there is little chance that QoS will be acceptable, rather than try and get bad service. To conclude, I don't have a final argument here (between fully endpoint-driven or supporting both) and getting feedback from others in the community would be useful.

[xdfy]

Hi @kixelated, after thinking further about it, the distinction I proposed earlier is probably not needed. Even more specialized/niche relays like the one I mentioned for XR can use the HTTP-like model in your protocol design. I guess the idea is that the endpoint should, based on context (application type, server location, type of client device, etc.) determine the type of metadata that it should send to get the best service. It does not preclude the client or relay from giving a hint to the server, but that could be considered outside of the scope of the MOQ protocol (and, again, probably not needed in general).