RE: Deadlocking in the transport

["Lubashev, Igor" <[e-mail]>]

Mandating a strict priority order on the sender may cause an increase in HOL blocking, if the contents of a higher-priority stream are not needed by all lower-priority streams. That happens when a higher-priority stream has MAX_STREAM_DATA that allows the sender to keep transmitting on that stream exclusively for 1-2 rtt, but one of the early packets is lost. The entire connection is blocked till that one loss is repaired.

The value of MAX_STREAM_DATA cannot be reduced below 1-2 rtt-worth of data, in case the higher-priority stream is the only stream with data.

A transport wishing to minimize HOL blocking may decide to allocate bandwidth in an other than strict priority order. Or the transport API would need to be very versatile to convey strict stream dependency graphs as well as stream priorities.

-----Original Message-----
From: Mike Bishop [[e-mail]]
Received: Wednesday, 10 Jan 2018, 5:55PM
To: Martin Thomson [[e-mail]]; Jana Iyengar [[e-mail]]
CC: QUIC WG [[e-mail]]; Charles 'Buck' Krasic [[e-mail]]
Subject: RE: Deadlocking in the transport

No disagreement.  When choosing which stream *with pending data* to make progress on, I think choosing the higher-priority stream is necessary rather than advisory.  With H2, we're talking about client preferences about server responses which might not be ready yet, so it's always advisory to the server.  Here, we're talking about the application's preferences about its own data that it has already handed off.  That's something that happened within the HTTP/2 implementation, so there was no agreement or contract needed.

So long as the dependency is strictly on a higher-priority stream and the transport layer is handling priorities strictly when choosing what to send in a flow-control-limited situation, I think we avoid the deadlock.  That is, when X depends on Y, if new flow control credit is guaranteed to cause Y to make forward progress (and the other side is continuing to read from Y's stream), the other side would eventually be able to process X.

This isn't a protocol element, but an implementation element that's necessary for the protocol to be fully functional.

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Wednesday, January 10, 2018 2:42 PM
To: Jana Iyengar <[e-mail]>
Cc: QUIC WG <[e-mail]>; Charles 'Buck' Krasic <[e-mail]>
Subject: Re: Deadlocking in the transport

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?