Re: Header Compression Overview

Hmm.. You're right. An earlier version of the draft had indicated that
a "Least Recently Written" strategy was to be used. I was not aware
that the language around the eviction strategy had changed (or when it
changed). The current language troubles me significantly "renumbering
of the remaining entries" does make maintaining the reference set
state more difficult but not unmanageable. I much prefer the "Least
Recently Written" approach without renumbering anything. Hmm..

On Mon, Jul 1, 2013 at 2:36 PM, Gábor Molnár <gabor.molnar@sch.bme.hu> wrote:
> Are you sure this is how eviction works?
>
> The spec says:
>
>     When an entry is added to the header table, if the header table size
>     is greater than the limit, the table size is reduced by dropping the
>     entries at the beginning of the table until the header table size
>     becomes lower than or equal to the limit.  Dropping entries from the
>     beginning of the table causes a renumbering of the remaining entries.
>
> I could not find any reference to eviction of old headers other than this...
>
>
>
> 2013/7/1 James M Snell <jasnell@gmail.com>
>>
>> Minor correction with regards to substitution indexing for literal
>> headers...
>>
>> You can use substitution to change both the name and value of existing
>> header positions, making it fairly simple to reuse existing memory
>> slots.
>>
>> Generally speaking, an intelligent implementation is likely going to
>> want to make smart use of substitution indexing as much as possible,
>> in order to keep the compression context from filling up and incurring
>> more frequent eviction operations.
>>
>> On Mon, Jul 1, 2013 at 11:32 AM, James M Snell <jasnell@gmail.com> wrote:
>> [snip]
>> >
>> > We have an index position for the header field foo1 but not the full
>> > name+value pair "foo1=bar". Remember when I briefly mentioned
>> > Incremental Indexing vs. Substitution indexing? We need to make a
>> > decision. When Incremental Indexing, I can add "foo1 = new" as an
>> > entirely new entry in the dynamic table (#2) or I can replace the
>> > value of the existing "foo1 = bar" entry sitting at index #3. The
>> > choice is entirely up to the sender and can be based on a number of
>> > factors... the most important of which is basic memory management. For
>> > now, let's keep things simple and use Incremental Indexing. We want to
>> > minimize the amount of data we're going to send, however, so instead
>> > of sending the header field name as a length prefixed string, we're
>> > going to reference the existing index position and send along a new
>> > value ( 0x43 0x03 0x6E 0x65 0x77 ).
>> >
>> ...
>> >
>> > Another consideration that must be carefully weighed is the choice
>> > between Incremental and Substitution indexing. If an implementation
>> > always chooses to use Incremental Indexing, Eviction will become the
>> > only reliable means of memory management. Long lived connections will
>> > build up full compression contexts that tie up a potentially
>> > significant amount of memory. This could be dangerous, especially
>> > since there is no explicit mechanism for deleting items from the
>> > dynamic table.
>> >
>> ...
>> >
>> > Substitution Indexing provides only a partial solution to this problem
>> > by making it possible to reuse existing index positions so long as the
>> > header field name remain the same. There still exists the possibility
>> > of tying up memory, however, if there are a large number of different
>> > header names.
>> >[snip]
>>
>

Received on Monday, 1 July 2013 21:48:19 UTC