Re: SETTINGS_HEADER_TABLE_SIZE and ACK

On Sat, Oct 19, 2013 at 1:03 AM, RUELLAN Herve
<Herve.Ruellan@crf.canon.fr>wrote:

> The sender can use only a part of the header table.
> For example, with a SETTINGS_HEADER_TABLE_SIZE of 4k, it may use only 2k
> for storing entries.
> The receiver will have a 4k table, storing more entries than the sender.
> These entries stored only by the receiver are not a problem, as the sender
> will never refer to them, but only to those it has in its table.
>

OK, I understand that this is possible with the 0-index addition scheme.
The encoder also takes care of the reference set, if the entry slips away
from the 2K, then it needs to emit indexed repr to toggle off.



> There is a difficulty to access the entries from the static table: to know
> the index of the first entry in the static table, the sender needs to know
> how many entries are present in the whole table of the receiver. It can
> manage this by tracking the size of the entries in the part it doesn't use:
> this allows it to evict entries from the table as would the receiver, and
> therefore to know how many entries are in the header table.
>
>
Right. I feel this is a bit more complicated for the already complicated
enough HPACK spec. It would be good to add the above text to the draft so
that the implementer know the reasoning.

Best regards,
Tatsuhiro Tsujikawa



>
> Hervé.
>
> > -----Original Message-----
> > From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
> > Sent: vendredi 18 octobre 2013 14:31
> > To: ietf-http-wg@w3.org
> > Subject: SETTINGS_HEADER_TABLE_SIZE and ACK
> >
> > SETTINGS_HEADER_TABLE_SIZE is used to inform the size of header table to
> > the other endpoint. Since the size of header table of the decoder side
> has to
> > be matched to the one in the encoder side (otherwise, header table
> out-of-
> > sync on eviction or out-of-bound index), the received peer may not want
> to
> > accept the larger buffer size due to whatever reason (e.g., resource
> > constraints or variable buffer size is not implemented, etc).
> >
> > The HPACK-03 has a text to allow the receiver to choose smaller values
> in the
> > acknowledgement, but now SETTINGS with ACK flags must not have any
> > settings value, the peer is forced to accept the offer.
> >
> > The SETTINGS_HEADER_TABLE_SIZE is special among the other settings. The
> > others affect the receiver's capability, but it can regulate itself not
> to use
> > more resources it wants (e.g., SETTINGS_MAX_CONCURRENT_STREAMS is
> > informed as 500, but the receiver only uses 100). For
> > SETTINGS_HEADER_TABLE_SIZE, there is no way but to just obey the
> > informed value.
> >
> > Best regards,
> > Tatsuhiro Tsujikawa
>
>