Re: #541: CONTINUATION

On Tue, Jul 8, 2014 at 1:07 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Thanks for the detail, Roberto.
>
> On 8 Jul 2014, at 10:53 am, Roberto Peon <grmocg@gmail.com> wrote:
>
> > The limit on max header size partially solves a problem (see other
> thread for the problems with how a proxy picks the right max size..) that
> is different from the jumbo vs continuation stuff, though.
> > The limit on max frame size absolutely helps to make multiplexing work
> (and I can get behind that).
> >
> > I see a few distinct and orthogonal topics:
> > 1) declaring a limit on the compressed header size
> > 2) headers get buffered at sender until complete and sent with declared
> length
> > 3) declaring a maximum accepted frame size for headers or data frames or
> perhaps all frames.
> > 4) changing the base framing format to have a larger, but consistent
> size field (e.g. from 16 bits to 24).
> > 5) changing the base framing format to have a variable length size field
> > 6) headers transmitted using multiple frames (i.e. continuations)
> > 7) moving the flags on continuations to the last frame, possibly
> renaming those/changing the opcodes
> > 8) nonblocking headers
> > 9) flow control for metadata (i.e. headers).
> >
> > A few of these get conflated often (e.g. 1,2,{4,5}), despite the fact
> that they're separable.
> >
> > I'm saying this in the hope that we can talk about these separately.
> > From my perspective:
> > #1: Sure, though I suspect its utility will be minimal when
> proxies/gateways are in the mix.
>
> See previous discussion. I'm not seeing strong pushback on doing this kind
> of setting, so it sounds like we're going to do something like this.
>
> This would partially mitigate #550, and substantially help #551.
>
> > #2: Don't like it-- it restricts implementations in ways that affect
> their performance/efficiency without providing clear DoS-protection/scaling
> benefit.
>
> I'm hearing mixed messages on this, but how it turns out depends on other
> decisions we make, so probably best to punt for now.
>
> > #3: Sure, seems reasonable to do.
>
> And I'm not hearing people pushing back on that (assuming we make frames
> bigger).
>
> > #4: Fine, so long as #3 covers data and headers, though I suspect that
> adding to the size field will increase protocol overhead in the common
> case, and that a 16 bit length field is good enough for that common case.
>
> The only outright reluctance I hear is from Nick, and Greg has just
> responded to that. We'll see how that plays out, but to me the important
> question here is "how big?"
>
> The answer here seems very intertwined with #6. E.g., if we chose a 16-bit
> frame size, that would avoid any extra overhead, but we'd still need
> CONTINUATION if we wanted to support large header blocks.
>
> OTOH if we chose 16 bits and declared that any header block over 64K-10
> (compressed) needs to be supported by an extension (presumably,
> CONTINUATION in a separate document), that would be another approach. I'd
> be interested to hear what people think of this.
>
>
​If we are going to expand length bits, I very much support this approach.
We get 64K - 1 payload and Kerberos headers is supported which is only
known use case I heard so far.
By requiring implementations to fully process 64K frame, we don't need
additional settings at all (and no WINDOW_UPDATE abuse).  Implementations
are free to return 431 or RST_STREAM within their limits but just keep
running HPACK decompressor to stay connected.
This is far more simpler than the proposal and not invasive at all.  We
just goes back to the state when we decided that frame payload size should
be 16K.

​Best regards,

Tatsuhiro Tsujikawa​



> If neither of those options is palatable, we'll need more bits - and that
> has its own set of tradeoffs.
>
> > #5: Don't like it, never will. It makes base framing more complicated,
> and the base framing should be the simplest and most regular thing in the
> protocol. Interpretation can have more complexity-- framing shouldn't.
> Getting the framing wrong leads to security nightmares.
>
> I suspect many feel the same.
>
> > #6: I prefer fragmentation to varying the base framing due to the
> reasons described in #5.
>
> That's a false choice; there are other options.
>
> > #7: Sure. We could also do PARTIAL_HEADERS* HEADERS, or HEADERS
> CONTINUATION*, or SYN_STREAM (HEADERS)* END, whatever. All make just as
> much sense to me as the current layout.
>
> This seems to be widely held view.
>
> > #8: Still for it, though it does add complexity. Probably not worthwhile
> to solve the problem for HTTP-for-browsing, but useful for other usecases
> where HTTP would be used.
> > #9: Same as #8.
>
> Let's defer these until we get a sense of where the rest is going.
>
> Thanks,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
>