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

[Martin Duke <[e-mail]>]

Lucas,

Sorry, I was too brief.

In my straw man where priorities always had stream scope, it would require
h3 datagram (an extension to an extension) and priority header (an
independent extension). That’s a lot of failure cases to design for.

If we want priority granularity below the stream, then it’s an extension to
the priority extension — yet another failure case. This is by no means
unsurmountable but does make it harder to code, specify, and reason about.

Whereas if anyone who implements h3 priorities correctly inherently
understands “flow priorities” or whatever, because it’s in the same draft
or normatively connected, that’s less complexity.

This is all rather abstract for an argument I’m not really making….

On Wed, Jun 23, 2021 at 2:47 PM Lucas Pardue <[e-mail]>
wrote:

> Hey Martin,
>
> On Wed, Jun 23, 2021 at 10:01 PM Martin Duke <[e-mail]>
> wrote:
>
>> This is an argument against punting, I think. If there are additional
>> semantics required to specify priorities on a sub-stream basis, it will be
>> somewhat more painful to have this be an extension than something native.
>>
>> Which is not to say we shouldn't punt.
>>
>
> I don't follow this argument, sorry. Extensibile priorities is not base to
> HTTP/3, it could be substituted by something entirely different (although I
> kind of hope not). HTTP/3 DATAGRAM is an extension, built on top of the
> QUIC transport DATAGRAM extension. WebTransport is a new thing built on top
> of these extensions. What does native mean in your definition? I really
> think it's better that things wishing to use Extensible priorities take on
> board the responsibility of defining that, using the extension mechanisms
> that it provides. Otherwise, we're bottlenecking the progress that people
> can make for the initial use cases that these things were built towards.
>
> Cheers,
> Lucas
>
>