W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Mon, 7 Oct 2013 16:46:54 +0000
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
CC: Mike Bishop <Michael.Bishop@microsoft.com>, Gábor Molnár <gabor.molnar@sch.bme.hu>, Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E52F4F4B4F@ADELE.crf.canon.fr>
> -----Original Message-----
> From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
> Sent: samedi 28 septembre 2013 16:36
> To: RUELLAN Herve
> Cc: Mike Bishop; Gábor Molnár; Roberto Peon; ietf-http-wg@w3.org
> Subject: Re: HPACK benchmark test for substitution indexing vs incremental
> indexing only
> 
> 
> 
> 
> On Sat, Sep 28, 2013 at 1:34 AM, RUELLAN Herve
> <Herve.Ruellan@crf.canon.fr> 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é.
Received on Monday, 7 October 2013 16:47:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC