Re: Clarification of dynamic table size change

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

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?

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
>
>