Re: Straw Poll: Restore Header Table and Static Table Indices

[Greg Wilkins <[e-mail]>]

Roberto,

I do understand that you and Jeff would prefer the compression bias to be
towards dynamic headers, but what I don't understand is the strength of
that preference.      You are so strongly in favour of reverting the
indexing that I feel that I must be missing something?   The compression
achieved by hpack regardless of the indexing is excellent.

I know that Mark is heavily leaning towards WONTFIX on this one - but I'd
be very interested to hear your thoughts on the proposed compromise of
reducing the size static table so that there are at lease a few 1 byte
index's available for dynamic headers and dynamic header names.  If we
opened up say 8 slots to be available for 1 byte dynamic index's (and added
static values at the same time), do you feel that would go some way to
addressing your concerns, or would it still be insufficient?    Do you have
some example header sets you can share with me so I can do some
experimentation?

To respond to your specific points:  I think that "highly suboptimal" is
over stating the situation.   Dynamic headers can still be reduced to a 2
byte index, which is a vast improvement over http/1.   There was technical
evaluation using the available test data an it did show a general
improvement with the low static indexes and that variations were essential
down among the noise considering the huge savings both approaches already
achieve.

I believe I have explained how the new scheme has allowed significant CPU
and memory savings in my server and there have been reports from other
implementers of code savings.     I cannot prove that such savings are only
available with the low index, and theoretically I might be able to achieve
some of them with reverted indexing.  However the reality we were not able
to achieve those savings with the high static indexing, despite there being
significant benefits if we could (and we did try). We have been able to
achieve them with the low index's.  I know this is not proof, but I think
it is good circumstantial evidence.

regards








On 13 October 2014 03:28, Roberto Peon <[e-mail]> wrote:

> The current mechanism is highly suboptimal when not using the headers in
> the static table.
>
> There has been no technical argument refuting this-- all arguments have
> shown that the previous arrangement was approximately on par for
> static-table heavy workloads in terms of compression efficiency.
>
> We have no guarantee that users will always wish to use the arguments in
> the static table.
> We know that adding to the size of the static table decreases efficiency
> of the compressor for any item that would not be in the static table.
>
> No-one has shown that the new scheme is significantly better in terms of
> CPU or memory.
>
> There was no interop issue w.r.t. the previous text.
>
> In fact, the previous text allowed for the static table to be changed
> easily in future versions, with guaranteed detection of mismatch when new
> elements have been appended to the static table by one implementation but
> not the other. This is not true of the current version, which would require
> a negotiation in order to figure any such things out, and would otherwise
> result in corruption.
>
>
> As currently specc'd we're half-assing the compression, and we already
> know a better solution and have specc'd, implemented and demonstrated
> interop with it.
> -=R
>
> On Sat, Oct 11, 2014 at 11:59 PM, Mark Nottingham <[e-mail]> wrote:
>
>> There doesn't seem to be support for making a change here; most people
>> were against any change, and while there were a few other proposals made,
>> they didn't get broad support. Since this isn't a security or interop
>> issue, I'm inclined to close as WONTFIX.
>>
>> Does anybody have new information here, or can we move on?
>>
>> Cheers,
>>
>>
>> On 7 Oct 2014, at 6:23 am, Mark Nottingham <[e-mail]> wrote:
>>
>> > Thanks, Jeff.
>> >
>> > I see people have already started to respond to this.
>> >
>> > Everyone else, please do the same — if you think this needs more
>> discussion, please do so, but I think we’re at a point where people can
>> just state their preferences.
>> >
>> > Regards,
>> >
>> >
>> > On 7 Oct 2014, at 2:02 am, Jeff Pinner <[e-mail]> wrote:
>> >
>> >> As request by Mark, I propose that the current HPACK draft be changed
>> >> such that Sec. 2.3.3 Index Address Space reads,
>> >>
>> >> "Indices between 1 and the length of the dynamic table (inclusive)
>> >> refer to elements in the dynamic table.
>> >>
>> >> Indices strictly greater than the length of the dynamic table refer to
>> >> elements in the static table. The length of the dynamic table is
>> >> subtracted from the index into the static table."
>> >>
>> >> with the associated diagram updated. This reverts the change made
>> >> between draft -08 and -09 in the change log, "Exchanged header and
>> >> static table positions."
>> >>
>> >
>> > --
>> > Mark Nottingham   http://www.mnot.net/
>> >
>> >
>> >
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>
>


-- 
Greg Wilkins <[e-mail]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.