Subject: Reasons to not use huffman encoding?

From: Adrian Cole <[email-masked]>
Date: Fri, 31 Jan 2014 09:13:30 -0800

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

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 01 Feb 2014 06:27:34 +1300

>  When, in your opinion, would the sender choose not to?

1) debugging some other part of the protocol.

2) sender device wants to save on CPU and has lots of bandwidth available.

3) using some other future encoding that is better than huffman.

Amos

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 31 Jan 2014 09:50:52 -0800

and of course

4) the huffman encoded string is larger than the original

---

From: Gábor Molnár <[email-masked]>
Date: Fri, 31 Jan 2014 19:55:01 +0100

There are cases when encoding without Huffman simply produces smaller input
(for example, if your header value consists of uncommon letters or binary
data).

---

From: Adrian Cole <[email-masked]>
Date: Fri, 31 Jan 2014 13:11:28 -0800

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 <[email-masked]>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).
>
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 31 Jan 2014 16:50:52 -0500

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 <[email-masked]> wrote:

> Thanks for the inputs.  So, seems case-by-case, with most decisions being relatively static.
> 
> 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 <[email-masked]> 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).
> 
> 
> 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

---

From: Fred Akalin <[email-masked]>
Date: Fri, 31 Jan 2014 14:11:11 -0800

30% (the number I've seen thrown around) isn't compelling?

On Fri, Jan 31, 2014 at 1:50 PM, Michael Sweet <[email-masked]> 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...
>

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Sat, 01 Feb 2014 07:39:11 +0900 (JST)

> 30% (the number I've seen thrown around) isn't compelling?

In my experiment, 31.36 bytes per HEADERS frame in average.

We should consider whether or not this contributes to reduce the
number of IP packets actually.

--Kazu

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Jan 2014 15:09:32 -0800

> In my experiment, 31.36 bytes per HEADERS frame in average.

I think that you need to express that in relative terms, which I infer
from your graphs is something a little under % (0.303 vs 0.394 for
instance).

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 1 Feb 2014 16:25:31 +1100

> 3) using some other future encoding that is better than huffman.

If that happens, we’d need to version the protocol (at least, as things currently sit), so this isn’t really a motivation for being able to turn it off.

Cheers,

--
Mark Nottingham   http://www.mnot.net/