Re: Large Frame Proposal

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.

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.

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.

Larger framesizes matter only for non-TLS connections.
That is why I'll hope that most browsers and most servers pick framesizes
that are proportional to the TLS record size, and that are relatively small
(e.g. 16k or less).

I'm happy with 16 bits of length. 24 bits of length will slow things down
marginally in the common case as we're putting 8 more '0's on the wire for
nothing almost all the time.

-=R


On Tue, Jul 8, 2014 at 8:22 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014–07–09, at 10:56 AM, Greg Wilkins <gregw@intalio.com> wrote:
>
>
> On 9 July 2014 12:35, David Krauss <potswa@gmail.com> wrote:
>
>> Dynamic changes are unlikely to happen in practice;
>
>
> If the proposal is accepted, Jetty is definitely planning on modifying our
> server to adjust the frame size setting to a large value when we see a
> single large upload on a request.
>
> We will do the same for our client for downloads.
>
>
> OK, I suspected I was having a failure of imagination anyway :P .
>
> It seems pointless to only keep the frame size small only while little is
> being received anyway. Perhaps you intend to reduce the frame size when a
> request is received in the midst of a long data reception? This would
> trade-off HOL blocking against performance, as a single HOL block event
> would restore performance for subsequent requests.
>
> I’m a bit skeptical of this scheme. The server is not responsible for (and
> barely capable of) fine-tuning the client’s request+upload stream. Could
> you confirm whether I’m thinking along the right lines?
>
> While I would have preferred a per stream limit for dynamic changes (to
> match the per stream flow control window) as per the original proposal,
> I've accepted the argument made by Martin that having that as an optional
> part of the specification makes unlikely to be useful.  A dynamic setting
> for the connection can be used almost the same.         But eitherway, I
> think the limit should be considered as part of the flow control algorithm
> and thus is naturally dynamic.
>
>
> A per-stream setting would be nice. If I were designing from a clean
> slate, multiplexing would be strictly a lower layer and flow control would
> be a separate protocol contained within each stream. For better or worse,
> we still have multi-connection as a fallback.
>
>