W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Large Frame Proposal

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 9 Jul 2014 08:10:36 -0400
Message-ID: <CAOdDvNp8kreZ-LEyOe2TipGjNofzYvecupz-9RD4Z7FPSF8d9w@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: David Krauss <potswa@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Wednesday, 9 July 2014 12:11:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC