Re: #540: "jumbo" frames

The size of a header block is orthogonal to the max frame size so long as
it is unlimited, as is true today and as is required today for
compatibility with the tail.
Getting rid of compatibility in the tail is a different discussion.

For any implementation which is using TLS, or not using sendfile/splice,
the size of a frame has zero correlation with the number of system calls
for a non-naive implementation, so I don't think the number of syscalls
here matters.
You read into a buffer, you append/pad/skip space for the header, read, etc.

The benefit to jumbo frames is solely that one can do fewer sendfile/splice
calls, at the cost of more framing complexity, and at the cost of having
naive implementations (especially server implementations) do things that
would affect performance/latency such that HTTP2 would be a downgrade.
Patrick mentions this, and it is a large motivator here-- getting the
muxing wrong, as is much more likely to happen with larger frame sizes,
means poor latency.

Experimentation with this seems reasonable as an extension.
-=R


On Wed, Jun 25, 2014 at 12:30 PM, Patrick McManus <pmcmanus@mozilla.com>
wrote:

> hey all -
>
>
>> Extensions are length limited to 16KB, so to allow that you would have to
>> define special framing rules, and if you have done that might as well apply
>> it everywhere.
>>
>
>
> I don't think that's the case at all. un-acked extensions are limited that
> way because you can't change the semantics of the protocol.. but once you
> ack something you can do anything you like - including changing framing to
> look like websockets via use one of the R bits (as an example). Go
> bootstrap h3 that way if you feel so inclined to write an extension like
> that.
>
> but maybe I have that wrong -(our extension text is brand new afterall)
> and extensions are meant to preclude such hackery which seems odd - given
> they are essentially a hackery escape hatch that already acknowledges the
> ability to change semantics of existing elements. If that's true there is
> always the alpn method of proving this can work - because I really don't
> think it can work and leave h2 responsive.
>
>
>
>> It’s a very common use-case.
>>
>>
>
> unfortunately its one that is in direct competition with the driving
> reason for h2: prioritized mux on one connection. Minimally you should
> prove out that can coexist with jumbo frames because spdy showed us it was
> a problem. You simply can't send a multi megabyte frame and also then
> respond quickly to a CANCEL and a new GET on the same connection which is
> something any h2 implementation should be able to handle responsively. My
> H1 application closes a ton of connections because of that pattern - h2
> doesn't have to. Its one of its under appreciated features. The cost of
> that feature, 16KB frames, is reasonable imo.
>
> and of course, then there is TLS.
>
> ship it.
>