Re: HPACK encoder/decoder memory bounding

On Sat, Oct 26, 2013 at 1:50 AM, Fred Akalin <akalin@google.com> wrote:

> It seems tricky to me for an endpoint to use less than
> SETTINGS_HEADER_TABLE_SIZE for its encoding state, especially since it
> still has to use SETTINGS_HEADER_TABLE_SIZE for its decoding state.
>
> Since we already need an ack for a header table size change, can we
> perhaps piggyback a negotiated size (guaranteed to be <= the advertised
> size) onto that ack? So a client can just send
> SETTINGS_HEADER_TABLE_SIZE=5MB, and a memory-constraint server can ack with
> SETTINGS_HEADER_TABLE_SIZE=4K, and both sides will then use 4K.
>
>
+1
This greatly simplifies the things.

Best regards,
Tatsuhiro Tsujikawa


>
> On Fri, Oct 25, 2013 at 9:38 AM, Hervé Ruellan <ruellan.crf@gmail.com>wrote:
>
>> Hi Osama,
>>
>> We discussed on this topic in the thread starting at:
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0221.html.
>>
>> Basically, an encoder can choose to keep only the first 4 KB of its
>> table, discarding the rest. It will just not make any reference to the
>> entries in the table above the first 4 KB.
>> It the encoder wants also to reference the static table, this is more
>> complex (see the referred to thread for more details). It will work if the
>> maximum table size is 8 KB, and the encoder keeps only 4 KB of it, it will
>> not really work if the encoder wants to only keep 4 KB of a 5MB table.
>>
>> Hervé.
>>
>>
>> On Fri, Oct 25, 2013 at 4:09 AM, Osama Mazahir <OSAMAM@microsoft.com>wrote:
>>
>>>  Based on my understanding, the encoder and decoder have to have the
>>> exact same value for max-header-table-size so that the indices match.  So
>>> if the client advertises SETTINGS_HEADER_TABLE_SIZE=5MB then that means the
>>> client-decoder is using a header-table with maxsize=5MB.  Which means the
>>> server-encoder also has to use a header-table of maxsize=5MB.  But if the
>>> server only wants to use 4KB of encoder space then after storing 4KB worth
>>> of header name/values, it can only reuse from the initially stored 4KB or
>>> emit literals (either as-is or Huffman encoded).****
>>>
>>> ** **
>>>
>>> So it seems to bound its memory usage, the server (in the above example)
>>> has to be choosy in what it adds to the server-encoder header-table because
>>> once something is added it cannot be removed (unless it decides to expand
>>> to 5MB+)?****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> --Osama.****
>>>
>>
>>
>