Re: Getting to Consensus: CONTINUATION-related issues

Option a- I find this option to be an extremely poor option. I hate it, it
should not happen.

It increases aggregate complexity while increasing the DoS surface as it
would require state rewind in the compressor. This would impact scalability
in a very negative way, in terms of memory, and in terms of cpu (copying
the whole compression context would be expensive, and would need to be done
for every response unless one can accurately predict the compressed size).
Compressor rewind would often result in a doubling of the memory
requirements for the compressor while compressing, as the least error-prone
rewind is to make a copy of the complete compressor state. While more
efficient 'rewinds' are possible, the complexity becomes significantly
higher, and when done improperly, could result in state committments of
more than double the compression size (it could be as large as message-size
+ state size)

Option b-

 I could live with it. It acts against the right thing-- uncompressed size,
which implies no state rewind from the compressor, and, so long as the
setting can be set large, it can retain compatibility with HTTP/1.

-=R
On Jul 17, 2014 5:47 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> We've had a rollicking discussion about the design tradeoffs in
> CONTINUATION, especially regarding HOL blocking and DoS considerations.
>
> I see very little new information entering that discussion, and I think
> everyone has come to understand the tradeoffs. For a refresher, please see
> the wiki:
>   https://github.com/http2/http2-spec/wiki/ContinuationProposals
>
> I proposed two options the other day:
>
> a) Remove CONTINUATION from the specification and add a new setting that
> dictates the maximum HEADERS/PUSH_PROMISE frame size (as distinct from
> max_frame_size) a peer is willing to receive. I.e., the setting refers to
> the compressed header size.
>
> b) Keep CONTINUATION in the specification, and add a new setting that
> advises the maximum header set size (i.e,. uncompressed) a peer is willing
> to receive (but might not imply PROTOCOL_ERROR or STREAM_ERROR on receipt).
>
> Although there have been some tentative proposals for additional options
> since, I haven't heard a clamour for support for them, so I think these are
> realistically the ways we can go.
>
> As stated before, there will no doubt be tweaking and adjustments made to
> these, but I think we're in a place where we can choose a general direction.
>
> I'd like to hear:
>
> 1) Your preferred outcome (if any)
> 2) Whether you can live with the other option, and if not, why
>
> "I have no preference" is useful information too.
>
> If you indicate you can't live with one (or both) of the options, you MUST
> give a detailed, relevant reason as to why; omitting the reason means your
> "can't live with" will be ignored.
>
> Thanks,
>
> P.S. Please state *your* preference, not what you think the WG can live
> with.
>
> P.P.S. This is not a call for more discussion; please resist replying to
> others' preferences.
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
>