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

[Martin Duke <[e-mail]>]

Lucas,

Assuming that we have the necessary language about QUIC APIs, as I've just
proposed, to enable something in future, then I personally have no use
cases or strong objection to punting. It is somewhat annoying to have a
draft for priorities, datagrams, and then priorities-with-datagrams, but if
writing the last bit will be a struggle (which I have no informed opinion
on) deferring it is probably the right decision.

Now descending into the weeds:

> It's easy to say this. The difficulty comes, as an implementer, with
knowing what to actually do with the information. Concrete example, if a
client signals "incremental false" does a server send all streams as FIFO
and then all DATAGRAMS as FIFO, or does it look at DATAGRAM flow creation
order

No, I think the DATAGRAMs correspond to a stream and they go with the
STREAM frames in with priority. Whether one delivers STREAM or DATAGRAM
first within a particular stream maybe doesn't need tight specification; if
we do, I'd say STREAM (if for no other reason than to deliver the headers)
and then DATAGRAM, unless STREAM is being flow-controlled. As datagram
flows don't have a 1-to-1 mapping with requests and responses, I think
streams are the correct abstraction for datagram priority, not flows. If
there are multiple Flow-IDs associated with the same stream, they all get
grouped together for priority purposes.