Subject: [quicwg/base-drafts] Non-blocking decoder (#1140)

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Feb 2018 00:49:01 +0000 (UTC)

The QCRAM draft currently enables an encoder to operate in blocking or non-blocking mode, because the encoder always knows which header blocks have been processed by the decoder.  However, there's currently no mechanism for a decoder to require an encoder to operate in non-blocking mode.  During design team discussions, this seemed to be a desirable property -- do we want to add a setting to support this?

There was also some discussion that a decoder which permitted blocking might still want to constrain how many blocked decoder instances it had, and therefore put a bound on the number of blocking QCRAM frames which should be permitted.

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 26 Feb 2018 19:18:24 -0800

> During design team discussions, this seemed to be a desirable property -- do we want to add a setting to support this?

IMMSMC, this was considered a must.

-- 
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/1140#issuecomment-368733668

---

From: afrind <[email-masked]>
Date: Tue, 27 Feb 2018 08:54:31 -0800

If we made this a SETTING, is that too late, considering 0RTT?  Would a client be able to use a previous setting value, and what happens if the client then ends up violating a server's new maximum blocking frames?

-- 
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/1140#issuecomment-368947138

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 27 Feb 2018 10:37:08 -0800

The client does not have to reference vulnerable entries until the second flight (assuming a single first request) and once the server response, its position regarding blocking avoidance becomes clear.

-- 
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/1140#issuecomment-368980878

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Feb 2018 18:49:50 +0000 (UTC)

Or we say that, like max table size, this is one of the settings the client must remember with the 0-RTT ticket, and the server can't accept 0-RTT if it wants to be stricter than it was.

-- 
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/1140#issuecomment-368984755

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 27 Feb 2018 10:55:18 -0800

> Or we say that, like max table size, this is one of the settings the client must remember with the 0-RTT ticket, and the server can't accept 0-RTT if it wants to be stricter than it was.

This will punish servers that decide to remove a potential source of latency by introducing latency at the start.

-- 
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/1140#issuecomment-368986479

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Feb 2018 11:01:31 -0800

But only for the first connection after a change, just like any other setting where the client has to remember the value.  It's not like we're saying they're forever barred from using 0-RTT.

-- 
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/1140#issuecomment-368988539

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 27 Feb 2018 19:26:17 +0000 (UTC)

Depending on the usage pattern, that penalty may be incurred by most connections.

On the other hand, if the client begins in avoidance mode, it incurs no penalty unless it packages more than one requests in the first flight.  Also, the requests in the second flight have no vulnerable entries.

-- 
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/1140#issuecomment-368996104

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Feb 2018 00:00:19 +0000 (UTC)

Anything we do for 0-RTT should be consistent with QUIC itself.  That is, if the server can't honour the limits it knows to apply to 0-RTT, then it has to reject 0-RTT.  And the corollary: if the server wants to decrease limits, it has to reject 0-RTT.

-- 
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/1140#issuecomment-369071230

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Feb 2018 16:29:29 -0800

I'm a little conflicted about this proposal.  It seems like it might be valuable, but then I have a serious aversion to options.  The added uncertainty about the value prior to receiving SETTINGS isn't a concern though: you can't use the table at all if you don't have settings.

-- 
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/1140#issuecomment-369077038

---

From: Mike Bishop <[email-masked]>
Date: Tue, 27 Feb 2018 16:59:43 -0800

I'm not sure that's true, or at least not stated.  In HTTP/2, the client has to act without seeing the server's settings.  In HTTP/QUIC, the client will probably either have 0-RTT memory or the SETTINGS frame in 0.5 RTT, but we don't currently have a prohibition on the client sending requests without seeing the SETTINGS frame.

-- 
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/1140#issuecomment-369082849

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Feb 2018 01:07:58 +0000 (UTC)

If we set the header table size to 0, the point remains: you can't use the table until you get SETTINGS.

(BTW, the current text on settings is poorly aligned with QUIC transport parameters, which should be fixed.)

-- 
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/1140#issuecomment-369084581