Re: I ran across this while working on the spec.

We most definitely want to be able to clear out all compression state.

An example use-case is that we'll have long-lived connections from just
about any client that wants server-side notifications. Leaving lots of
memory lying about unused (~99% to ~99.9% of the time things are idle) has
strongly negative utility. I'd rather use that memory to have larger
compression contexts for connections which are active, or to allow more
connections, or, in the case of mobile devices, to yield more memory to
actively running processes.

So, it would be a very good thing to be able to completely de-allocate the
compression context until communication is going on.
Terminating the connection is not a desirable mechanism for accomplishing
this, as it requires both significant latency and significant CPU to
reconnect. Reconnecting implies a worse experience for all users, and for
mobile devices also implies decreased battery life. Ick/should be avoided.


#1 strictly bounds the amount of memory used. I do like that a lot.
  I'd imagine that #1 would be specified approximately as:
     Evict entries normally as per eviction rules.
     if size(header table) is zero, size(header context) >
MAX_HEADER_CONTEXT_SIZE, evict the highest indexed reference from the
reference set.
  if MAX_HEADER_CONTEXT_SIZE is zero, then the receiver side need never
allocate a header context/may completely deallocate it.

  MAX_HEADER_CONTEXT_SIZE would replace MAX_HEADER_TABLE_SIZE. We'd still
use only one setting (just rename it).

#2 is fairly clean, and would be a close-second choice. This perhaps
minimizes complexity. I could be made to like this one :)
    I'd assume that the mechanism to accomplish #2 would be a setting which
toggles whether or not the reference set is allowed to have any elements.
    Thus, if HEADER_TABLE_SIZE is 0 and REFERENCE_SET_DISABLED is true, the
receiver is guaranteed to require no compression context.
     The main thing I dislike about this option is that it requires another
setting. The main advantage is that this is essentially all it requires.

#3 doesn't solve the problem better than #2, as we'd still need something
like #2 for the decoder-side to signal to the encoder-side that it would
like this state to be cleared.

#4 is less clean than #2, but I prefer it to #3, as it is also a complete
solution.
    We would also need to specify that this implies that one cannot add
elements to the reference set when the size is zero (essentially, the same
mechanism used for adding entries to the header table which don't fit).

There is another option as well:

#5 When referencing an element from the static set, instead of inserting a
reference to the static-table entry, instead copy the element into the
header table and add a reference to it there.
     References stored in the reference set must point only to elements of
the header table with this option.

   This solves the problem without requiring any additional signaling, but
at the cost of worse compression, and increased CPU consumption (copying).

-=R


On Thu, Oct 17, 2013 at 7:34 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

> I'm wondering if we want to be able to clear out all compression state. We
> currently have 59 entries in the static table, meaning 8 bytes to store
> whether they are in the reference set or not.
>
> I we want this, I think #1 is too complex.
>
> It means that sending an index (therefore adding a new entry to the
> reference set) may trigger an eviction.
>
> We have several other solutions for this:
> - #2
> - 3 Adding the possibility of clearing the reference set inside a header
> block.
> - 4 Having a special rule for a max header table of 0, stating that this
> clears all the compression state.
>
>
> My preference is for 2 or 3.
>
> Hervé.
>
>
> > -----Original Message-----
> > From: Fred Akalin [mailto:akalin@google.com]
> > Sent: jeudi 17 octobre 2013 04:10
> > To: Roberto Peon
> > Cc: ietf-http-wg@w3.org Group
> > Subject: Re: I ran across this while working on the spec.
> >
> > (copying from issue)
> >
> > #1 <https://github.com/http2/http2-spec/issues/1>  has the problem that
> it
> > introduces an ambiguity in what to do when reducing the max size (clear
> out
> > the reference set first?). But if we specify exactly what to do when
> reducing
> > the max size, then that isn't that bad.
> >
> >
> >
> > On Wed, Oct 16, 2013 at 5:37 PM, Roberto Peon <fenix@google.com> wrote:
> >
> >
> >       https://github.com/http2/http2-spec/issues/281
> >
> >       Setting the max header size to 0 does not clear out all encoder
> state.
> >
> >       In particular, elements to the reference set that are pointing to
> static
> > table elements are not cleared out.
> >
> >       There are a couple of obvious ways of fixing this:
> >       1) Include the space used in the reference set in the overhead
> (e.g.
> > 2-bytes per reference)
> >       2) explicit SETTING for clearing the compression state
> >
> >
> >       I prefer #1.
> >
>
>