incrementally indexed headers should be inserted in index '0' instead of len(table)+1

https://github.com/http2/http2-spec/issues/233

####  summary of github issue chatter ###

Currently, index 0 is the 'top' of the table, and when a new header is
added using incremental indexing, it is added at the 'bottom' (i.e. the
highest number index).

This is potentially problematic from a compression-efficacy standpoint--
data analysis shows that newly added items are the most likely to be reused
or removed from the reference set, and thus most likely to be referred to
again.

This implies that we should change the spec to insert headers inserted via
incremental indexing into position '0' (i.e. the top)

 jpinner commenteda day ago

Does this also imply that eviction should occur from the "bottom" of the
table?

 grmocg commented21 hours ago

eviction from the bottom == oldest entry dies first when all one is using
is incremental indexing.

With substitution indexing, that isn't true. I'm happy with either one, but
I imagine that Herve might prefer one over the other.

 grmocg commented21 hours ago

And I'm fine with either, because I intend to only do incremental indexing,
since my research as shown it to be as good or better than substitution (at
least so far), and because I know that incremental indexing is suitable to
use in a world where we have something like TCP-minion or SCTP doing
out-of-order-delivery without HOL blocking at the compressor (with a couple
of small modifications).

 jpinner commented21 hours ago

Does the small modification require you to expose the sequence number?

 grmocg commented21 hours ago

Precisely!

 jpinner commented20 hours ago

An argument to drop substitution indexing from the spec?

 grmocg commented20 hours ago

Thusfar, we're assuming TCP transport, and I can imagine that substitution
has the capacity to help out there, but I imagine it wont help on
substrates like TCP-Minion, SCTP, etc. On those transports substitution
indexing probably hurts more than it helps.

#### end summary of github issue chatter ###


We absolutely should not close this issue without ensuring Herve has a
chance to chime in, but we can discuss for now. I can attempt to channel
Herve as much as possible in the interim (it will be a poor imitation
indeed, but better than nothing).

-=R