Re: Deadlocking in the transport

[Roberto Peon <[e-mail]>]

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?
    >