- From: James M Snell <jasnell@gmail.com>
- Date: Wed, 6 Nov 2013 10:04:34 -0800
- 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