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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

> On 23 Jun 2021, at 15.10, Patrick Meenan <[e-mail]> 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