Subject: Re: [quicwg/base-drafts] Disallow changes of table size after 0-RTT (#2276)

From: Mike Bishop <[email-masked]>
Date: Mon, 07 Jan 2019 15:14:33 -0800

I don't feel strongly about the feature itself, but this would make QPACK differ from the "increase is permitted" pattern we've created.

Assuming that SETTINGS arrives before any acknowledgements do and given that you can't evict unacknowledged entries from the dynamic table anyway, there's no way you could be wrapping under the old value of MaxEntries; increasing the max table size upon receipt of SETTINGS won't change the interpretation of anything you've sent.

The problem scenario seems to be a SETTINGS frame that's delayed past some acknowledgements on the decoder stream -- a bar on evicting anything until SETTINGS is received seems like the simplest fix.

-- 
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/2276#issuecomment-452116302

---

From: afrind <[email-masked]>
Date: Fri, 11 Jan 2019 09:28:27 -0800

I agree we should not allow SETTINGS to carry a different value for the maximum dynamic table size than the remembered value of 0-RTT.  The one exception that seems workable is if the remembered value is 0 (no dynamic table), the server could send a non-zero value in SETTINGS - this is the same case as 1-RTT, since the default is 0.

True, it means the server must reject 0-RTT when it changes the size of the dynamic table it wants to support, but this is a very rare server side change.

I find the idea of putting a latch in the QPACK code that disallows eviction before SETTINGS kind of strange, though the code to do so doesn't seem 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/2276#issuecomment-453593927

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jan 2019 16:05:19 -0800

If we allow 0 to become >0, that isn't fundamentally that different to allowing increases. If you chose 0, then 0-RTT probably isn't that effective either. I am inclined to leave no change as the only option if we go this way.

The alternative is to prohibit wrapping until SETTINGS is received, which I agree is manageable, but a little clumsy. For me, this comes down to whether we think that changing max capacity will be that common. It might be easier to say that changes (increases really) can't be made until you get a full handshake.

We see only slightly more than 1% of our TLS 1.3 connections accepting 0-RTT - or even attempting it. It is early days for 0-RTT, but that suggests that there will be plenty of opportunities - even for a server that prefers 0-RTT - to bump the capacity limit.

-- 
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/2276#issuecomment-453696458

---

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

> If we allow 0 to become >0, that isn't fundamentally that different to allowing increases. If you chose 0, then 0-RTT probably isn't that effective either. I am inclined to leave no change as the o…

I would argue that allowing 0 to become >0 is different from allowing increases in a subtle but important way: while the SETTING value is 0, wrapping is automatically disabled.  Therefore I do not see any complexity change from banning all changes to allowing 0 to be increased.  Whether there is any benefit to this in practice is a different, and quite valid, question.

In the end I do not feel strongly about allowing 0 to be increased either way, as long as non-zero values are not allowed to be changed.

-- 
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/2276#issuecomment-458385580

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Jan 2019 23:12:49 -0800

Discussed in Tokyo; okay with allowing changes only from zero to non-zero, and not increases between two non-zero issues.

-- 
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/2276#issuecomment-459240538