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

[Willy Tarreau <[e-mail]>]

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