Re: #540: "jumbo" frames

On 26/06/2014, Greg Wilkins <gregw@intalio.com> wrote:
>
> Continuations are jumbo frames!  They are just really bad jumbo frames that
> only apply to headers, can't be efficiently handled and don't have a
> mechanism for end points to pre declare max acceptable sizes.   General
> jumbo frames would handle the headers use-case, but also provide a solution
> for those who need efficient large data.
>

Data is a single unit, with simple properties for concatenation, so
it's trivial to split into multiple frames at one end and recombine at
the other.

The equivalent metadata unit is the header block, but that doesn't
have the same recombination properties; so while it can be split into
multiple frames, there are rules about streaming and interleaving.

Those rules result partly from the record-based nature of the
underlying headers, but mostly from the shared state. To eliminate the
shared state issue I see a couple of options:

1) allow multiple header blocks to be sent on one stream, and remove
continuations. Interleaving wouldn't be a problem, but it wouldn't be
possible to send large individual headers. More kluge required.

1.5) Only compress the HEADERS, make CONTINUATIONs stateless. Pros and
cons as above.

2) Extend HEADERS frame size and remove continuations. Removes the
ability for a very low level packet shuffler to shuffle packets
easily.

3) Extend frame size for all frame types. I understand where Roberto
is coming from on this now. It defeats the purpose of the protocol.

4) Revisit #1, but add a stream-local state, and only emit frame data
to the shared state when some boundary is reached. I think that's
fancy words for "buffer headers until END_HEADERS, then unhpack." This
appeals to me, but it defeats the commitment requirements that Martin
patiently explained to me a few months ago.

4.5) 1.5 with local state for continuations. This just occurred to me
now, so I'm not sure of the implications. OTOH two state sets
(essentially 'connection' and 'stream') is more moving parts requiring
more juggling, but probably not unreasonable. Likely to get resistance
because we're late in the game.

If we consider the status quo as option 5, its only downsides are:
END_STREAM is in the wrong place, and jerks who send ginormous headers
screw up their user experience. Also it's annoying to have to design
your low level packet shuffler, if you have one, to throw errors if
one packet has certain bit pattern (HEADERS-END_HEADERS) and the next
doesn't have another (CONTINUATION).

I think I'm pretty well decided, at least as far as my concerns are
being addressed.


> h2 should either just support general jumbo frames for both headers and
> data or no jumbo frames for either.  By supporting jumbo headers, but not
> jumbo data, a double standard is being applied.
>

Yep. For jerks. And using it quite clearly marks them with a taint.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au

Received on Wednesday, 25 June 2014 23:53:35 UTC