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

[ianswett <[e-mail]>]

My main concern about putting prioritization into QUIC is that I don't know
what prioritization API would be sufficiently robust for non-HTTP/2
applications as well.  Possibly we could define some pluggable
"prioritization API"?

I want is per-stream send buffers, which allows both optimal prioritization
and a reasonable amount of buffering.  These per-stream send buffers
replace the TCP send buffers for most part.  The number of UDP packets
encrypted and written to the socket at once would be determined by
congestion control and pacing.   Data is retransmitted from these stream
buffers, which allows a stream to be re-prioritized and the retransmissions
to follow the new priority, instead of the original priority.  This also
makes cancellations simpler, because there's nothing to retransmit from the
cancelled stream.  But this could be done with the priorities inside the
transport layer or in the application layer, it's more a matter of what
interface we're designing.

I agree about embracing the monolith.  To make the above implementation
approach work well, a tight coupling makes a lot of sense.

Some pitfalls to be aware we've run into:
 1) Retransmissions in multipath may have smaller MTU, so having a stream
level send buffer is better than just a series of stream frames.
 2) FEC would likely not use retransmission at all.
 3) A zero-copy friendly interface is a good thing.
 4) There are cases when new data is more important than retransmissions,
or one retransmission is more important than another.

Given this seems like it will become clearer after a few more people
implement it, does it make sense to punt this conversation to the future a
bit?


On Fri, Jan 6, 2017 at 11:18 AM, janaiyengar <[e-mail]>
wrote:

> 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, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/104#issuecomment-270982068>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJcWRDEOYgiqcHAMdOQmOzh0sSaKXBks5rPpOVgaJpZM4LWi4b>
> .
>


-- 
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-270998565