Hey Martin, On Wed, Jun 23, 2021 at 9:13 PM Martin Duke <[email protected]> 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
