W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Re-work of op-code patterns

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Thu, 13 Feb 2014 00:19:54 +0900
Message-ID: <CAPyZ6=LVGp9dKYtGdVz4PXKNw4i4Djvt5i+fNhqQQf5rJ8a8KA@mail.gmail.com>
To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Cc: Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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.
>
Received on Wednesday, 12 February 2014 15:20:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC