Re: Large Frame Proposal

On Tue, Jul 8, 2014 at 11:42 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Allowing a large frame-size setting for any stream implies a loss of
> reactivity for all other streams within that connection, so long as the
> stream with the larger framesize is used.
>

yes. "all other" plus "all future" streams.. cancel is a big deal here.

>
> Essentially, it adds HOL blocking in. A frame size of 2^32, would
> potentially imply seconds of latency, and a failure of the protocol to
> deliver adequately.
>
>
yes. Most of the value of h2 is in prioritized mux - it makes sense that
the protocol operates in a way that makes that work. If we could figure out
how to disable buffering I would support that too :)

greg's proposal is a worthwhile extension for those that are interested.
We made the same extension decision for alt-svc even though that also deals
with a core property of the protocol.



> I still find it amusing (in an " I'm so sad that we keep conveniently
> overlooking these things" kind of way) that we're still talking about large
> frames being any kind of improvement at all in the web context when one
> still needs to traverse the TLS library in order to get HTTP2 working
> anyway, and when larger frame sizes cause problems with reactivity, and
> thus induce latency.
>
>
yes.