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

Re: First cut of Huffman encoding in compression document.

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Fri, 18 Oct 2013 01:44:52 +0900
Message-ID: <CAPyZ6=KiQFzEjZ3md_+=wGYEb3gWk0DTK8ghHKFx3UQ8gTH0vA@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Oct 17, 2013 at 11:17 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Wed, Oct 16, 2013 at 12:20:08PM -0700, Roberto Peon wrote:
> > The first cut of Humman encoding is now included in the compression
> > document.
> >
> > Please take a look and shout about the parts that you find
> confusing/could
> > be better expressed.
>
> - Lengths are marked as 8+. Are those 8 bit prefix or 0 bit prefix
>   (IIRC, those were 0 bit in some past versions)?
>
- Is encountering a name/value without End-Of-String an error?
> - Is encountering a name/value with more bytes after EOS an error?
>   * Appears to be string delimiter for values?
>
>
I have the same impression.

As for huffman encoding, we experimented it and achieved 0.28 compression
ratio against 0.37 in the same algorithm of HPACK-03 (using mnot data set).
So 9 points improvement.
 To achieve 0.28 compression ratio, we need large (>64K) header table
buffers with HPACK-03, so huffman does the good job.

Best regards,
Tatsuhiro Tsujikawa


> -Ilari
>
>
Received on Thursday, 17 October 2013 16:45:40 UTC

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