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

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.

Received on Thursday, 24 July 2014 17:55:22 UTC