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

From: afrind <[email-masked]>
Date: Tue, 14 Jan 2020 10:51:26 -0800

I feel like the draft explicitly says this is an error.  Here's the current text:

> 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.

Which part is obtuse?  Should I replace '...the value defined in Section 2.1.3.'  and '...smaller/larger than expected' with a restatement of the expected values?  I'm pretty sure it used to say that and we changed it to this.  Or would moving it to another section make it easier to find?  

Regarding whether this is a functional or performance bug, I expect many implementations won't parse the header block until the RIC is met, so the encoder can cause the decoder to block a stream indefinitely.  This can lead to other poor compression performance effects, but I don't think it can cause an actual deadlock on any request other than the one with the bad RIC, which is the encoder's fault anyways.  Maybe a security consideration recommending timeouts for this case?  

-- 
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-574318635

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jan 2020 15:02:58 -0800

Which value matches the Required Insert Count?  I think that you mean that the Required Insert Count value and the lowest index found in the block have to be equal.  If the lowest index found is smaller than RIC, then MUST; else if lowest > RIC, then MAY.

Does that help clarify?

-- 
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-574897773

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 Jan 2020 09:15:52 -0800

I think it already *says* the right thing, but I agree that "the value defined in Section 2.1.3 is a bit opaque.  IIRC, you're right that it was the result of a compromise.  It would probably be clearest to have another defined term, but we have a lot of those already.

-- 
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-575716113