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

Header Compression Implementation Feedback

From: James M Snell <jasnell@gmail.com>
Date: Mon, 8 Jul 2013 13:33:53 -0700
Message-ID: <CABP7RbcjzwY6YgQWxRSu9zLJ6v2kwyQHyyr7t7SYOqH5e1Opow@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
So I've gone through and updated my header compression implementation
based on the current spec. Some feedback (shouldn't be too surprising
to anyone who may have followed my previous inputs on this topic)

1. I'd be *MUCH* happier without the Differential Encoding and the
Reference Set requirement. These mechanisms are designed to further
cut down on the number of bits set across the wire but they do add
complexity to the implementation that I do not feel is strictly
necessary. It would be possible to greatly simplify implementation if
Differential Encoding and the Reference Set we dropped from the
mechanism altogether at the cost of only a handful of additional bytes
per serialized header block.

2. I'd be *MUCH* happier if Eviction in the Header Table did not cause
renumbering of the existing items and if there was a fixed range of
index positions. Roberto has argued that doing so gives much worse
compression overall when dealing with lots of smaller valued headers
but my testing against the current corpus of test headers has not
demonstrated any significant problems. I will be drafting up a
modified bohe proposal that describes what I'd like to see in detail.

3. Going with the fixed range of index positions would allow us to do
away with the distinction between Literal with Incremental and Literal
with Substitution indexing. Everything would essentially be Literal
with Incremental until the fixed range is consumed, then the index
would simply rollover to reuse the existing index positions. Yes, I
get that the current scheme gives encoders more flexibility to develop
alternative algorithms for management the header table but, so far, I
do not agree that the flexibility is worth the additional complexity.

- James
Received on Monday, 8 July 2013 20:34:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC