Re: #540: "jumbo" frames

The sender determines how to apportion data into frames. We were seeing
whole files transmitted as a single frame.
And again, in the web use-case this is not going to be a measurable
difference in utilization, since we're likely to be using TLS.
-=R


On Wed, Jun 25, 2014 at 1:15 PM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Jun 25, 2014, at 3:06 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> >
> >
> >
> > On Wed, Jun 25, 2014 at 1:00 PM, <K.Morgan@iaea.org> wrote:
> > On 25 June 2014 21:48, grmocg@gmail.com wrote:
> > > The same is true for any other optional thing under the sun.
> > > It doesn't seem to be a motivating argument for including more
> optional features, though.
> > > -=R
> >
> > That's not the point.  Patrick implied that adding the jumbo frame
> option kills the ability to efficiently mux.  That's simply false.
> >
> > A jumbo frame option requires the implementation to be smart to before
> the protocol becomes effective/useful for web traffic.
> >
> >
> > On Tuesday,22 April 2014 09:00, fielding@gbiv.com said [1]:
> > "Likewise, restricting packet sizes to a small length in order to
> prevent fools from HOL blocking
> >  their own multiplexed channels makes some sense, for browser developers.
> >  However, it actively harms applications of HTTP that are not interested
> in multiplexing
> >  because they only want to transmit a single large data stream.
> >  ... I don't think it makes sense to limit an application-level protocol
> to the worst case.
> >  ....Roy"
> >
> > So let's be straight.  There are legitimate use cases for jumbo frames.
>  You and Patrick just think the world is full of a bunch of what Roy calls
> "fools" (see above) who will HOL block their own multiplexed channels.  Roy
> (and I) don't disagree.  Roy (and I) don't think it makes sense to limit
> the protocol to protect against an unknown number of fools.
> >
> > Keep in mind that the original SPDY had much, much larger max
> framesizes, and I designed it that way in concert with Mike.
> > Implementation experience, however, provided hard data that this
> actually happens, and harms the user.
>
> Happens from where, the browser? Since the browser controls the channel,
> it can simply set whatever frame size it wants.
>
> If it wishes to implement fast downloading of large files, it can simply
> open a new connection using the larger size and limited to no multiplexing.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>