Subject: Why "MUST" encoder emit Context Update

From: Osama Mazahir <[email-masked]>
Date: Wed, 30 Jul 2014 23:42:11 +0000

http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-08#section-5.1

   After applying an updated value of the HTTP/2 setting
   SETTINGS_HEADER_TABLE_SIZE that changes the maximum size of the
   header table used by the encoder, the encoder MUST signal this change
   via an encoding context update (see Section 7.3).  This encoding
   context update MUST occur at the beginning of the first header block
   following the SETTINGS frame sent to acknowledge the application of
   the updated settings.

Why is it a 'MUST' for the encoder to emit a Context Update opcode?  The SETTINGS ACK (from encoder-side to decoder-side) communicates that the encoder has made the corresponding accounting change and implies the encoder will use the decoder's entire table space.  If the encoder does not want to stretch itself to the full extent of the decoder, only then is it a 'MUST' to emit a Context Update opcode in order to advertise what subset of the table space it will use.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 31 Jul 2014 03:19:58 +0300

On Wed, Jul 30, 2014 at 11:42:11PM +0000, Osama Mazahir wrote:
> Why is it a 'MUST' for the encoder to emit a Context Update opcode?  The
> SETTINGS ACK (from encoder-side to decoder-side) communicates that the
> encoder has made the corresponding accounting change and implies the
> encoder will use the decoder's entire table space.  If the encoder does
> not want to stretch itself to the full extent of the decoder, only then
> is it a 'MUST' to emit a Context Update opcode in order to advertise wha
> subset of the table space it will use.

Actually, AFAICT (since static table is below dynamic indices, dynamic
incides drop on high index and reference set does not exist) even if
encoder_table < decoder_table, if stream is encoded correctly, it will
decompress correctly (but incorrect streams may decompress to garbage
instead of erroring out).

-Ilari

---

From: <[email-masked]>
Date: Thu, 31 Jul 2014 11:33:31 +0000

On Thursday,31 July 2014 01:42, [email-masked] wrote:
>    via an encoding context update (see Section 7.3). ...
>
> Why is it a 'MUST' for the encoder to emit a Context Update opcode?  ...

I agree this is confusing.

For example, suppose the encoder is only using 512 for the table size out of the 4096 default value for SETTINGS_HEADER_TABLE_SIZE.

Now suppose the decoder lowers SETTINGS_HEADER_TABLE_SIZE to 1024, why 'MUST' the encoder emit a Context Update opcode since the new setting doesn't force the encoder to lower the table size and therefore should have no effect?

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 31 Jul 2014 12:18:41 +0000

The initial intention when the Context Update was introduced was twofold:
- Enable the encoder to use a smaller header table size than what was allowed by the decoder.
- Transmit the header table size change at the HPACK level to better separate HPACK from the rest of the framing layer (even if the separation can't be completely done).

After exchanging the positions of the static and header table, the encoder can decide to use only a part of the size allowed by the decoder without any impact on either the encoding or decoding side. Transmitting the effectively used size just helps the decoder reduce its memory commitment for the header table.

I agree than the context update in HPACK is not always necessary. It's probably simpler to generate it for each received SETTINGS_HEADER_TABLE_SIZE change.
However, it's not fully coherent with allowing to fold several changes received between the sending of two header blocks.

This may be improved, but I'm not sure the improvement in term of bytes not transmitted is worth it.

Hervé.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: jeudi 31 juillet 2014 13:34
> To: [email-masked]; [email-masked]
> Subject: RE: Why "MUST" encoder emit Context Update
> 
> For example, suppose the encoder is only using 512 for the table size out of the
> 4096 default value for SETTINGS_HEADER_TABLE_SIZE.
> 
> Now suppose the decoder lowers SETTINGS_HEADER_TABLE_SIZE to 1024, why
> 'MUST' the encoder emit a Context Update opcode since the new setting
> doesn't force the encoder to lower the table size and therefore should have no
> effect?
> 
> 
> 
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jul 2014 10:53:20 -0700

> Now suppose the decoder lowers SETTINGS_HEADER_TABLE_SIZE to 1024, why 'MUST' the encoder emit a Context Update opcode since the new setting doesn't force the encoder to lower the table size and th…

You will notice the careful addition of a condition on this: "...that
changes the maximum size of the header table used by the encoder".
Your example doesn't change what the encoder uses, so you are not
*required* to send the context update.