Subject: [quicwg/base-drafts] QPACK: Clarify how maximum dynamic table capacity can be set (#2330)

From: afrind <[email-masked]>
Date: Fri, 11 Jan 2019 11:57:19 -0800

0-RTT client
 Use remembered value
 If 0, server can increase in SETTINGS
 otherwise server must use this value in SETTINGS

Everyone else
 Starts at 0
 Can be set to non-zero by SETTINGS

This started as a modification of #2257, but the differences were significant enough I split it off.

Fixes #2276
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2330

-- Commit Summary --

  * QPACK: Clarify how maximum dynamic table capacity can be set

-- File Changes --

    M draft-ietf-quic-qpack.md (24)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2330.patch
https://github.com/quicwg/base-drafts/pull/2330.diff

-- 
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/pull/2330

---

From: Martin Thomson <[email-masked]>
Date: Sun, 13 Jan 2019 14:39:58 -0800

martinthomson commented on this pull request.

See my previous comment about the capacity instruction.

-- 
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/pull/2330#pullrequestreview-191993983

---

From: afrind <[email-masked]>
Date: Mon, 14 Jan 2019 09:51:41 -0800

Sending a MAX in SETTINGS never changes the table capacity.  Sending a set capacity instruction is required if the encoder wants to change capacity.

I agree the 0 -> >0 transition could be handled by reject 0-RTT when an implementation enables the dynamic table after running for some period with it off.  Such cases are probably as rare as the server changing the max capacity it supports.  The argument I have for allowing it is that it's the same case as 1-RTT (client starts at 0, enable dynamic table later), so I don't think the implementation needs to be any more complex to handle it.  But I can live without it also.

-- 
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/pull/2330#issuecomment-454097839

---

From: Bence Béky <[email-masked]>
Date: Tue, 22 Jan 2019 17:37:19 -0800

I support this change, because it avoids the clumsiness around wrapping if changing the value fo SETTINGS_QPACK_MAX_TABLE_CAPACITY was allowed.  I also agree with @afrind that an explicit capacity instruction has to be sent.

-- 
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/pull/2330#issuecomment-456634246

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 20:05:40 -0800

I can live with this.  In short, the maximum capcity is initially zero.  It can only be set to a non-zero value once.  The value is set using the SETTINGS frame and from remembered settings in 0-RTT.  If a non-zero value is remembered for 0-RTT, the SETTINGS frame has to carry the same 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/pull/2330#issuecomment-456662483

---

From: afrind <[email-masked]>
Date: Sun, 27 Jan 2019 21:13:58 -0800

@martinthomson: do you feel like the PR expresses those ideas clearly enough or you think it needs more polish?

-- 
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/pull/2330#issuecomment-458001233

---

From: afrind <[email-masked]>
Date: Sun, 27 Jan 2019 23:21:55 -0800

@afrind pushed 1 commit.

c2c69eb5ffa97670bb531d712725a677aae62caf  Martin's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2330/files/98a8932a0b24dbbe725b39ea01f86f1f0f43e947..c2c69eb5ffa97670bb531d712725a677aae62caf

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Jan 2019 00:53:00 -0800

kazuho commented on this pull request.

> @@ -427,16 +427,20 @@ The encoder MUST not set a dynamic table capacity that exceeds this maximum, but
 it can choose to use a lower dynamic table capacity (see
 {{set-dynamic-capacity}}).
 
+For clients using 0-RTT data in HTTP/3, the maximum table capacity is the
+remembered value of the setting. If the remembered value is not present or is 0,
+the server MAY set it to a non-zero value in its SETTINGS frame. If the

I am not sure if allowing server to accept 0-RTT without remembering the table capacity is a good idea, because it might lead to a connection error.

Instead, can we simply forbid the use of 0-RTT unless the server remembers the value (possibly through the use of session ticket)?

-- 
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/pull/2330#pullrequestreview-196924015

---

From: Bence Béky <[email-masked]>
Date: Mon, 28 Jan 2019 04:37:17 -0800

bencebeky commented on this pull request.

I agree with @kazuho.  If the remember value is "not present" on the server side, but it is on the client side, that can cause a problem.

Also, in my mind "the server MAY set it" and "if [...] omits SETTINGS_QPACK_MAX_TABLE_CAPACITY [...], the encoder MUST treat this as [...] error" are inconsistent.

-- 
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/pull/2330#discussion_r251396769

---

From: afrind <[email-masked]>
Date: Mon, 28 Jan 2019 17:58:04 -0800

afrind commented on this pull request.

I was thinking of a case where the client was attempting 0-RTT from a session which never set SETTINGS_QPACK_MAX_TABLE_CAPACITY (leveraging the default, which is 0), rather than a case where the server had sent one but can't remember.

The 'MAY' refers to when 0-RTT is resumed using 0 or None (implying 0, the default), where the 'MUST treat as error' refers to when 0-RTT is resumed with non-zero.  

But if I confused both of you, then the text needs work. 

> For clients using 0-RTT data in HTTP/3, the server's maximum table capacity is the
remembered value of the setting, or 0 if the setting was not previously sent.  When the client's 0-RTT value of the setting is 0, the server MAY...

?

-- 
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/pull/2330#discussion_r251666497

---

From: Bence Béky <[email-masked]>
Date: Mon, 28 Jan 2019 18:20:07 -0800

Thank you for clarifying.  Yes, this sounds better to me.

-- 
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/pull/2330#discussion_r251670168