- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 25 Jun 2014 15:15:53 -0500
- To: Roberto Peon <grmocg@gmail.com>
- Cc: K.Morgan@iaea.org, Patrick McManus <pmcmanus@mozilla.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
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
Received on Wednesday, 25 June 2014 20:16:57 UTC