Re: Suggestion for simplified HTTP 2.0 header compression algorithm

Okay thanks. I really like the idea in general and I think it could be
further optimized without adding a lot of complexity. And, on the other
hand, could be made still simpler without sacrificing a lot of performance.

Peter


On Wed, Nov 6, 2013 at 1:04 PM, James M Snell <jasnell@gmail.com> wrote:

> I generated some last spring that would be out of date now. I need to
> update my impl and re-generate the numbers... just haven't had a great
> opportunity to do so yet, and with primary focus on hpack, there
> hasn't been a strong justification yet for allocating the time.
>
> On Wed, Nov 6, 2013 at 10:01 AM, Peter Lepeska <bizzbyster@gmail.com>
> wrote:
> > 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> 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,          |
>