Re: Header Compression...

Based on feedback I have received offlist and implementation
experience, I have made a few additional modifications to the proposed
alternative "Stored Header Encoding" draft.

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

This offers a significantly less-complex alternative to the current
Header Compression mechanism at the cost of a few additional bits on
the wire. The changes I have made to this draft include combining
"Literal Replacement" and "Literal Incremental" into a single
representation. I also made a few editorial improvements here and
there.

As always, comments and feedback are definitely welcome.

- James

On Tue, Aug 6, 2013 at 11:49 AM, James M Snell <jasnell@gmail.com> wrote:
> 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 Wednesday, 14 August 2013 19:34:11 UTC