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

[janaiyengar <[e-mail]>]

Given that QUIC implementations should really not be buffering any/much data, I think an API ought to be adequate. I agree that prioritization is important, but any prio scheme that you bake into QUIC is going to be either a poor fit for the next application. 

QUIC implementations can be (i) encouraged to minimize or not buffer any unsent data, and (ii) strongly encouraged to have an API that allows an application to indicate priorities across all "active streams". This would have the drawback of making priority opaque during QUIC's retransmissions, but I would argue that an application may well consider the priority of a retransmission as higher than that of the original transmission simply because of the amount of time in between the two.   I think that it's reasonable for endpoints to generally prioritize retransmissions over the rest.

In a past life, I implemented priorities in the TCP socket send buffer to prioritize across multiple application "messages". I learned the hard way that simply limiting the send buffer size in TCP and allowing the application to handle priorities above yielded similar benefits. The key was in keeping the TCP send buffer size low.

(When you're worried about prioritizing new data over retransmissions, my intuition tells me that it's either a non-issue or it doesn't matter. It's a non-issue when there are very few retransmissions that it's in the noise, or it doesn't matter since there are too many losses that those dominate latency beyond what priority can help with.)

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