Re: Deadlocking in the transport

[Martin Thomson <[e-mail]>]

I am reminded again that intermediation is why we can't have nice things.

Yes, you are right, an intermediary cannot perfectly propagate flow
control state.  That means that even if either endpoint does what it
can to avoid a deadlock, the intermediary might end up creating that
deadlock anyway.  In that case, the most expedient solution is to
terminate the dependent stream and start over.

In part, it's the ignorance of the intermediary that causes this
particular problem.  If the intermediary was aware of the protocol
details then it might be able to recognize and avoid these situations,
but that seems a little too much to expect of intermediaries. Ruling
out the entire class of intermediary that operates purely at the
transport layer is extremely harsh.

What is more likely here is that we describe this situation, explain
that it is impossible to prevent in the presence of intermediation,
and explain how to kill the right streams in order to ensure forward
progress doesn't stall indefinitely.

I'd caution against an over-reliance on BLOCKED-style messages because
they will mark the blocked stream as a problem, where the best way to
proceed is to kill dependent streams.  That is, the blocked stream is
the one most likely to hold critical state; killing that might not
unbind the blockage.  But again, identifying the right stream to kill
requires a degree of additional sophistication, effectively tracking
the dependency graph.  What seems most likely - at least in the hq
case - is that requests will have the timers and those are what will
get killed.  That works better if compression updates are on separate
streams from requests, but the other mechanisms work reasonably well
too.


On Sat, Jan 13, 2018 at 5:01 AM, Roberto Peon <[e-mail]> wrote:
> The transport *CANNOT* provide ordering guarantees w.r.t. prioritization because flows are end-to-end, whereas connections are point to point.
> Flow-control, being a property of flows, ends up being asserted end-to-end though the mechanism at each hop is point-to-point.
>
> Consider the ‘standard’ client->proxy->server topology.
> If the server asserts flow control, the proxy must respect it.
> As the client<->proxy hop is asynchronous from the proxy<->server hop in most circumstances with a loadbalancing (i.e. shared flow) proxy, the proxy cannot guarantee flow-control window will be available for sending to the server even when flow control window is available from the client<->proxy.
>
> Preemption/cancellation/retry, the addition of more resources, or finer management of resources can be used to resolve the (transitive) deadlock.
>
>
> The sub-case of compression may be solvable without solving the general case as compression is point-to-point.
> -=R
>
>
> On 1/12/18, 8:04 AM, "QUIC on behalf of Mirja Kühlewind" <[e-mail] on behalf of [e-mail]> wrote:
>
>     I disagree. I think it can be good to provide the transport hints about dependencies in application data which then could be used by the transport to optimize the sent-out scheduling, but I don’t think the transport should provide guarantees for ordered processing between streams. For me the whole point of having streams in the transport is to resolve dependencies between independent data.
>
>     Therefore, I think it would probably be good to mention this deadlock problem in the main draft but I don’t think we should add strict priorities as a transport feature to QUIC. There are several ways how an application can avoid (don’t have dependencies by using the same stream for dependent data or wait until data has be sent before sending dependent data) or resolve (read all streams and implement an additional application layer buffer) such a deadlock and these should be explained in the applicability document respectively.
>
>     My 2c,
>     Mirja
>
>
>     > Am 10.01.2018 um 23:42 schrieb Martin Thomson <[e-mail]>:
>     >
>     > On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar <[e-mail]> wrote:
>     >> Yes, I think there's easy misinterpretation here -- something I realized
>     >> today as I've had conversations about this. What I meant was specifically at
>     >> the API between the app and the transport, at the sender. This is basically
>     >> saying that to avoid deadlock due to dependencies across streams, the
>     >> transport write API must allow the app to express strict priorities.
>     >
>     > Ahh, excellent, then I think at least we two are in agreement.  It
>     > seems like there is an emerging acceptance of the problem and proposed
>     > approach, I guess we might start considering how to address it.
>     >
>     > I think that this needs to be in the main spec.  Failing to document
>     > this sort of pitfall could be fatal.  Does anyone disagree?
>     >
>
>
>