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

Protocol mechanism-wise, Mux/Demux requires framing.
A normalized framing scheme leads to normalized and/or interoperable mux/demux.

Similarly, routing and prioritizing both require an address space, and having it be normalized leads to interop.

The above is probably completely obvious, but mentioning it again just in case..
This is all that is required on the protocol side to do whatever routing/muxing/prioritization.

The problem, as it was with HTTP2, is that what the protocol allows won't matter if the APIs available to applications don't expose it.
Please don’t learn the wrong lesson w.r.t. the HTTP2 priority stuff—the complexity is and was relevant, yes, but we should be far more worried about the API side.

-=R


From: QUIC <quic-bounces@ietf.org> on behalf of Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Date: Wednesday, June 23, 2021 at 7:34 AM
To: Patrick Meenan <patmeenan@gmail.com>
Cc: MASQUE <masque@ietf.org>, Samuel Hurst <samuelh@rd.bbc.co.uk>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, David Schinazi <dschinazi.ietf@gmail.com>, QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Prioritizing QUIC DATAGRAMs (was: Re: [Masque] Prioritizing HTTP DATAGRAMs)




On 23 Jun 2021, at 15.10, Patrick Meenan <patmeenan@gmail.com<mailto: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