Re: Cost analysis: (was: Getting to Consensus: CONTINUATION-related issues)

Martin,

On Jul 18, 2014, at 2:24 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 18 July 2014 10:57, Jason Greene <jason.greene@redhat.com> wrote:
>> It’s extra complexity, but the implementation isn’t difficult (a cake walk compared to other aspects of the spec). I can certainly appreciate the perspective from implementations that don’t want to touch their code though.
> 
> I realize that this is a standard sophist technique in this forum, but
> I find that selectively trivializing various aspects of the space
> isn't particularly constructive.  Let's try to be even-handed in our
> analysis.
> 
> On the one side:
> 
> CONTINUATION has a cost in code complexity.  It defers the discovery
> of what might be a surprisingly large amount of state.
> 
> On the other:
> 
> A hard cap on size (i.e., option A) has a cost in code complexity.  It
> requires that encoders be prepared to double their state commitment so
> that they can roll back their header table when the cap is hit.  When
> you consider compression, it does not prevent there from being a
> surprisingly large quantity of header information.

Actually, there is a simple solution to this problem - add a flag causes the header table to be reset/cleared before the frame is processed.  The sender can set the flag when it has tried preparing a HEADERS frame and made one too big, or when it gets a 431 response that indicates the recipient was unable to process it fully.

That solves the header-table-is-out-of-sync and allows the sender to maintain a single header table should that become too much of a burden (although constrained endpoints can always specify settings to disable the header table on their end and always use encoding that doesn't add values to the header table...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair