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

[Nicholas Hurley <[e-mail]>]

I'm a big -1 on both of those options. They are both rather significant
changes that have no proof of viability behind them, and are even larger
changes than the one Jeff proposed (and in my estimation - take that for
what you will - have no place being considered at this stage of the
process). Note: this does not in any way mean I'm any more positive on
Jeff's proposed change.

On Mon, Oct 6, 2014, at 23:26, Mark Nottingham wrote:
> Thanks, Willy.
> 
> Everyone, please extend the straw poll to include these two options --
> who prefers one of them as the solution?
> 
> Regards,
> 
> 
> On 7 Oct 2014, at 5:16 pm, Willy Tarreau <[e-mail]> wrote:
> 
> > On Tue, Oct 07, 2014 at 04:54:01PM +1100, Mark Nottingham wrote:
> >> Willy, if you have a concrete proposal that you think can can strong
> >> consensus, please make it ASAP. Stopping the work to do research on whether a
> >> change is necessary isn't appropriate at this point in the work; that train
> >> left the station a while ago.
> > 
> > I have proposed two directions in July and was told it was already too late.
> > I'm sorry for not having accurate details anymore in my mind 3 months later,
> > but that was the first one :
> > 
> >       http://article.gmane.org/gmane.ietf.http-wg/23155
> > 
> > "
> > I'm noticing that we need only 4 bits to send any possible static header+value
> > (assuming we swap accept-charset and accept-encoding), since all other values
> > are empty and will never be used as-is but as litterals.
> > 
> > So I think that based on your suggestion to split indexing of static and
> > dynamic, I'm suspecting we could systematically split indexes between static
> > and dynamic in opcodes. Indeed, some index fields are already small (6+ for
> > litterals and 4+ for litterals not indexed/never indexed), so having the
> > static first will force one extra byte for all dynamic headers. However,
> > stealing one bit in unused value ranges could help make that situation
> > better. Something along these lines seems possible (please forgive me for
> > errors, I'm encoding as I write) :
> > 
> >  11 XXXXXX => send 6+indexed header from *dynamic* table as-is  (0xC0 reserved)
> >  10 01XXXX => send 4+indexed header from *static* table as-is   (0x80 reserved)
> > 
> >  00 00XXXX => send 4+indexed *dynamic* header without indexing (unchanged)
> >  10 00XXXX => send 4+indexed *static* header without indexing
> > 
> >  10 1XXXXX => send litteral based on *dynamic* header table (0=new name or reserved)
> >  01 XXXXXX => send litteral based on *static* header table (0=new name)
> > 
> > The idea is that even when we have few bits to encode the index, we're not
> > forced to add an extra byte to encode the values from the other table, whatever
> > table we pick first as first.
> > "
> > 
> > The second one was much simpler and Greg seems to favor it as well :
> > 
> >       http://article.gmane.org/gmane.ietf.http-wg/23201
> > 
> > "
> > If at least we had the ability to encode both static table and most recent
> > dynamic entries with a single index, I would feel better. For example you
> > can have another approach :
> >  - positive indexes = static table index
> >  - negative indexes = - dynamic table index
> > 
> > You encode (index + 10), so that you can encode up to the last 10 emitted
> > fields, and you can encode up to 54 static headers in a single byte (it's
> > just a matter of proper sorting but it's already reasonably clean). I think
> > you get the idea.
> > "
> > 
> > Greg proposed to run some tests. I really think the second one is *very*
> > easy to test in a sane environment, and represents a very small change.
> > It ensures that commonly used fields do not need an extra byte, that recently
> > indexed headers do not need an extra byte either, and that only old indexed
> > headers or rarely used static headers need one. Right now I think that some
> > of the static header fields might be less common than a number of the ones
> > that are found in the indexed table, precisely because if they're in the
> > indexed table, they're being used!
> > 
> > Regards,
> > Willy
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 


-- 
Peace,
  -Nick