Re: Suggestion for simplified HTTP 2.0 header compression algorithm

Do you have any numbers on performance of BOHE? Be nice to get performance
numbers vs HPACK for the same max memory setting and the same HTTP header
data set.

Peter

On Wednesday, November 6, 2013, James M Snell wrote:

> On Wed, Nov 6, 2013 at 9:16 AM, Mark Nottingham <mnot@mnot.net<javascript:;>>
> wrote:
> >[snip]
> > I’m surprised to hear you say that. In all of the discussions I’ve been
> a part of, the emphasis has been on balancing compression efficiency and
> complexity, with a bias towards simplicity (and a constraint of security).
> Pretty much everyone acknowledges that HPACK is more complex than we’d
> like, but we don’t yet have an alternate proposal that’s gathered more
> interest.
> >
>
> Just a personal opinion, really. Take it for what it's worth.
>
> > The concerns I’ve heard about BOHE are that it requires knowledge of
> individual headers when sending, and that it adds complexity. We haven’t
> yet ruled it out; the issue you raised is still open, but the approach so
> far has been to see how well delta coding works before considering adding
> other techniques or replacing it.
> >
>
> FWIW, it does not *require* knowledge of individual headers, but does
> allow a sender that does happen to have such knowledge to leverage
> that to encode more efficiently. Once encoded, the encoding is
> self-describing with very clear processing and backwards
> compatibility.
>
> Also note, my proposal comes in two parts: a header encoding and a
> value encoding. They are distinct and do not necessarily depend on one
> another.
>
> > We’re just getting starting to get that experience with HPACK.
> >
> [snip]
>
> Note that I've backed off pushing on the bohe option while the work on
> HPACK is ongoing. I stated my concerns, offered an alternative, put it
> on the table, then backed off to see how things develop. Personally,
> HPACK is still far too complicated for my taste, but that's just one
> opinion out of many. Again, take it for what it's worth.
>
> - James
>
> >>
> >> [1] http://tools.ietf.org/html/draft-snell-httpbis-bohe-13
> >>
> >> My personal opinion is that achieving the best possible compression
> >> ratio should not be the sole deciding factor and that the currently
> >> proposed mechanism is far into the "trying to be way too clever" range
> >> and introduces far too much unjustified additional complexity. In
> >> other words, I'm very -1 on it but, thus far, I appear to be in the
> >> minority. (and yes, FWIW, I have taken the time to implement the
> >> current scheme so I'm not just speaking out of some theoretical
> >> concern).
> >>
> >> - James
> >>
> >>
> >>
> >> On Wed, Nov 6, 2013 at 5:02 AM, Michael Sweet <msweet@apple.com> wrote:
> >>> Hans,
> >>>
> >>> I am all for simplifying the current header compression algorithm,
> which is
> >>> growing needlessly complicated IMHO as people try to achieve ever
> greater
> >>> compression ratios without regard to implementation complexity or
> >>> interoperability concerns.
> >>>
> >>> That said, I don’t like the idea of putting headers in the settings
> frame
> >>> since it doesn’t play well with proxies - clients need to be able to
> direct
> >>> requests to multiple origin servers and proxies need to be able to
> >>> consolidate multiple client connections onto a single connection to the
> >>> origin server.  (it will be hard enough for the current header
> compression
> >>> scheme to work for that, but at least it is possible)
> >>>
> >>>
> >>> On Nov 6, 2013, at 4:04 AM, Hans Spaak <hans.spaak@ericsson.com>
> wrote:
> >>>
> >>> Hello,
> >>>
> >>>
> >>>
> >>> The proposed header compression algorithm is rather complicated and we
> >>> foresee that  there will be at least initially a lot of interworking
> >>> problems
> >>> when different compressor and de-compressor implementations need to
> work
> >>> together.
> >>> We experienced those problems when the equally complicated WAP1.x
> header
> >>> compression was implemented.
> >>>
> >>>
> >>>
> >>> Here is our proposal for simplifying how headers are compressed in
> HTTP/2.0.
> >>>
> >>> It does not compress as hard as the currently proposed solution (if the
> >>> encoder is written in a very smart way),
> >>>
> >>> but it is much easier to implement.
> >>>
> >>>
> >>>
> >>> Please have a look at it and comment.
> >>>
> >>>
> >>>
> >>> Exchange of static headers, which are the same for one TCP connection:
> >>>
> >>>
> >>>
> >>> The SETTINGS frame is used to transmit the static request and response
> >>> headers.
> >>>
> >>> The HEADERS frame is used to transmit the dynamic request and response
> >>> headers.
> >>>
> >>> Static headers and dynamic headers are combined in the following way:
> >>>
> >>> 1.       Emit the dynamic headers.
> >>>
> >>> 2.       Emit the static headers whose header names are not present in
> the
> >>> dynamic headers.
> >>>
> >>>
> >>>
> >>>                         Client                        Server
> >>>
> >>>                           |                             |
> >>>
> >>>                           |SETTINGS                     |
> >>>                           | - static request headers    |
> >>>                           |   (:method, :host,          |