Re: Deadlocking in the transport

[Christian Huitema <[e-mail]>]

On 1/10/2018 10:50 AM, Dmitri Tikhonov wrote:

> Let's make sure that we are talking about the same idea.  It seems that
> what you are suggesting is either:
>
>     A. The transport layer not allow the application to read from
>        a stream if a higher-priority stream data is available for
>        reading; or
>
>     B. If the application wants to read from a lower-priority stream
>        first, the transport layer will pretend that the higher-stream
>        data has been read.  In other words, the high-stream data will
>        be set aside somehow, giving the peer flow control credits for
>        sending more.
>
> Both seem suboptimal to me -- did you have something else in mind?

The problem arise because of over commitment of resource. Specifically,
it arises if the MAX DATA limit is lower the sum of the MAX STREAM DATA
limits. If MAX DATA was defined implicitly as the sum of MAX STREAM
DATA, we could have a very simple API between application and transport.
The application gives credits on the stream that it is ready to accept
data, and the transport just follows that.

I understand that from a resource point of view it is sub-optimal. The
smaller MAX DATA can be tied to a buffer pool not yet allocated to
specific streams, and there is some possibility to get the application
going with less than 2 bandwidth*delay products of buffers. But then,
this optimization is precisely what leads to deadlock conditions when
the transport does not quite get the priorities of the application, or
when the sender does not quite get the priorities of the receiver.

So we have two alternatives. One is to make the API more "expressive" so
the application can tell the transport exactly which order and
priorities can be applied. The other is to make the API less complex by
just mandating that MAX DATA be large than the sum of MAX STREAM DATA.
Or possibly removing MAX DATA altogether.

-- Christian Huitema