Re: Reasons to not use huffman encoding?

Fred,

Since the current HPACK spec already does a decent job of compressing headers just with index/replace, the 30% figure isn't a net improvement.  Based on Kazu's data, Huffman is only yielding 0.3% overall, which isn't compelling.  I personally believe that type-based encoding will yield better overall results since headers like Date are not well compressed by the current index/replace scheme, but need to finish my HPACK implementations to do some comparisons and get some real numbers to see if it is worth the trouble.

However, I'll reiterate that I believe the focus on getting the absolute best compression will only hurt HTTP/2.0 in the long run.  The key features of HTTP/2.0 - elimination of multiple network connections and disconnects after errors - are what will bring the greatest perceived improvements in performance and latency, while compression and other add-ons only serve to make implementations more complicated without providing noticeable improvements.  And there may yet be security considerations (see the HPACK analysis messages) that make today's HPACK unsafe to deploy.


On Jan 31, 2014, at 5:11 PM, Fred Akalin <akalin@google.com> wrote:

> 30% (the number I've seen thrown around) isn't compelling?
> 
> 
> On Fri, Jan 31, 2014 at 1:50 PM, Michael Sweet <msweet@apple.com> wrote:
> FWIW, I would rather not use Huffman encoding at all, just to reduce the complexity of implementation.  IMHO it doesn't offer a compelling improvement in overall header compression...
> 
> On Jan 31, 2014, at 4:11 PM, Adrian Cole <adrian.f.cole@gmail.com> wrote:
> 
>> Thanks for the inputs.  So, seems case-by-case, with most decisions being relatively static.
>> 
>> if huffmanNotDisabledDueToSomeCPUConcern
>> and worthItToCheckLengthWithAndWithoutHuffman 
>> and foundHuffmanShorter
>> huffmanEncode
>> 
>> Is that a fair summary?
>> 
>> I'm guessing that in most cases, you'll have a buffer with a known length, so above comparison is probably worth it in most cases.
>> -A
>> 
>> 
>> On Fri, Jan 31, 2014 at 10:55 AM, Gábor Molnár <gabor.molnar@sch.bme.hu> wrote:
>> There are cases when encoding without Huffman simply produces smaller input (for example, if your header value consists of uncommon letters or binary data).
>> 
>> 
>> 2014-01-31 Adrian Cole <adrian.f.cole@gmail.com>:
>> 
>> Hi, all.
>> 
>> HPACK allows the sender to decide whether or not to encode with huffman.  When, in your opinion, would the sender choose not to?
>> 
>> -A
>> 
>> 
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair