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

[Lucas Pardue <[e-mail]>]

Hey Sam,

On Wed, 23 Jun 2021, 09:36 Samuel Hurst, <[e-mail]> wrote:

>
> The primary issue that I can see with this is that it potentially leads
> to the inability to use DATAGRAMs for multiple application protocols in
> an interoperable way. While it's fully possible for one application to
> de/multiplex it's own traffic on the DATAGRAM channel, multiple
> applications sharing the same tunnel might have different (and
> incompatible) ideas on how to use an identifier that multiplexes
> traffic, or may use different mechanisms entirely.
>

Right. But having an identifier in the transport doesn't help much here.
Streams have such an identifier (split into 4 types) and don't solve the
problem you describe IIUC.

To give an example, an application mapping like HTTP/3 makes use of 3
types, using the up to the entirety of the values permitted. There isn't
currently a way for multiple completely independent HTTP/3 connections to
share a QUIC connection. HTTP/3 connection coalescing achieves sharing to
some degree, it relies on the demultiplexing occurring in the HTTP
messages. Similarly, CONNECT and CONNECT-UDP methods use HTTP to signal the
intent of streams or HTTP/3 datagrams, and applications can build context
state around this to decide how to dispatch received data.


> It's this danger of lack of interoperability that I don't like. I don't
> like the idea of having to write lots of application notes saying "you
> can do A but not with B, but B and C can coexist", which leads to
> applications exploding when someone does something unexpected with
> option D down the line, that I didn't foresee.
>
> Of course, I don't know exactly how much call there is for doing this.
> For example, with regards to my RTP Tunnelling draft [1] that Spencer
> linked to above I haven't encountered a need to run something alongside
> RTP/RTCP in DATAGRAMs yet, but that's not to say that it isn't a
> possibility.
>

The challenge is that if you want to mix usage intents for a shared
transport resource, you probably need some way to signal that. Since QUIC
delegates using streams and DATAGRAMs to upper layers applications, it's
very tricky to design anything at the lower layer to accommodate this.

One approach to allow general purpose indiscriminate resource sharing would
be to design a virtualization layer that sits just below actual mappings.
Such a thing would fool upper layers into thinking they had access to
native QUIC. The layer of indirection would probably require a "hypervisor"
to manage things properly. MASQUE is vaguely an instantion of this design
that relies on HTTP. WebTransport is vaguely another example, we used to
have a QuicTransport protocol but pivoted away from it back to HTTP.

The potential solution space is large. However, I'm not sure the problem
space you describe is broad enough to activate building something else. It
would be interesting to hear otherwise. At the end of the day, there needs
to be strong motivation for building complexity and/or runtime overhead in
order to share QUIC connection resources. Otherwise, isn't it just easier
to use multiple separate connections?


>
> I'm certainly interested in some form of prioritisation for my RTP
> Tunnelling draft [1], as protocols like RTP run in real-time and other
> things getting in the way can easily cause poor quality of service. This
> could be by making the application use longer receive buffers than
> necessarily to ensure smooth audio and video playback at the receiver,
> or random pauses and glitches in the stream.
>

Makes sense. Would you design that into your RTP tunneling mapping?

Cheers
Lucas

>
>