RE: HPACK, Dynamic Table Size Update

It can be unsolicited.  The decoder sends (via SETTINGS) the largest context it will allow the encoder to use -- the encoder, however, could choose to go even smaller than it's allowed for whatever reasons seem good to it.  (Think low-memory embedded devices, for example.)  The encoder can also be fancy and vary the size it's using based on current memory pressure.  4.2 is trying to reduce the chattiness of an encoder that's doing dynamic variation like this.

Your pseudocode would work, but you're sending at least one, possibly two, size updates on every encoded header block.  Most of the time, it won't have changed, so you don't need to send anything.  So more like:

    Encoder.setMaxSize( size ) {

      if size < minSizeSinceUpdate
        minSizeSinceUpdate = size

      currentSize = size;

    }

    Encoder.encodeAndSendAsHeaderBlock( headers ) {

      if minSizeSinceUpdate < lastSent  {
        sendMaximumSizeUpdate( minSizeSoFar );
        lastSent = minSizeSinceUpdate;
      }

      if lastSent != currentSize {
        sendMaximumSizeUpdate( lastSize );
        lastSent = currentSize;
        minSizeSinceUpdate = currentSize;
      }

      for each (Header h in headers) {
          ...
      }
      ...
    }

The key is to let the remote side know the smallest the table got (so it can prune appropriately) and what size it is now, if it has grown again.  The point of 4.2 is that if you're dynamically varying size, you don't have to tell the remote about *every* size change, you can just condense them into at most two.  But most of the time, zero or one will be sufficient.

-----Original Message-----
From: Pavel Rappo [mailto:pavel.rappo@gmail.com] 
Sent: Tuesday, June 9, 2015 6:15 AM
To: ietf-http-wg@w3.org
Subject: HPACK, Dynamic Table Size Update

Hi,

1. Can a "Dynamic Table Size Update" be unsolicited or its only purpose is to acknowledge the fact that encoder has understood the request sent by decoder and agreed to use a new maximum upper bound for the dynamic table size?

2. From "4.2.  Maximum Table Size":

   ...Multiple updates to the maximum table size can occur between the
   transmission of two header blocks.  In the case that this size is
   changed more than once in this interval, the smallest maximum table
   size that occurs in that interval MUST be signaled in a dynamic table
   size update.  The final maximum size is always signaled, resulting in
   at most two dynamic table size updates.  This ensures that the
   decoder is able to perform eviction based on reductions in dynamic
   table size (see Section 4.3)...

Am I right saying that _semantically_ it would be equivalent to this schematic behaviour (depicted by pseudo-code):

    Encoder.setMaxSize( size ) {

      if size < minSizeSoFar
        minSizeSoFar = size

      lastSize = size;

    }

    Encoder.encodeAndSendAsHeaderBlock( headers ) {

      sendMaximumSizeUpdate( minSizeSoFar );

      if minSizeSoFar != lastSize
        sendMaximumSizeUpdate( lastSize );

      for each (Header h in headers) {
          ...
      }
      ...
    }

Or this paragraph means something completely different?

Thanks.

-Pavel

Received on Tuesday, 9 June 2015 17:28:22 UTC