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

Lets call this #6.
-=R


On Thu, Oct 17, 2013 at 11:15 AM, Jeff Pinner <jpinner@twitter.com> wrote:

> Another option:
>
> Do not allow indexed representations to use the static set. If you can
> only use the set for literal representations (with or without indexing)
> then you could never add anything from the static set to the reference set.
> No need to track emitted status. Problem sovled.
>
> This would mean a slight overhead when sending the initial ":scheme" or
> ":method" headers since you would have to encode the values.
>
> It would mean that we could remove values (and thus duplicates) from the
> static set since they could never be referenced.
>
>
>
> On Thu, Oct 17, 2013 at 10:44 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> 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.
>>> >
>>>
>>>
>>
>