Re: Deadlocking in the transport

[Jana Iyengar <[e-mail]>]

On Wed, Jan 10, 2018 at 2:08 PM, Martin Thomson <[e-mail]>
wrote:

> On Thu, Jan 11, 2018 at 7:32 AM, Jana Iyengar <[e-mail]> wrote:
> >> What would this advice be?  "Consume *all data* from higher priority
> >> streams before consuming data from lower priority streams?"
> >
> > Yes, to avoid deadlock.
>
> Priorities in h2 were always guidelines.  You (and I think Buck as
> well) are suggesting that a dependency would be something that the
> transport could be bound by.  That creates a dangerous schism between
> interpretation of priorities.
>
> In h2, if Y depends on X, a server can still send Y first.  It will
> likely do so if Y is ready to go before X.  That is, generally, h2
> favours forward progress over strict adherence to priority ordering.
>
> I agree that the case that we're talking about at the transport layer
> is substantively different, but if we don't have other language for
> what we're doing, we create the potential for some really bad
> confusion about this mechanism.  This is exacerbated by the fact that
> QUIC doesn't have any concrete priority mechanism built in.  QUIC
> depends on the application protocol to feed it priority information,
> and that naturally tends toward having hq (and h2) dictate priority.
> hq will likely use the h2 idiom, which won't fit well with this
> notion.
>

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.

As Buck pointed out, I think this is an extention to option (4) in that it
is useful when data beyond what's allowed by the flow controller is
buffered at the transport sender.