Re: Recovery from decompression failure (was: Re: Cost analysis: (was: Getting to Consensus: CONTINUATION-related issues))

Also, the more opcodes, the smaller the space left over for indices is, and
thus the compressor becomes less efficient.
I'd expect having a compressor which wants to clear the dynamic table is a
relatively rare occurrence. Sacrificing bytes in the common case for this
rare case would be counter productive.
-=R


On Thu, Jul 24, 2014 at 10:54 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> Basically, if an compressor wants to clear the dynamic table, it can just
> stop using it and discard the actual data from memory.  It can either
> maintain enough bookkeeping data to track expiration of the items (whatever
> they were), or it can encode a size of zero followed by a non-zero size
> which frees it from bookkeeping as well (and frees the memory on the peer).
>  An opcode that was just a shortcut for reduce to zero, then increase to
> the current value doesn't seem like it adds much to this direction, though
> it wouldn't hurt much either.
>
> The more common case that was raised for wanting to clear the dynamic
> table, though, was the decompressor -- it can't clear it without notice to
> the other side like the compressor can.  That's why it sends SETTINGS to
> zero and then back.  There's no opportunity for an opcode to flow in this
> direction.
>
> So why no opcode?  Superfluous in one direction and not (cleanly) an
> option in the other.
>
> -----Original Message-----
> From: Mike Bishop
> Sent: Thursday, July 24, 2014 10:29 AM
> To: 'Poul-Henning Kamp'; Martin Thomson
> Cc: Tatsuhiro Tsujikawa; Mark Nottingham; David Krauss; Greg Wilkins; HTTP
> Working Group; Michael Sweet; Jason Greene; Roberto Peon; Ilari Liusvaara
> Subject: RE: Recovery from decompression failure (was: Re: Cost analysis:
> (was: Getting to Consensus: CONTINUATION-related issues))
>
> There's no opcode because it's the compressor who wants (wanted) to clear
> the reference set since they know that what they're encoding will be
> quicker if the set is gone, but it's the decompressor that wants to clear
> the dynamic set to reduce its memory commitment.  (The compressor can
> partially discard the contents of the dynamic table any time it wants
> without need to notify the other side it has done so.)
>
> There are no HPACK opcodes sent from decompressor to compressor, unless
> you want to mix information across the two directions.  That seems like
> even more of a complication to me.  SETTINGS and the corresponding ACK are
> effectively the communication channel from decompressor back to the
> compressor.
>
> -----Original Message-----
> From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk]
> Sent: Thursday, July 24, 2014 7:35 AM
> To: Martin Thomson
> Cc: Tatsuhiro Tsujikawa; Mark Nottingham; David Krauss; Greg Wilkins; HTTP
> Working Group; Michael Sweet; Jason Greene; Roberto Peon; Ilari Liusvaara
> Subject: Re: Recovery from decompression failure (was: Re: Cost analysis:
> (was: Getting to Consensus: CONTINUATION-related issues))
>
> In message <
> CABkgnnV82KWYVzHKNzFH7fXp4hZoC7vsqGsJcPDRep-O1qKuQQ@mail.gmail.com>
> , Martin Thomson writes:
>
> >Yes, I would use SETTINGS ACK as the marker to use for trimming the
> >header table down, but still require the next header block after that
> >to include a context update.  That might mean two rounds of eviction if
> >the encoder chooses to use a smaller table size, but that's the safest
> >approach.
>
> The safest and by far most efficient approach is to have an oopcode for it.
>
> Why that was felt necessary for the reference set but not for the dynamic
> set is a good question.
>
> Resizing the dynamic set to zero and then back up invites the receivers to
> complicate their memory management because the most likely resize of the
> dynamic set isn't going to be one.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>