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

On Jul 18, 2014, at 1: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.

Fair enough, although I really didn’t think I said anything controversial. I simply meant that even if you agree with me that the code complexity is marginal, I understand the reluctance to touch already developed and working HPACK routines.

> 
> 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.

Right and there is CPU + memory + transmit cost for both parties in the conversation vs raw sender compute time.

> 
> 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.

One caveat:

A client that *chooses* to send more than max_header_frame (lets assume 16KB) uncompressed headers, does need an additional 4KB of temporary space to go along with the 16KB destination buffer. So the rollback means you need 20KB vs 16KB.

I emphasize the choose part because clients that really care about this extra 4k can still send 99.8% of headers by simply treating the compressed limit as the uncompressed limit, and thereby leaving their hpack routines untouched.

> 
> Option B seems almost orthogonal to these points,

Yes, I agree that this only affects A.

> providing a 431
> warning.  I'm not really certain how it would be used.

An intermediary can make accurate determinations about what to relay and what not to. This saves network bandwidth and mitigates the impact of HOL blocking when connection coalescing is occurring, while also avoiding arbitrary cut-offs that drop what should be perfectly acceptable data.  

> 
> Did I miss anything else pertinent to the discussion?

Nope I think you got it all.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 18 July 2014 19:26:01 UTC