Re: Clarification of dynamic table size change

Hi,

On Wed, Sep 14, 2016 at 11:48 PM, Bence Béky <bnc@chromium.org> wrote:

> 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.
>
>
​Awesome!  Meanwhile, we added new configuration to libnghttp2​ to change
dynamic table size for encoder per session, so nghttp2 based servers have
the opportunity to experiment larger table size with Chromium.

Best regards,
Tatsuhiro Tsujikawa




> Cheers,
>
> Bence
>
> On Thu, Aug 18, 2016 at 10:06 AM, Patrick McManus <mcmanus@ducksong.com>
> wrote:
> > 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
> >>>>
> >>>
> >>
> >
>