Subject: [quicwg/base-drafts] encoder stream can deadlock (#1420)

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jun 2018 14:11:48 +0000 (UTC)

If the encoder sends a large block that is bigger than the flow control limit AND the decoder doesn't read the block until all the data is present, THEN the decoder never releases flow control credit for the block, but the encoder can't complete sending of the block.  Deadlock.  Advise caution.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1420

---

From: krasic <[email-masked]>
Date: Wed, 06 Jun 2018 09:16:20 -0700

A decoder shouldn't do that.   The same kind of deadlock would be possible for any app protocol that precedes app level messages with a length where the message length is allowed to be larger than flow control window.     

[Blocked decoding](https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#rfc.section.6.3.2) is only for dependencies .    

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1420#issuecomment-395127280

---

From: afrind <[email-masked]>
Date: Wed, 06 Jun 2018 12:32:10 -0700

Right, if the decoder only wants to process the block in its entirety, it needs to buffer this data in application space and release the flow control.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1420#issuecomment-395186933

---

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Jun 2018 14:19:56 -0700

It's also worth noting that we really have two situations here:

On the encoder stream, nothing says the encoder has to send all updates in a single block.  It can query for available flow control, write that much, and wait for more credit.  The only time it deadlocks with this approach is when a single header is bigger than the flow control credit being issued, in which case don't put those huge Kerberos tickets in your dynamic table, for the love of God.

On the request stream, you do have to send the whole header set all at once, which is harder.  However, you're also bounding the size of headers you'll accept on any given stream; we can recommend that the flow control window be large enough to transfer the expected header set or that you be willing to buffer as needed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1420#issuecomment-395217431