Subject: Compression ratio of HPACK.

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 30 Jan 2014 14:07:07 +0900 (JST)

Hi,

I implemented 6 kinds of HPACK 05 encoding and calculated compression
ratio with the help from the Japanese HTTP/2 community. I wrote a blog
article on it.

	http://d.hatena.ne.jp/kazu-yamamoto/20140129/1391057824

In short, reference set saves only 1.57 byte per HEADERS frame in
average. So, I would suggest the designers to remove reference set.

If you guys want to calculate compression ratio with other data set,
please let me know.

--Kazu

---

From: Adrian Cole <[email-masked]>
Date: Thu, 30 Jan 2014 07:27:49 -0800

Really interesting, Kazu.  I would love to cut out gears if we are only
saving a byte and a half.  Can someone else who profiled hpack review this
data and conclusion?

-A

---

From: Roberto Peon <[email-masked]>
Date: Thu, 30 Jan 2014 10:36:37 -0800

As mentioned before, but probably not enough, much of the value for this
part is expected to show up in the future as people adapt to the
compression by reusing header fields, and/or by using push.

-=R

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 31 Jan 2014 13:55:15 +0900 (JST)

Hi,

> saving a byte and a half.

I added appendix to describe the difference between Naive and Linear
by examples.

And one correction: it appeared that :authority values are mixed
together in our data set. So, please suggest better input data set.

As describe in
	https://github.com/http2jp/hpack-test-case
our data set comes from
	https://github.com/http2/http_samples

--Kazu

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 31 Jan 2014 08:22:14 -0800

Just to sanity check I navigated to www.google.com -- the page load made 11
requests, each with the same 8 identical cookies. Thus the reference set in
this example saves 8 bytes per frame (as opposed to the 1.57 bytes in your
analysis).

I'd suggest trying to capture data on a single domain to show the affect
the compression has on repeated cookies.

---

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

> the compression has on repeated cookies.

Here I was being pleased at how much like a real-world middleware
traffic that test was.

Good example results for what we middleware people have been saying
about the compression, TLS, etc. having very little benefit compared to
the amount of CPU/RAM resource consumption required to maintain the state.

PS. The HTTP/2 test data so far appears to have been very biased towards
traffic as seen on connections which are terminated at a origin server
or browser / UA client simply by being grouped by :authority. Traffic as
seen by middleware is much more volatile.

Amos

---

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

> the amount of CPU/RAM resource consumption required to maintain the state.
For middleware boxes that do connection coalescing for multiple clients it
is almost certainly true that without the ability to divide the reference
set into groups (a feature that was dropped to its imagined complexity),
the best thing to do is to clear the reference set before each header set.
That's why the opcode was added to do just that.

---

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

Jeff,

> this example saves 8 bytes per frame (as opposed to the 1.57 bytes in your

I think you should also consider how many headers are different (to be
deleted and be added). See the following example:

Old   New
1         to be deleted
2         to be deleted
3     3   common
4     4   common
5     5   common
6     6   common
      7   to be added

In this case, we cannot save four bytes. We need to sent two bytes for
deleting and one byte for adding. So, we can save just one byte.

P.S.

Even we can save 8 bytes in average in the real world, I don't think
it contributes to reduce the number of IP packets to be generated.

--Kazu