Re: [quicwg/base-drafts] Priority in QUIC Transport (#104)

[janaiyengar <[e-mail]>]

I'll take back some of what I said earlier. Since an application's interaction with QUIC uses a stream abstraction, as long as QUIC implementations do a late-binding to the data in the streams, an API that indicates stream priorities ought to be adequate. Data can be buffered in incoming stream buffers from the application to the transport, but we should avoid buffers deeper within the transport (which is natural, I think.) To be clear, I'm not including buffers for reliability in this conversation; those don't interact with priorities much.

On the TCP small buffer point, I think it's difficult to expect high performance if an application simply wants to shoot and forget into a non-prioritized buffer... perhaps your point is that it's still better for TCP (in an alternate Minion world) to provide a priority queue rather than a FIFO queue since that's an easier abstraction for apps to write to. If so, point taken. In this respect, the buffers between the application and QUIC can be seen as a priority queue, and this queue itself could be seen as an API element between the application and QUIC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/104#issuecomment-270982068