Subject: [quicwg/base-drafts] Initial size of dynamic table (#1530)

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 21:50:40 -0700

The draft doesn't say what the default should be.  I think that it should be the value of the setting, which would be more efficient than the only sensible alternative (that is, 0).  I don't see many encoders using less than the full table size for QPACK.

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 06 Jul 2018 10:15:21 -0700

??? [Section 4](https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#rfc.section.4) says:

> QPACK defines two settings which are included in the HTTP/QUIC SETTINGS frame.
>
>SETTINGS_HEADER_TABLE_SIZE (0x1):
>    An integer with a maximum value of 2^30 - 1. **The default value is 4,096 bytes.** See (TODO: reference PR#1357) for usage.

Now, that TODO clearly needs a fix, but I'm not clear what's missing on this issue,

-- 
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/1530#issuecomment-403095173

---

From: Martin Thomson <[email-masked]>
Date: Fri, 06 Jul 2018 16:09:43 -0700

That's a default value for the setting, but there is a starting value for the dynamic table size (prior to any size update instructions).  What is that?  Sorry for not being clearer.

-- 
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/1530#issuecomment-403167511

---

From: Mike Bishop <[email-masked]>
Date: Mon, 09 Jul 2018 10:53:21 -0700

Ah, I see.  So the receiver has declared a maximum of 4KB, but if the encoder doesn't specify a size before sending instructions, what is the table size at that point?

My initial inclination matched yours, to say that it's the receiver's declared maximum, so that the encoder only needs to speak to reduce it. But there's a corner case: In 0-RTT, we assume the previous max; server can't accept 0-RTT if it's going to go *lower*, but can still increase its value when it sends the SETTINGS frame.  That means either the server has to detect whether particular instructions were sent before or after the handshake completed and change the implicit table size, or there's a nasty corner case when the client thinks it has overflowed the table but the server thinks it hasn't.

HPACK requires the size change instruction to be the first instruction of the first block following the change; I'd honestly never thought about whether that requires a size change to be the first instruction of the first header block sent on a connection.  Does it?

I think it has to be zero, and require the encoder to declare the size it intends to use.

-- 
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/1530#issuecomment-403564944

---

From: Mike Bishop <[email-masked]>
Date: Mon, 09 Jul 2018 17:55:56 +0000 (UTC)

Ugh.  Actually, it's worse than that -- the server is allowed to tolerate violations during 0-RTT, so it could actually reduce the max table size once the SETTINGS frame arrives.

-- 
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/1530#issuecomment-403565768