Subject: RE: HPACK benchmark test for substitution indexing vs incremental indexing only

From: RUELLAN Herve <[email-masked]>
Date: Mon, 7 Oct 2013 16:46:54 +0000

> -----Original Message-----
> From: Tatsuhiro Tsujikawa [mailto:[email-masked]]
> Sent: samedi 28 septembre 2013 16:36
> To: RUELLAN Herve
> Cc: Mike Bishop; Gábor Molnár; Roberto Peon; [email-masked]
> Subject: Re: HPACK benchmark test for substitution indexing vs incremental
> indexing only
> 
> 
> 
> 
> On Sat, Sep 28, 2013 at 1:34 AM, RUELLAN Herve
> <[email-masked]> wrote:
> 
> 
> 	I've ran some tests on the "mnot" test set and I've been able to see
> some effect from using substitution:
> 	- Substituting compressor:   29.5%
> 	- Append-only compressor: 30.3%
> 
> 
> 
> 
> Since these numbers are much better than the my results (which is 39% and
> 37% respectively), I'm very interested in the algorithm you used to achieve
> them.
> 
> Could you share it with us?
> Is it some kind of algorithm to take advantage of the complete knowledge of
> incoming headers?
> Or based on statistics on today's web traffic?

I'll try to publish my algorithms. They do nothing fancy and are rather simple.

> Note that my results combine request and response headers.

My results also combine the figures for request and response headers. They were generated using the http2 compression testing framework (https://github.com/http2/compression-test).
The differences may come from the condition of the test, in particular in the way the testing framework group messages into different "HTTP/2.0 sessions".

> Because of relative difference is small, I'm lean to the side to remove
> substitution for now.
> Mostly it is because the decoder have to pay for it. The encoder can just skip
> substitution if it wants, but decoder has no choice.

By tweaking my substituting compressor, I'm able to get more compaction. On long-running connections, the difference between the two compressors is greater, and on some test cases, the substituting compressor can be 3 or 4 points lower than the Append-only compressor.

I think that the substituting compressor offers some potential room for future compaction improvement. 

Best regards,

Hervé.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 7 Oct 2013 12:16:46 -0700

We still need to change the place the incremental indexing gets indexed--
it needs to be indexed at 0. This made a noticable change in the output
(>1%) on an older compressor.
-=R

On Mon, Oct 7, 2013 at 9:46 AM, RUELLAN Herve <[email-masked]>wrote:

> My results also combine the figures for request and response headers. They
> were generated using the http2 compression testing framework (
> https://github.com/http2/compression-test).
> The differences may come from the condition of the test, in particular in
> the way the testing framework group messages into different "HTTP/2.0
> sessions".
>
> By tweaking my substituting compressor, I'm able to get more compaction.
> On long-running connections, the difference between the two compressors is
> greater, and on some test cases, the substituting compressor can be 3 or 4
> points lower than the Append-only compressor.
>