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

On 22/06/2021 15:58, Lucas Pardue wrote:
> On Tue, Jun 22, 2021 at 2:57 PM Spencer Dawkins at IETF
> <spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>>
> wrote:
>     I believe
>     that https://datatracker.ietf.org/doc/draft-hurst-quic-rtp-tunnelling/
>     was bumping up against the desire to use QUIC datagrams for
>     tunneling and the recognition that we don't have an agreed-upon way
>     to multiplex (and demultiplex) datagrams that are carried in the
>     same QUIC connection. 
> 
>     Do you see any connection between prioritizing datagrams and
>     multiplexing/demultiplexing datagrams?
> 
> Speaking personally. Yes there is a connection. But it only really
> matters where there is competition for resources, which typically
> manifests when things occur concurrently.
> 
> draft-ietf-quic-datagram calls these entities and says [1]
> 
> If the application protocol supports the coexistence of multiple
> entities using datagrams inside a single QUIC connection, it may need
> a mechanism to allow demultiplexing between them.
> 
> This really means the problem of defining the demultiplexing is left as
> a job to the application,
> if it needs it. And I think that is the correct choice because, as we're
> finding out in
> HTTP/3 DATAGRAM, we're evolving our understanding of demultiplexing
> requirements
> within the context and constraints of HTTP.

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.

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.

> I don't know if draft-ietf-quic-datagram needs to say anything specific
> about prioritization.
> Maybe it could crib some test from RFC 9000 Section 2.3 [2], so that
> people builiding
> DATAGRAM-based applications are aware of the considerations.

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.

Best regards,
-Sam


[1]: https://datatracker.ietf.org/doc/draft-hurst-quic-rtp-tunnelling/