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

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.

The reference set does not decrease efficiency.
The reference set can substantially increase efficiency in some cases, and
is likely to do so in the common case if senders adapt to the compression.

   - 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.
   - 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, and make the use of the
reference set optional for encoders (and decoders have the easy part
anyway).

It doesn't make sense to me to remove it unless we believe that the
use-cases it potentially solves are not going to happen.

The reference set makes server-push more efficient (and it can be
substantially more efficient with its use).
It makes non-browser workloads more efficient.
It makes proxy communication more efficient when demuxing/muxing is done
properly by the loadbalancing proxy (i.e. it creates connections properly
to its targets).

-=R


On Mon, Jul 14, 2014 at 12:35 AM, Kazu Yamamoto <kazu@iij.ad.jp> wrote:

> >> I think that the index for static table and one for dynamic table can
> >> be separated. If we take such a design, HPACK implementation would get
> >> simpler.
> >
> > Could you elaborate your idea?
> > I guess you have new index opcode for static table but it is not
> sufficient.
>
> What I thinking is to use two tables separately.
>
>           <-- Header  Table -->  <-- Static  Table -->
>           +---+-----------+---+  +---+-----------+---+
>           | 1 |    ...    | k |  | 1 |    ...    | 61|
>           +---+-----------+---+  +---+-----------+---+
>           ^                   |
>           |                   V
>    Insertion Point      Dropping Point
>
> Each table has its own index. Prepare necessary operations and their
> binary format.
>
> --Kazu
>
>