Re: Header Compression...

Here is an updated version of the Stored Header Encoding proposal that
includes the Typed Codecs.

http://www.ietf.org/id/draft-snell-httpbis-bohe-12.txt

I want to "officially" get this on the table as a proposed alternative
to the current header compression mechanism.

This really exists in two parts:

1. The type codecs (which can live equally well in the current header
compression mechanism)
2. The alternative header block encoding.


On Tue, Aug 6, 2013 at 9:43 AM, James M Snell <jasnell@gmail.com> wrote:
> While I was, unfortunately, unable to get my http/2 client
> implementation ready in time for the berlin interop testing, I was
> able to take time over the last month to dig into the header
> compression implementation in greater detail and I would have to say
> that while I agree that the current design offers a great compression
> profile and is technically sound for what it offers, I am definitely
> -1 on adopting the currently defined scheme as is without making
> significant changes. There are a number of reasons for this position
> that I've talked about a few times already so I won't get into those
> again.
>
> For one, as my experimentation with the Stored Header Encoding and
> typed codecs demonstrates, it is possible to achieve good compression
> ratios using a much less complicated mechanism that is more "routing
> friendly", more streaming-based, has better support for ordered values
> (see Julian's recent comments on multi-valued header fields), has
> stronger memory consumption constraints and is easier to implement.
> Granted, we end up sending a few more bytes over the wire but that's
> OK, IMHO. Sending those few additional bytes is far better, in my
> opinion, than significantly increasing the implementation complexity
> of the protocol through seemingly endless premature optimization
> (repeat after me, "Perfect is the enemy of good"...)
>
> In my opinion, the differential encoding and the reference set both
> ought to go away; the more efficient typed codecs ought to be
> introduced; and the header table ought to be limited to 256 storage
> slots so that index positions never require more than a single octet
> to represent on the wire. We can keep incremental and substitution
> indexing... In other words, some variation of what I have proposed in
> http://tools.ietf.org/html/draft-snell-httpbis-bohe-11.
>
> Yes, I fully recognize that this approach ends up sending more bits
> over the wire on average, but that's ok. There are other approaches we
> can take (e.g. better sessions) that can address that gap.
>
> - James

Received on Tuesday, 6 August 2013 18:50:34 UTC