Subject: [quicwg/base-drafts] Initial maximum table size needs clarification. (#2258)

From: Bence Béky <[email-masked]>
Date: Wed, 26 Dec 2018 07:34:59 -0800

Initial maximum table size needs clarification.

A QPACK context is shared between the encoder of one endpoint, call it endpoint
A, and the decoder of another endpoint, call it endpoint B.  Endpoint A is the
one sending HTTP messages (requests or responses).  (There is another,
completely independent QPACK context shared between the encoder of B and the
decoder of A used for messages sent by B.)  A and B must have a shared
understanding of the initial maximum table size for this context.  In HTTP/3,
endpoint B can send endpoint A a SETTINGS_HEADER_TABLE_SIZE setting.

In https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#maximum-table-size,
it is difficult for me to apply the sentence "The initial maximum size is
determined by the corresponding setting when HTTP requests or responses are
first permitted to be sent." from B's prospective, because B does not sent HTTP
messages using this QPACK context.  And from A's prospective, I understand that
A is allowed to send messages before receiving B's SETTINGS frame, at which
point the value of SETTINGS_HEADER_TABLE_SIZE is zero according to issue #2038
in the 1-RTT case, in contradiction with the current last sentence of this
paragraph.

Similarily, I find the phare "the initial maximum table size is the value of the
setting in the peer’s SETTINGS frame" confusing from B's prospective, because
it is B, not its peer sending the relevant SETTING.

I propose to reword this paragraph.  In the 1-RTT case, there are two options
for the initial maximum table size: zero, see #2256, or the value of
SETTINGS_HEADER_TABLE_SIZE, see #2257.  In either case, the encoder
cannot insert entries into the dynamic table until it receives the SETTINGS frame
from the decoder.

As for the case where QPACK is used in a protocol other than HTTP/3, I feel like
the initial maximum table size can either be left unspecified, placing the
burden on that other protocol.  Another option is to define it to be zero unless
that other protocol specifies otherwise.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 17:19:00 -0800

I think that setting the value to the maximum (from the setting, which is as-remembered in 0-RTT) is the most consistent.  It also has the value of saving a few bytes.

The case where the maximum increases after 0-RTT is a case that we need to address more thoroughly.  We have to acknowledge explicitly how this is acceptable: no evictions of unacknowledged entries are permitted, which also means no rollover of the modulo-2*MaxEntries encoding for largest reference.  This is complicated.

-- 
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/2258#issuecomment-450599152

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 30 Dec 2018 17:29:04 -0800

> The case where the maximum increases after 0-RTT is a case that we need to address more thoroughly. We have to acknowledge explicitly how this is acceptable: no evictions of unacknowledged entries…

Agreed. And my preference goes to simply disallowing servers from advertising a different max table size when 0-RTT is used.

-- 
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/2258#issuecomment-450599615

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 17:31:20 -0800

> disallowing servers from advertising a different max table size when 0-RTT is used

I'd be OK with 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/2258#issuecomment-450599699