Subject: QPACK Design Input Needed

From: Alan Frindell <[email-masked]>
Date: Wed, 28 Mar 2018 23:59:47 +0000

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.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 29 Mar 2018 04:04:10 +0000

I vote “not important.”

 - Dmitri.

________________________________
From: QUIC <[email-masked]> on behalf of Alan Frindell <[email-masked]>
Sent: Wednesday, March 28, 2018 7:59:47 PM
To: QUIC WG
Subject: QPACK Design Input Needed

Which do you prefer?

Thanks

-Alan

---

From: Roberto Peon <[email-masked]>
Date: Thu, 29 Mar 2018 15:35:05 +0000

Agreed: backwards compatibility is less important that the benefit.

For one thing, being not exactly backwards compatible sets a good precedent w.r.t. future changes.

-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Dmitri Tikhonov <[email-masked]>
Date: 3/28/18 9:04 PM (GMT-08:00)
To: Alan Frindell <[email-masked]>, QUIC WG <[email-masked]>
Subject: Re: QPACK Design Input Needed

I vote “not important.”

 - Dmitri.

Which do you prefer?

Thanks

-Alan