Re: Re-work of op-code patterns

I'd prefer not to overload static index +1, mostly because I don't want to
hide a possible off-by-one error in interop testing if the table sizes
become out of sync.


On Wed, Feb 12, 2014 at 7:19 AM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

>
>
>
> On Wed, Feb 12, 2014 at 8:57 PM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr
> > wrote:
>
>> I'm somewhat annoyed of using two bytes to clear the reference set: this
>> decrease the usefulness of it, and I think it can be very useful in the
>> aggregating proxy use-case.
>>
>> However, I agree that changing the op-codes may not be the best solution.
>> But there's another possibility:
>> - use index 0 to encode that the reference set is cleared.
>> - use the first index after the static table to encode that the header
>> table size is changed.
>>
>> As a result, we need only one byte to clear the reference set. For
>> changing the header table size, one or two bytes will be needed in addition
>> of encoding the actual new size. This is possibly a slight increase in
>> size, but I think that header table size change will not be very common.
>>
>> If there's no strong opinion against this, I'd like to include it in
>> HPACK-06 which is almost ready to go.
>>
>>
> I don't have strong objection against the proposed solution, but the
> current Editor's copy version feels more natural to me. Using last static
> index + 1 is a bit hackish.
> Does the extra 1 byte for clearing reference set really matter?
>
> Best regards,
> Tatsuhiro Tsujikawa
>
>
>
>
>> Hervé.
>>
>> > -----Original Message-----
>> > From: RUELLAN Herve [mailto:Herve.Ruellan@crf.canon.fr]
>> > Sent: mardi 28 janvier 2014 18:05
>> > To: Martin Thomson; Jeff Pinner
>> > Cc: ietf-http-wg@w3.org
>> > Subject: RE: Re-work of op-code patterns
>> >
>> > I ran the number, but they were maybe hidden at the end of my proposal.
>> > Here there are again, with more details:
>> >
>> > Mnot test set:
>> >               Req     Res     All
>> > Current               24,62%  37,53%  29,62%
>> > Proposal      24,66%  37,53%  29,64%
>> >
>> > Hruellan test set:
>> >               Req     Res     All
>> > Current               17,89%  26,34%  21,65%
>> > Proposal      17,96%  26,34%  21,68%
>> >
>> > So there is a compaction loss, but it's mostly negligible.
>> >
>> > It is also probably easier for handling padding inside HPACK.
>> >
>> > Hervé.
>> >
>> > > -----Original Message-----
>> > > From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> > > Sent: lundi 27 janvier 2014 18:39
>> > > To: Jeff Pinner
>> > > Cc: RUELLAN Herve; ietf-http-wg@w3.org
>> > > Subject: Re: Re-work of op-code patterns
>> > >
>> > > On 27 January 2014 08:43, Jeff Pinner <jpinner@twitter.com> wrote:
>> > > > With the proposed change what would 0b1000000 signal?
>> > >
>> > > An indexed header field, the first one.
>> > >
>> > > > If we are going to add a new opcode, I'd prefer to see the literal
>> header
>> > > > encodes both start with the same symbol:
>> > >
>> > > The problem with your proposal is that it takes a rare condition
>> > > (Encoding context change) and assigns a shorter opcode to it.  The
>> > > cost is that header indexes greater than 30 will take an extra byte.
>> > > If you really want this, run the numbers and let us know what it
>> > > costs.
>>
>
>