Re: Clarification of dynamic table size change

Tatsuhiro's description matches my understanding.

-Patrick


On Thu, Aug 18, 2016 at 9:50 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
wrote:

> ​Hi,​
>
> On Thu, Aug 18, 2016 at 10:31 PM, Bence Béky <bnc@chromium.org> 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 <
>> ilariliusvaara@welho.com> 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 <
>>> herve.ruellan@crf.canon.fr>
>>> > 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
>>>
>>>
>>
>