Re: Clarification of dynamic table size change

[Bence Béky <[e-mail]>]

Hi Tatsuhiro and Patrick,

Thank you very much for the clarification.  FYI Starting with release
54, Chrome will send out a SETTINGS_HEADER_TABLE_SIZE of 64 kB value
in the initial SETTINGS frame, allowing servers to experiment with
encoding using larger tables in hopes of more efficient compression.

Cheers,

Bence

On Thu, Aug 18, 2016 at 10:06 AM, Patrick McManus <[e-mail]> wrote:
> Tatsuhiro's description matches my understanding.
>
> -Patrick
>
>
> On Thu, Aug 18, 2016 at 9:50 AM, Tatsuhiro Tsujikawa <[e-mail]>
> wrote:
>>
>> Hi,
>>
>> On Thu, Aug 18, 2016 at 10:31 PM, Bence Béky <[e-mail]> wrote:
>>>
>>> Hi all,
>>>
>>> I'm sorry to revive this old thread, but there is one more case that I
>>> would
>>> like to request clarification for.  I was looking at both RFC 7540 and
>>> 7541, but
>>> could not find a definitive answer to the following question:  What is
>>> the
>>> initial maximum size of the dynamic table if there was a
>>> SETTINGS_HEADER_TABLE_SIZE value in the initial SETTINGS frame (the one
>>> part of
>>> the connection preface)?
>>>
>>> For example, suppose that the decoder sends a SETTINGS_HEADER_TABLE with
>>> value
>>> 64 * 1024 in the initial SETTINGS frame.  Do we think about the HPACK
>>> context to
>>> be created after the connection preface is sent, with a maximum dynamic
>>> table
>>> size of the current SETTINGS_HEADER_TABLE_SIZE value of 64 kB?  Or do we
>>> think
>>> about the HPACK context to be created before the connection preface is
>>> sent,
>>> with a default maximum dynamic table size of 4 kB?  Note that there is no
>>> synchronization issue even in the former case: if the decoder only evicts
>>> dynamic table entries above 64 kB from the very beginning, there is no
>>> harm in
>>> the encoder not starting to reference entries above 4 kB until it
>>> processes the
>>> decoder's initial SETTINGS frame.
>>>
>>> Suppose that the encoder does not emit a "dynamic table size update"
>>> HPACK
>>> instruction after this.  The consensus on this e-mail thread seems to be
>>> that
>>> this is acceptable as long as the encoder means "no change" to the
>>> maximum
>>> dynamic table size.  It is, however, important that the encoder and the
>>> decoder
>>> are in agreement about the initial maximum dynamic table size, relative
>>> to which
>>> the encoder means "no change".  For example, if the decoder is under the
>>> impression that the maximum dynamic table size is 4 kB, while the encoder
>>> takes
>>> it to be 64 kB, then the decoder will signal a CONNECTION_ERROR as soon
>>> as the
>>> encoder references an entry above 4 kB.  If, on the other hand, the
>>> encoder
>>> thinks it's 4 kB and never references entries above that, then the
>>> decoder would
>>> waste memory if it kept 64 kB worth of entries.
>>>
>>> Given that a decoder can send a SETTINGS_HEADER_TABLE_SIZE with a value
>>> lower
>>> than the default, and the encoder can start compressing headers before
>>> receiving
>>> the initial SETTINGS frame, it seems necessary to me to understand the
>>> initial
>>> maximum dynamic table size to be 4 kB, and to require the decoder to
>>> store this
>>> much entries until it receives the dynamic table size update HPACK
>>> instruction
>>> from the encoder.  Otherwise a COMPRESSION_ERROR arises due to the
>>> synchronization issue even if the peers agree that the initial size is
>>> the new
>>> (lower) value.  Unless, of course,  we want to formulate different
>>> requirements
>>> depending on whether the SETTINGS_HEADER_TABLE_SIZE value is greater than
>>> or
>>> less than the default.
>>>
>>> If I implement a decoder in this spirit, that is, one that sends a
>>> SETTINGS_HEADER_TABLE_SIZE of 64 kB in the initial SETTINGS frame, but
>>> does not
>>> allow more than default memory for the dynamic table until it receives a
>>> dynamic
>>> table size update from the encoder, would it be incompatible with
>>> anybody's
>>> current implementation?
>>>
>>
>> According to this thread, I'm under impression that this is OK, and until
>> you get dynamic table size update, default 4KiB dynamic table limit still
>> applies.
>>
>> As for initial value of dynamic table size, I think it is 4KiB regardless
>> of SETTINGS.  We create HTTP/2 session before doing any parameter
>> modification, including header table size change.  At this moment, table
>> size if 4KiB, RFC default.  After that, decoder send
>> SETTINGS_HEADER_TABLE_SIZE with whatever value they want.  Then after
>> SETTINGS ACK, and HPACK table size update, dynamic table size is finally
>> synchronized, and changed to the value encoder sent in HPACK table size
>> update (as long as it is equal or smaller than decoder sent in SETTINGS).
>>
>> Best regards,
>> Tatsuhiro Tsujikawa
>>
>>
>>
>>>
>>> Best regards,
>>>
>>> Bence Béky
>>>
>>>
>>> On Fri, Oct 23, 2015 at 12:15 PM, Ilari Liusvaara
>>> <[e-mail]> wrote:
>>>>
>>>> On Sat, Oct 24, 2015 at 12:45:49AM +0900, Tatsuhiro Tsujikawa wrote:
>>>> > Hi,
>>>> >
>>>> > On Fri, Oct 23, 2015 at 1:18 AM, Hervé Ruellan
>>>> > <[e-mail]>
>>>> > wrote:
>>>> >
>>>> > > I agree that the wording is ambiguous here.
>>>> > >
>>>> > > However, my reading is the same a Cory's: you don't have to send a
>>>> > > dynamic
>>>> > > table update if the *actual* value is not changed.
>>>> > >
>>>> > >
>>>> > I also found the discussion in this ML indicating you are right.
>>>> > Thank
>>>> > you for clarification.
>>>> > I have to ask one more question: what is *actual* value? Is it the
>>>> > table
>>>> > size both peer agreed before reading SETTINGS, or the value in
>>>> > SETTINGS_HEADER_TABLE_SIZE decoder sent?
>>>> >
>>>> > I think this is a good item to add in FAQ section..
>>>>
>>>> The way negotiation works:
>>>> - Decoder side sets the upper bound via SETTINGS_HEADER_TABLE_SIZE.
>>>> - Encoder side sets the actual size via dynamic table updates (inside
>>>>   HPACK bitstream) within limits set by decoder.
>>>> - If between headers decoder reduces the limit below size signaled by
>>>>   encoder, the encoder must first reduce the table size to the minimum
>>>>   it was between the frames or less (it can then increase it up to
>>>>   current limit).
>>>>
>>>> As example of the last point:
>>>> [4k dynamic table size in use]
>>>> --> HEADERS
>>>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=4k)
>>>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=2k)
>>>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=4k)
>>>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=8k)
>>>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=6k)
>>>> --> HEADERS
>>>>
>>>> The second HEADERS must first reduce the dynamic table to at most
>>>> 2k. It can then increase dynamic table size to up to 6k.
>>>>
>>>>
>>>> -Ilari
>>>>
>>>
>>
>