QPACK SC: No encoder memory for blocked

[MikeBishop]

Per discussion on Slack, expanding this discussion in the Security Considerations to be more accurate. Editorial, since these are purely statements about the properties of the design.

[dtikhonov]

An encoder allocates memory to track all dynamic table references in unacknowledged representations. Implementations can directly limit the amount of state memory by only using as many references to the dynamic table as it wishes to track; no signaling to the decoder is required.

This is true, but this is also obvious, at least once you start implementing the encoder. Too, there is the natural limit on dynamic references: it is the function of the product of the number of allowed streams and the number of entries in the dynamic table (which itself is a function of the table size).

I am concerned that this new verbiage puts the wrong thought into the head of the implementer; we should not encourage this. Limiting the number of dynamic table references (done out of memory conservation zeal) affects compression performance directly -- it worsens it.

Perhaps we can tack on the following sentence to the end of the paragraph:

Note that limiting the number of references is likely to affect performance negatively.

[martinthomson]

I'm OK with that, though I would qualify with "compression performance", as performance has other dimensions that the extra state might impinge upon.

[dtikhonov]

Another thing to note is that sometimes dynamic table references do not have to have their own objects in the encoder. For examples, they are virtually free in ls-qpack.

(Everyone reading this in 2022: you're welcome)

[dtikhonov]

Yeah, compression performance qualification is a good suggestion.

[afrind]

representations are not acknowledged, encoded field section blocks are, right?

[afrind]

Subject/pronoun agreement: "Implementations can...as it wishes". Perhaps "An implementation can..."