Subject: [quicwg/base-drafts] Incorrect values for Required Insert Count (#3305)

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Dec 2019 01:36:19 -0800

If an encoder produces a Required Insert Count that is invalid, what can a decoder do?

The encoder could provide a value that is too high.  In the case where the value is high, but the number of entries is already acknowledged, this is probably harmless.  However, the decoder might block unnecessarily, if the values were not already present and the encoder references none of those entries or only references lower-indexed entries than it declared.  This is a performance problem up until the point where the encoder hasn't provided the "required" entries and finds no reason to do so, at which point the performance bug could be come a deadlock.

The encoder could provide a value that is too low.  The decoder might then reasonably reject an encoding, but some will not.  If the value is only too low and the entry is present in the dynamic table, some encoders will happily pull the value from the table and use it.  Those decoders will only generate an error if the entry isn't there yet.

I think that it would be better for the protocol if a decoder were able to generate an error if the maximum index referred to in a header block did not exactly match the Required Insert Count.

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 17 Dec 2019 05:14:29 -0800

>  This is a performance problem up until the point where the encoder hasn't provided the "required" entries and **finds no reason to do so**, at which point the performance bug could be come a deadlock. [Emphasis added.]

The "finds no reason to do so" is a functional, not performance, bug in the encoder.

As for performance, that's why there is the `QPACK_BLOCKED_STREAMS` setting.

> I think that it would be better for the protocol if a decoder were able to generate an error if the maximum index referred to in a header block did not exactly match the Required Insert Count.

I thought there was verbiage to that effect already, but I don't see it in the [current draft](https://tools.ietf.org/html/draft-ietf-quic-qpack-11).

-- 
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/3305#issuecomment-566536163

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Dec 2019 15:11:52 -0800

Alan found this in [Section 2.2.1](https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#name-blocked-decoding). It's a little obtuse though.

-- 
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/3305#issuecomment-566791128

---

From: Will Hawkins <[email-masked]>
Date: Tue, 17 Dec 2019 18:28:23 -0800

I am assuming that you are referring specifically to this paragraph?

```
When processing header blocks, the decoder expects the Required Insert Count to exactly match the value defined in Section 2.1.3. If it encounters a smaller value than expected, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED (see Section 2.2.3). If it encounters a larger value than expected, it MAY treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED.
```

-- 
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/3305#issuecomment-566838363

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Dec 2019 11:37:54 -0800

> The "finds no reason to do so" is a functional, not performance, bug in the encoder.

I interpreted this as saying that the encoder produced a RIC for entries that don't exist in the table yet and perhaps never will.  The bug is still producing a RIC that isn't referenced in the encoded header block.

-- 
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/3305#issuecomment-567632760