Re: Header Compression Overview

On Tue, Jul 2, 2013 at 10:17 AM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Jul 02, 2013 at 01:29:22PM +0000, RUELLAN Herve wrote:
>>
>> The eviction mechanism uses the table order: when the size of the header
>> table is greater than the limit, then the first entry is dropped. This
>> is repeated until the header table size becomes smaller than the limit.
>> The entries are renumbered to keep the indexes small.
>
> How to handle (slightly pathological) case where write causes modified
> entry itself to get evicted?
>
> E.g. Perform substitution on entry #1, with value long enough to cause
> 2 (or 3) headers to get evicted to make space.
>

That's one bit that needs to be clarified in the spec currently. From
what I understand, the order of operations is:

1. Insert the new value first, then
2. If the buffer > max, remove entries from the front until buffer is <= max

In which case, if you insert large items at the front of the buffer,
you willingly accept the risk that the items you just inserted will be
immediately removed. Which is silly, but that's what you get.

We're just going to have to play around with various algorithm
variations until we get it right.

>
> Also, there is no operation that could be used to "refresh" header table
> entries without explicitly coding for value? Since some headers could be
> quite expensive to code (that one WAP-related header anyone?), one would
> want to keep those live...
>

Nope, there is no "touch" operation that just keeps the header table
entry alive without using it. Adding such a thing would just add
unnecessary complexity, I think.

>
> Also, performing large enough write to bust the header table in one shot
> is probably a fatal error, no?
>

As I understand the current design, in theory, If the size of a new
entry > max size of the buffer, the new entry is added, then
immediately everything ends up getting removed, causing the buffer to
empty out completely. In practice, we ought to detect this and return
an error because obviously the sender is not doing something
correctly.

- James

>
> Since there is synchronized (and persistent) state involved, it is quite
> important that both ends handle all sorts of weird corner cases in the
> same way...
>
>
> -Ilari

Received on Tuesday, 2 July 2013 17:26:05 UTC