Re: Deadlocking in the transport

[Mikkel Fahnøe Jørgensen <[e-mail]>]

For what it is worth, my APACK-02 proposal attempts to solve the problem by
blocking at source, but only for this particular use of QUIC.

https://github.com/dvidelabs/apack/blob/master/apack-02.md#encoder-blocking

If the header compression overall ensures to not use more than certain
amount of credits before blocking, and if the other streams make sure to
not consume any more that the overall credit minus the header block, then
this should suffice from a cursory view.

As to my previous example with large files, the api needs to have some sort
of resource management to ensure background feeds do not over allocate. An
actual complex stream dependency scheme is probably not a good idea, but
streams could be divided into resource groups with allotted bandwidth.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 10 January 2018 at 14.51.26, Mikkel Fahnøe Jørgensen ([e-mail])
wrote:

Blocking at source is not practical if feeding several very large files via
a mmap pointer to the API for deferred round robin transmission so all
files get equal opportunity to get through. In this case only small pieces
could be delivered at a time before the allocation must check if there is
are more transmission credits.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 10 January 2018 at 14.46.36, Ian Swett ([e-mail]) wrote:

I would agree that #4 is the right direction.  GQUIC also does #4, because
it forces all headers to be written before any requests that may depend
upon them are written.

If the application knows there is a dependency, it should be the
application's responsibility to deal with it, not the transport's, which
also points to #4(or maybe #1).

I also think there are use cases for data transfer that is not a stream and
does not consume flow control, but I don't think they solve every problem
and I don't think they should be necessary here.

On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov <
[e-mail]> wrote:

> On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote:
> > Protocols that create inter-stream dependency should be able to express
> > that in priorities down to the transport, which I believe is expected to
> be
> > part of the API. I believe that handles this issue, doesn't it?
>
> When it comes to priorities, the QUIC I-D gives implementations
> some leeway [1].  One cannot guarantee that a conforming
> implementation will not deadlock.
>
>   - Dmitri.
>
> 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6
>
>