RE: Call for Consensus: Remove "reference set" from HPACK (to address #552)

On Monday,14 July 2014 10:41, grmocg@gmail.com wrote:
> The reference set has little or nothing to do with any of the other protocol
> changes or issues on the table right now. It has been incorrectly conflated with
> other issues.
>

I thought Mark made it a separate issue so as to _purposely_ not to conflate it with other issues.


> The reference set does not decrease efficiency.
>

Kazu didn't say it decreases efficiency.  His data just showed that it was *equivalent* to Linear+Huffman for the available data set (admittedly small).

Furthermore, in all of the replies to this thread, nobody has said anything about efficiency.  The words that have been associated with the reference set have been "tricky" or "difficult".

Making a "tricky" feature mandatory with no immediately obvious benefit doesn't seem like a good idea.

- "Do not add new functionality unless you know of some real application that will require it." [1]
- "If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution." [1]


> The reference set can substantially increase efficiency in some cases

Data please.


> , and is
> likely to do so in the common case if senders adapt to the compression.
>

Speculative (though I agree).


>
> *     To make interleaving possible, *all* state referring or state modifying
> opcodes must not be permitted to cross a frame boundary.
> *     Interleaving of headers would create a huge DoS hole, and would be a
> poor design decision in the first place as it creates an obvious and easily
> exploitable DoS surface area which is proportional to the maximum allowed
> header size times the number of allowed concurrent streams.

I think I'm convinced of this point, which is why I support the 'Greg et al' proposal that requires the header block to be in a single frame.


> *     Ordering of ':' headers first is possible using the current spec,
> unchanged.-- we had chosen not to require it solely as it could decrease
> efficiency.
> *     Maintaining the order of headers is possible with HPACK as it exists
> today. Again, we had chosen not to require it solely as it could decrease
> efficiency.
>
> Are there any other technical problems we have with the reference set?
>
> If we're stepping back and redesigning the compressor, there are other things I'd
> change that would increase efficiency,
>

I think everybody would love to hear your ideas.


> and make the use of the reference set
> optional for encoders (and decoders have the easy part anyway).
>

I think optional would be OK, but I would like to see it optional from the peer's point of view (which is how the rest of the settings already are)  i.e. a client can't use it until the server declares support


[1] http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Design_principles



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Monday, 14 July 2014 09:50:40 UTC