Re: Deadlocking in the transport

[Jana Iyengar <[e-mail]>]

On Wed, Jan 10, 2018 at 9:47 AM, Charles 'Buck' Krasic <[e-mail]>
wrote:

[pruning]

I think priorities actually do help solve this in the following sense.   It
> makes a variation of #4.   A write can occur, even without immediately
> consuming flow control, but the priority does ensure it will get flow
> control when it needs it.
> This isn't necessarily HQ priorities though.   A workable, but less
> performant variation, might be to say that if the transport does buffer
> writes, it must service buffered writes in a global FIFO order.
>

I agree. That's what I meant by priorities solving it -- that the shared
resource (connection-level flow buffer), if consumed in priority order at
the sender, avoids this deadlock. This  assumes that the application can
express this to the transport of course.

With priorities, the part where A sends a partial header seems invalid.
>  The header compression does have requirements that headers be encoded
> strictly sequentially, so partial header write doesn't make sense there.
>
> The counter example given was a proxy, but I'm not sure that it is
> reasonable to guarantee that QUIC proxies can always be oblivious to
> mapping level semantics.  In the case of HTTP and header compression, it
> seems especially counter-intuitive to me, since most cases will not have a
> 1:1 upstream downstream connection topology.
>

Yup, agreed.