Re: Deadlocking in the transport

[Martin Thomson <[e-mail]>]

On Thu, Jan 11, 2018 at 5:40 AM, Ted Hardie <[e-mail]> wrote:
> The second case is one in which the protocol using the transport cannot
> access Y's semantic content until X is received.  In that case, it has three
> potential strategies.  One is not to permit the dependency to occur at all;
> as you note, lots of applications have inherent dependencies or common
> optimizations (e.g. FEC) that use this strategy.  This turns into a limit in
> the scope of what can use QUIC if this is the required strategy.
>
> Two is is for the using application/protocol to set up and manage its own
> buffers so that it can take Y out of the receive buffer and wait for X to
> arrive without blocking the transport.  While that might be magical thinking
> for some using protocols of QUIC, it's not clear that it always would be, as
> an application protocol built with QUIC as a transport in mind could do it.
> There are video cases I've worked on in the past where this
> buffer-at-layer-above-the-network was the default, because multiple networks
> were simultaneously being used to build the video playout buffer.

Yes, there will be cases where the content can be read, AND that that
content won't impose a resource penalty on the receiver such that it
is still able to release flow control credit for that read.  Those
applications can likely manage.  As you say, a video application has
to maintain memory for decoding N frames and it could take data from
frame X+1 and run it partway through the decoder pipeline up to the
point that X arrives.  That's just an exception to this general
problem.

> For the case you're describing, I think strategy 3/option 4 is right.  But I
> don't think we ought to rule out strategy one and two for all using
> protocols.  If you have a protocol that doesn't require or can easily avoid
> these dependencies being split across streams, you get option one for cheap.
> If you have an application/protocol that's built with the idea of the
> application managing its own buffers for resolving these dependencies,  two
> is practical rather than magical.

Sure.  I'd expect to have that protocol opt in to that sort of
exceptional handling, because having it as a default is hazardous.