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

Re: Large Frame Proposal

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 9 Jul 2014 17:40:46 -0700
Message-ID: <CAP+FsNc_8NHU9H+Z+nZ2hqG2iPZ9Q=kX9WUOfaNervSULdaHjw@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: David Krauss <potswa@gmail.com>, Patrick McManus <pmcmanus@mozilla.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jul 9, 2014 at 5:21 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 10 July 2014 09:51, Roberto Peon <grmocg@gmail.com> wrote:
>> With a small framesize, that'll work just fine.
>> With a large framesize, that won't work. You may end up with single
>> frames which take seconds or even hours (4GB of data on a low bandwidth
>> link, for instance) to drain.
> Again with this strawman analysis!
> It is not a choice between small==good and large==bad.    There is a
> spectrum of possible frame sizes and picking a single arbitrary 16KB frame
> size is unlikely to be optimal in even a majority of today's networks.
> This proposal is to allow 32KB, 64KB 128KB frames much more than it is to
> occasionally allow a much larger frame.  In fact we have removed the
> WINDOW_UPDATE part of the proposal that would facilitate easy sending of
> very large frames for large content.

I'm happy with 64k as a max-representable framesize :)
128k is almost OK-- I'd just steal a bit from the type field.

I didn't personally mind the window-update part of the proposal, btw. I
thought it was reasonable given that negative windows already need
handling. *shrug*

> it would be interesting to perform an experiment on a fast network and
> compare user experience between multiplexed  traffic over 16KB frames vs
> 64KB frames.   I'm betting that most users will not notice the difference
> in terms in QoS/interruptability etc. but they will notice the faster down
> load times of images etc. with the large frame size.
> Regardless, the argument against this proposal based of the fact that
> sending a 2GB frame will break multiplexing is a straw man.  Just because a
> mechanism can be misused is not a sufficient argument against it.   In this
> case, large frames requires the collaboration of both peers, while large
> headers can currently be sent by a single peer (Even if it will get 431'd)

I'm fairly sure it isn't a strawman since I'm talking about evidence of
misuse of the capability of sending large frames as evidenced in SPDY :)
Regardless, I'm saying that the current framesize was a direct reaction to
that experience and evidence.

Lets assume that we're OK with larger frame sizes.
At that point the question becomes: How large should the length field be?
Imho, 64k for a frame is plenty large: 2048 frames/gig seems cheaply doable.

I've said it elsewhere, in other ways but:
I'm down with a larger max framesize (within limits: I feel that even 2^24
is pushing it).
I'm supportive of a setting for max framesize.

> regards
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
Received on Thursday, 10 July 2014 00:41:14 UTC

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