Re: #541: CONTINUATION

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

Received on Tuesday, 8 July 2014 04:08:22 UTC