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

Re: Suggestion for simplified HTTP 2.0 header compression algorithm

From: James M Snell <jasnell@gmail.com>
Date: Wed, 6 Nov 2013 10:04:34 -0800
Message-ID: <CABP7RbfwmHR1aJ=gFwSFjgZ0eF0V9oBuoredNixOd_gZ04gYrQ@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Michael Sweet <msweet@apple.com>, Hans Spaak <hans.spaak@ericsson.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Robert Skog <robert.skog@ericsson.com>, Thorsten Herber <thorsten.herber@ericsson.com>
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,          |
Received on Wednesday, 6 November 2013 18:05:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC