Re: [Masque] Prioritizing QUIC DATAGRAMs (was: Re: Prioritizing HTTP DATAGRAMs)

Lucas,

15 months ago, I brought up DATAGRAM priorities as a reason to put the
stream ID in QUIC Datagrams:
https://github.com/quicwg/datagram/issues/6. I was happy with where this
ended up: that QUIC should present a stream-based datagram API to
applications for prioritization purposes, but that there was no reason for
the stream ID to go out over the wire.

Alternatively, this could be done on a per-datagram basis.

Granted, this is not currently in the corresponding PR:
https://github.com/quicwg/datagram/pull/20/files
I'll review accordingly.

ISTM that in H3 use cases the datagram is associated with a QUIC stream,
and it would be straightforward to use httpbis-priority to negotiate a
priority that then applies to datagrams associated with that stream.

When using QUIC over CONNECT-UDP you have streams on top of streams, and H3
priorities are negotiated both with the origin server and the proxy at
different levels of hierarchy.

Does this answer your question? Or have I totally missed the point?

Martin

On Wed, Jun 23, 2021 at 7:34 AM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
wrote:

>
>
> On 23 Jun 2021, at 15.10, Patrick Meenan <patmeenan@gmail.com> wrote:
>
> Using multiple connections should be strictly worse than streams sharing a
> connection, otherwise we probably have a gap that needs to be filled.
> Multiple connections kicks the can down to the congestion control
> algorithms for each of the separate connections to play nicely with each
> other and hopefully result in a decent experience. With a single connection
> we should have better knowledge over the overall transport and make better
> decisions.
>
>
> For what it’s worth I me mentioned this as a potential downside when the
> protocol was drafted but consensus were, as I recall, that the protocol
> shouldn’t be designed around overlapping protocols, but that any specific
> application protocols were free to document how they would interoperate.
>
> Giving up on datagram IDs simplifies a lot and provides application
> protocols with more freedom and less overhead than forcing a specific ID
> system. As Lucas pointed out, even if you have IDs there it is not trivial
> for multiple application protocols to co-exist. For example, an application
> protocol might  use all even ID’s for game audio, and all uneven IDs for
> active game state and controller data. Then someone decides to use that
> protocol to run communication with a remote controlled wheel chair
> protocol. But that protocol assigns even ID’s to left wheel speed, and
> uneven ID’s to right wheel speed. And so on and so forth.
>
> Instead you would design an app interop header for all datagrams. For
> example if the high bit of the first byte in a datagram is set, the first
> byte codes for the sub app protocol, and the following data is then sub app
> specific. If the high bit is not set, the 7 following bits is a sequence
> number modulo 128. Just as an example. Then app protocols can refer to this
> meta protocol as a means to coordinate.
>
> As Lucas also pointed out, stream IDs also do not work with multiple sub
> app protocols, at least not in all cases due to implicit context assigned
> to certain stream IDs. Note that stream IDs are not necessarily handed out
> in arbitrary order by the transport layer. This might be the default, but
> app protocols can require more precise control from the transport layer,
> which of course limits the number of usable stacks for that application.
>
> Mikkel
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>