QPACK Design Input Needed

[Alan Frindell <[e-mail]>]

We need input from the working group about the importance of HPACK compatibility versus cleanliness of QPACK.  Mike’s PR (#1141), previously mentioned on list, reorganizes the instruction space, and makes a couple other compatibility-breaking changes. 

The new instructions are cleaner[1] than re-using the HPACK instructions, and would allow us (now, or in the future), to increase the size of the static table without any negative compression impacts[2].

Re-using the HPACK instructions makes it easier to share code between an HPACK and QPACK implementation.  It would allow using an HPACK library directly in HTTP over QUIC with a zero byte dynamic table[3].  

Which do you prefer?

Thanks

-Alan


[1] QPACK has two contexts for instructions, and all HPACK instructions are only valid in one of the contexts.  QPACK makes more efficient use of the instruction space and removes any notion of an “invalid” instruction.  My one-pass encoding PR (#1239) is kind of a hack, re-using some otherwise invalid instructions when a single instruction with a flag would be a cleaner design.

[2] In HPACK all dynamic indexes are serialized on the wire offset by the static table size.  If we increased the static table size, it would cost approximately one byte per dynamic indexed header field.  Mike’s PR replaces offsetting the index with a static bit.

[3] This is not a good idea for compression in general, as it only saves about 30% of header bytes on the wire, but it is nice for anyone trying to get an HTTP over QUIC implementation off the ground.