Subject: [quicwg/base-drafts] QPACK: stream cancellation only required when dynamic table size > 0 (#1747)

From: afrind <[email-masked]>
Date: Fri, 14 Sep 2018 16:47:21 -0700

The stream cancellation instruction serves to help the encoder cleanup state related to the dynamic table, but a decoder that sets the maximum dynamic table size to 0 does not need to send them.  Now that we omit header acknowledgement for blocks with no dynamic table references, this is the only use of the QPACK control streams for an implementation not using the dynamic table.

This is not to be confused with the encoder's current table size, which can be temporarily zero but raised later to the decoder's maximum.

-- 
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/1747

---

From: Martin Thomson <[email-masked]>
Date: Sat, 15 Sep 2018 05:33:20 -0700

If you think of this as an optimization for the case where there is no dynamic table AND you are cancelling streams (i.e., an exceptional condition on an exceptional condition), this really gets exciting (not).  Let them send cancellations.

-- 
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/1747#issuecomment-421563063

---

From: Dmitri Tikhonov <[email-masked]>
Date: Sat, 15 Sep 2018 18:04:15 -0700

Why send cancellations that serve no purpose?  My vote is for a consistent spec.

-- 
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/1747#issuecomment-421664969

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Sep 2018 02:34:02 -0700

I do not have a strong opinion on this, but I do think the proposal can be considered as a simplification.

The proposal allows endpoints that set maximum dynamic table size to zero to not even open a decoder stream. Maybe we could go one step further and forbid the creation of encoder stream if the maximum dynamic table size advertised by peer is zero.

Then, we can have simple HQ stacks that do not handle QPACK streams at all.

-- 
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/1747#issuecomment-421944059

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 17 Sep 2018 04:12:58 -0700

Amen.

-- 
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/1747#issuecomment-421972299

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Sep 2018 04:15:24 -0700

That would be useful for constrained devices.

-- 
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/1747#issuecomment-421972965

---

From: Bence Béky <[email-masked]>
Date: Mon, 17 Sep 2018 13:22:07 +0000 (UTC)

There can be problems if SETTINGS_HEADER_TABLE_SIZE is allowed to be changed to zero mid-connection (not with initial SETTINGS), so maybe this proposal should also require SETTINGS_HEADER_TABLE_SIZE not to be changed (or at least not to be set to zero) other than in the initial settings frame.

Otherwise what would happen if an endpoint sets SETTINGS_HEADER_TABLE_SIZE to zero not at the beginning of the connection, then a stream is cancelled but the peer does not need to be modified, then SETTINGS_HEADER_TABLE_SIZE is changed back to non-zero?  How will the peer know that the stream got cancelled?

Another consideration is that if an endpoint tries to close the decoder stream after changing SETTINGS_HEADER_TABLE_SIZE to zero mid-connection, there is no guarantee that the setting will reach the peer before the stream closure which is normally an error.  Therefore decoder streams cannot be closed even in this case, leaving the connection with an unused stream.

Finally, I believe that the order between SETTINGS frames and data on the decoder stream is not guaranteed.  Therefore it would need to be spelled out that a stream cancellation instruction received while SETTINGS_HEADER_TABLE_SIZE is zero must not be treated as an error (it might have been sent before the setting was changed).

That's why I think maybe it's easier not to allow SETTINGS_HEADER_TABLE_SIZE to be changed (at least to zero) after the initial SETTINGS frame.

-- 
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/1747#issuecomment-422013435

---

From: afrind <[email-masked]>
Date: Mon, 17 Sep 2018 07:00:25 -0700

@bencebeky : in HQ you can only send SETTINGS at the beginning of the connection, for all the reasons you describe.

@kazuho : my reasoning here was exactly to allow for simpler implementations that do not implement a dynamic table.  I hadn't thought about not opening the streams, but I'm not sure it really matters - nothing will ever be sent on them so you can effectively ignore them.

-- 
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/1747#issuecomment-422028006

---

From: Bence Béky <[email-masked]>
Date: Mon, 17 Sep 2018 19:13:02 -0700

Sorry, I wasn't aware of this amazing restriction in HQ.  Makes sense.

-- 
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/1747#issuecomment-422230239

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Sep 2018 14:21:50 +0000 (UTC)

So the biggest problem here is for a generic implementation of the encoder where it now needs to handle the expectation of stream cancellation acknowledgment specially.  When I send a header block, I track the need for acknowledgment.  Creating the tracking in a way that is robust against that is tricky.

-- 
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/1747#issuecomment-422412337

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Sep 2018 14:41:45 +0000 (UTC)

@afrind 
> my reasoning here was exactly to allow for simpler implementations that do not implement a dynamic table.

:+1:

> I hadn't thought about not opening the streams, but I'm not sure it really matters - nothing will ever be sent on them so you can effectively ignore them.

The issue is the additional state. You need to accept the creation of the decoder stream and you cannot reset it. For memory constrained devices, we could have QUIC stacks that support only a small number of currently operating streams. Spending one stream for transmitting nothing would be an overhead.

-- 
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/1747#issuecomment-422420779

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Sep 2018 10:09:09 -0700

@martinthomson, I'm not sure that you do.  If the decoder's maximum size is zero, you can never insert to the dynamic table, and therefore can never emit a header block that references it.  That means you'll never have sent a header block that expects an acknowledgement, since we already agreed not to ack static-only blocks.

-- 
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/1747#issuecomment-424796059

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Sep 2018 10:19:30 -0700

Right, that was the conclusion of the discussion in NYC.

-- 
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/1747#issuecomment-424799560

---

From: afrind <[email-masked]>
Date: Thu, 27 Sep 2018 15:45:49 -0700

Closed #1747 via #1761.

-- 
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/1747#event-1872304880