Subject: [quicwg/base-drafts] Initial header table size of QPACK (#1767)

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Sep 2018 12:15:07 -0700

Unlike HPACK (quoted below), QPACK does not require an encoder to emit Dynamic Table Size Update as its first instruction.

> This dynamic table size update MUST occur at the beginning of the first header block following the change to the dynamic table size. In HTTP/2, this follows a settings acknowledgment (see Section 6.5.3 of [HTTP2]).
> [RFC 7541; section 4.2](https://httpwg.org/specs/rfc7541.html#maximum.table.size)

This means that the peers might disagree on the table size, unless we require the encoder to set the table size to the value advertised by the peers SETTINGS frame. But I wouldn't assume that we would want to require that; for example some encoders might want to stick to 4KB even when the peer's SETTINGS frame says the table can be as large as 1MB.

Considering these aspects, I think that we should require the QPACK encoder to send Dynamic Table Size Update as its first instruction, at least when the SETTING frame advertises a non-default value.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Sep 2018 07:20:46 -0700

In hq, endpoints can't send requests until they have received SETTINGS.  There is no uncertainty if you wait for that.

-- 
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/1767#issuecomment-422822441

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Sep 2018 16:08:02 -0700

The issue here is inefficiency.

Consider the case where the receiver advertised 1MB (using SETTINGS) and sender decided to use 4KB. Current specification does not require the sender to notify *it's* initial header table size. Then, the receiver will keep 1MB table even though 1020KB of it is a garbage.

That is the reason I prefer sending Dynamic Table Size Update as the first instruction. The alternative approach will be to send the sender's max header table size *also* as a SETTINGS frame; and then, memory-constrained devices can advertise that it's both send *and* receive max header table size is zero to omit the creation of *all* QPACK streams...

-- 
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/1767#issuecomment-422987495

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 20 Sep 2018 06:31:34 -0700

The encoder can't just decide to use 4KB and not tell the decoder about it: the protocol would not work.  The table sizes must be the same.

-- 
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/1767#issuecomment-423183767

---

From: afrind <[email-masked]>
Date: Thu, 20 Sep 2018 06:45:33 -0700

I think we need to include the language from HPACK:  If the encoder changes its size it must immediately send the Table Size Update instruction on the encoder stream.  If there is no default size (and there doesn't seem to be one) then it also needs to send a TSU as the first instruction as well.

-- 
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/1767#issuecomment-423188726

---

From: afrind <[email-masked]>
Date: Thu, 20 Sep 2018 06:47:53 -0700

I guess @martinthomson is suggesting that the initial value is the max from SETTINGS, since you are required to wait for it before sending.  If the encoder is using the decoder max it may omit the TSU.

-- 
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/1767#issuecomment-423189597

---

From: Mike Bishop <[email-masked]>
Date: Thu, 20 Sep 2018 17:20:28 +0000 (UTC)

That's what we agreed in #1530, yes.

-- 
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/1767#issuecomment-423264693

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Sep 2018 11:10:52 -0700

I'm fine with @afrind says in 
https://github.com/quicwg/base-drafts/issues/1767#issuecomment-423189597.

And thanks to Mike for pointing me to #1530. I now see that the necessary text exists (see #1642), and consider that this issue can be closed as duplicate of #1530.

-- 
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/1767#issuecomment-423280767

---

From: Mike Bishop <[email-masked]>
Date: Thu, 20 Sep 2018 11:17:59 -0700

Closed #1767.

-- 
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/1767#event-1858421922