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: Peter Lepeska <bizzbyster@gmail.com>
Date: Wed, 6 Nov 2013 13:46:27 -0500
Message-ID: <CANmPAYF32_7DQ5bfz2LGKaMGY02qrwsx9uEdVsiLTRYqpj_kRQ@mail.gmail.com>
To: James M Snell <jasnell@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>
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,          |
>
Received on Wednesday, 6 November 2013 18:46:54 UTC

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