Subject: Re-work of op-code patterns

From: RUELLAN Herve <[email-masked]>
Date: Mon, 27 Jan 2014 16:19:28 +0000

I created a new issue for better handling all the recent additions to HPACK, allowing for in-band signaling of changes in the encoding context: https://github.com/http2/http2-spec/issues/365.

With these recent additions, I think a re-working of the patterns used for the different op-code could be more efficient.
Current, we have 3 op-ocodes:
- 1 - Indexed Header
- 01 - Literal Header without Indexing
- 00 - Literal Header with Indexing

I would propose to add a 4th op-code, which would be used for signalling changes to the encoding context:
- Empty reference set
- Change maximum header table size
- Empty header table
- Padding

The new op-codes would be:
- 1 - Indexed Header
- 010 - Literal Header without Indexing
- 011 - Encoding context change
- 00 - Literal Header with Indexing

I did some quick testing, and changing the op-code for Literal Header without Indexing has only a very small impact on the compaction size.
- For the mnot test-set: going from 29.62% of HTTP/1.1 size to 29.64.
- For the hruellan test-set: going from 21.65% to 21.68%.

I think this is a cleaner approach with a negligible compression cost.

Hervé.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 27 Jan 2014 08:43:16 -0800

With the proposed change what would 0b1000000 signal?

If we are going to add a new opcode, I'd prefer to see the literal header
encodes both start with the same symbol:

1 - Indexed Header
00 - Encoding context change
010 - Literal Header without Indexing
011 - Literal Header with Indexing

Though I'm not sure why this is necessary -- seems like 0x80 is a clean
enough signal and can be followed by an arbitrary set of control opcodes
without expanding the compression size.

On Mon, Jan 27, 2014 at 8:19 AM, RUELLAN Herve
<[email-masked]>wrote:

> I created a new issue for better handling all the recent additions to
> HPACK, allowing for in-band signaling of changes in the encoding context:
> https://github.com/http2/http2-spec/issues/365.
>
> With these recent additions, I think a re-working of the patterns used for
> the different op-code could be more efficient.
> I did some quick testing, and changing the op-code for Literal Header
> without Indexing has only a very small impact on the compaction size.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jan 2014 09:38:36 -0800

> With the proposed change what would 0b1000000 signal?

An indexed header field, the first one.

> encodes both start with the same symbol:

The problem with your proposal is that it takes a rare condition
(Encoding context change) and assigns a shorter opcode to it.  The
cost is that header indexes greater than 30 will take an extra byte.
If you really want this, run the numbers and let us know what it
costs.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 27 Jan 2014 09:49:06 -0800

On Mon, Jan 27, 2014 at 9:38 AM, Martin Thomson <[email-masked]>wrote:

> Indexes start at 1, so 0x80 is not a valid indexed representation -- that
is why it was chosen for "clear reference set." To be clear, my proposal is
that state changes to the table (a rare condition) and any padding (a
purposely increased compressed size) are signaled by 0x80 followed by a new
set of opcodes. This requires no changes to the existing opcodes and incurs
no penalty to compression when not modifying the state.

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 28 Jan 2014 17:05:20 +0000

I ran the number, but they were maybe hidden at the end of my proposal.
Here there are again, with more details:

Mnot test set:
		Req	Res	All
Current		24,62%	37,53%	29,62%
Proposal	24,66%	37,53%	29,64%

Hruellan test set:
		Req	Res	All
Current		17,89%	26,34%	21,65%
Proposal	17,96%	26,34%	21,68%

So there is a compaction loss, but it's mostly negligible.

It is also probably easier for handling padding inside HPACK.

Hervé.

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: lundi 27 janvier 2014 18:39
> To: Jeff Pinner
> Cc: RUELLAN Herve; [email-masked]
> Subject: Re: Re-work of op-code patterns
>