Subject: HPACK: replace Huffman by possibly faster and more efficient FSE (Finite State Entropy)

From: Frédéric Kayser <[email-masked]>
Date: Sat, 4 Jan 2014 18:10:57 +0100

Hi,
FSE (Finite State Entropy) is a brand new entropy coder backed by Yann Collet (the guy behind LZ4) based on ANS (Asymmetric Numeral System), it could eventually be used as a interesting drop-in replacement for the Huffman encoder found in HPACK since it claims compression rates closer to arithmetic coding and faster processing than Huffman.
More informations and code over there:
http://fastcompression.blogspot.fr/2013/12/finite-state-entropy-new-breed-of.html

Best regards.
-- 
Frédéric Kayser

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Jan 2014 11:31:23 -0500

Frédéric,

Certainly looks interesting, although IMHO all of this focus on compression for HTTP/2.0 is premature - yes, we can reduce the size of the request/response headers even more, but once you get past optimizing the initial request/response (initial page load time) any further gains are just "nice to have".

Better to have a simpler HTTP/2.0 that achieves the chartered goals than to create a much harder to implement HTTP/2.0 that offers only a modest improvement in perceived performance/responsiveness.  And IMHO adding Huffman or FSE falls into the "harder to implement for a modest improvement" category.

> http://fastcompression.blogspot.fr/2013/12/finite-state-entropy-new-breed-of.html

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: James M Snell <[email-masked]>
Date: Mon, 6 Jan 2014 09:00:31 -0800

+1

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 6 Jan 2014 12:39:30 -0500

+1

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Jan 2014 10:12:20 +1300

+1.

Just to be a bit more constructive than that. I think that now we have 
the framing structure and flow controls basically operational and agreed 
we should be moving on to specific per-header changes that reduce the 
header values from verbose plain-text to something more compact prior to 
any generic block compression. For example; revisiting the earlier 
discussions of binary values in Date:. These will have a major impact on 
the efficiency testing results of HPACK and similar block compression 
proposals.

Amos

On 2014-01-07 06:39, Peter Lepeska wrote:
>>> Certainly looks interesting, although IMHO all of this focus on 
>>> compression for HTTP/2.0 is premature - yes, we can reduce the size 
>>> of the request/response headers even more, but once you get past 
>>> optimizing the initial request/response (initial page load time) any 
>>> further gains are just "nice to have".
>>> 
>>> Better to have a simpler HTTP/2.0 that achieves the chartered goals 
>>> than to create a much harder to implement HTTP/2.0 that offers only a 
>>> modest improvement in perceived performance/responsiveness.  And IMHO 
>>> adding Huffman or FSE falls into the "harder to implement for a 
>>> modest improvement" category.
>>> 
>>> 
>>>