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

It's a separable decision, but not a separable concern.



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

Does anybody truly believe the data is representative of the broad web, and
the usage patterns that occur there? I don't. For example, the effect of
cookie crumbs is tremendously under-represented.
I also don't believe the data represents the easy, low-hanging fruit that
will likely be optimized upon HPACK deployment (eg, quantize the Date
header with courser granularity).


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

I'm unsympathetic to this. SPDY uses deflate for headers, which is far more
complicated under the hood. The choice of compressor is orthogonal to
whether each implementer must go and implement it. Multiple implementations
are available under permissive licenses, as has been pointed out on this
list.

Meanwhile, we have actual operational experience with multiple implementers
who have built out the reference set. We've already turning it on for real
users. I have yet to get a bug report for it. Granted I may, but my
experience to date is that it's not the landmine it's being painted as.


> The reference set can substantially increase efficiency in some cases
>
> Data please.


Chromium has offered to do a study on this. That offer received no response
or endorsements.

It would still be interesting to do, but only if there's honest engagement
and buy-in from the list. Setting up something like this takes time, and is
not compatible with the rate-of-change in arguments we're seeing on the
list lately.



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


Let's *not* open this can of worms. Let's finish.