Brief header compression comments

Overhead:
I would like someone to explain where the number 32 came from with
respect to per-entry overhead (it doesn't need to go into the draft,
but a quick enumeration would be good, just so I don't have to spend
the time myself ;)  All state used in an specific implementation
doesn't need to all be accounted for, and it doesn't matter that some
people use less overhead because of tweaks and CPU architecture
differences. I note that it's almost the case that a punitively large
accounting for overhead would be useful.

Eviction Strategy:
The eviction strategy needs some more text.  I would like to know the
characteristics of this choice and I think that the draft could use
this.  (This isn't critical for -00, or early implementations, but it
will affect later uptake of the spec.)

And then there are the choices:

1. The oldest entries are those that get evicted first.  I don't know
what the stats say, but this would make it hard to establish a
baseline set of fields that were unaffected by relatively volatile and
temporary stuff.  For example, most implementations are going to have
to re-push :method=GET and :method=POST regularly.  It would be good
to understand the trade-off here a little more.

2. Probably more importantly, you really want the headers that you are
referencing  most often to be those with the lowest index numbers.
That means fewer bits on the wire to reference them.  If the headers
that are most at risk of deletion are also the ones with lowest
numbers, that doesn't seem conducive to effective use of bits.  I'm
going to suggest an inversion of ordering, depending on the above.

BTW, I do like the linear arrangement, it's simple and it avoids the
need for updates based on reads from the table, which would suck.

Received on Wednesday, 26 June 2013 22:43:31 UTC