Hey Martin,
On Wed, Jun 23, 2021 at 9:13 PM Martin Duke <martin.h.duke@gmail.com> wrote:
> 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.
>
I think this model breaks down entirely for something like WebTransport
where the session is created with a single stream and then there'll
potentially be multiple datagram flows in either direction all vying for a
slice of the pie.
Cheers,
Lucas