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

In message <CABkgnnWmBUNKFDH8JKz8GKRgZDaS=1f6yQ0C6CdF_zv=QnPR8A@mail.gmail.com>
, Martin Thomson writes:

>I find that selectively trivializing various aspects of the space
>isn't particularly constructive.

I agree.  Misinformation is also bad.

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

And even though CONTINUATION in themselves do not imply or cause
any limit to exist, all implementations are going to have limits,
one way or another.  What these limits might be is anyones guess
at this point, but HTTP/1 deployments might be indicative.

Reception of CONTINUATION frames carries a cost in complexity for
memory and buffer management, independent of there being limits or
not.

CONTINUATIONS are significantly more complext to describe in the
draft (compare red/green in the Greg at all draft).

>On the other:
>
>A hard cap on size (i.e., option A) has a cost in code complexity.

I pressume you mean ... over option B) ?

If so, it will be quite the contrary:  Both senders and receivers
will have much simpler memory management and far less state to keep
track of with complete header-sets in a single frame.

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

No, it doesn't, the encoders can just sacrifice the connection and
open another, which will be an incredibly common implementation
because header-sets larger than the other side is willing to accept
are going to be incredibly rare, and primarily caused by attacks.

(See my previous analysis of the scenarios where larger than max
could be encountered.  Please respond relative to that analysis
if you disagree with it.)

-- 
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 Friday, 18 July 2014 19:37:48 UTC