Re: #540: "jumbo" frames

On Jun 25, 2014, at 1:48 PM, Nicholas Hurley <hurley@todesschaf.org> wrote:

> On Wed, Jun 25, 2014 at 3:56 AM, Mark Nottingham <mnot@mnot.net> wrote:
> On 25 Jun 2014, at 7:35 pm, <K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:
> 
> > We've been talking about jumbo frames for a week already and there hasn't been any resistance from "implementers".
> 
> So far we’ve had a voluminous discussion among a small set of people who agree on generalities but not a single proposal, and only one of them has an actual implementation on offer.
> 
> I’d suggest that the reason why the rest of the implementers list hasn’t jumped in is because they’re busy getting draft-13 done, which we said we intended to go to WGLC any day now.
> 
> Making such a radical change to the protocol at this stage is going to need broad, strong agreement. I’m expressing doubt about the likelihood of that because so far, the interested parties haven’t converged on a single proposal, and (again) because none of the proposals are informed by running code.
> 
> (co-)Implementer of 2 implementations chiming in...
> 
> Exactly. Jumbo frames seem like prime candidates for an extension, especially since no one can seem to come together on a single plan for what they would look like. And given that we've already removed things from the spec that had some actual implementation experience (or at least broad implementer interest - I'm thinking ALTSVC and BLOCKED), I see no reason to add something to the spec just before WGLC.

Extensions are length limited to 16KB, so to allow that you would have to define special framing rules, and if you have done that might as well apply it everywhere. 

> 
> If the procedural concerns aren't enough (they don't seem to have been in the past, so I'm not sure they will be now), let's talk about actual experience. We have running code, right now, from a good number of implementers, that works with the regular-sized frames as currently in the spec. The current frame layout is simple, easy to parse, and easy to make decisions about. With all the perceived "complexity" that people have been complaining about, I'm honestly a little surprised that people are asking to add even more complexity (some of whom seem to be the same people complaining earlier!)

The rough proposals are trivial changes thought. We are talking about a small change to a length value and a new setting to negotiate. 

> 
> I'm not convinced by the arguments around large file downloads - those are the exception rather than the rule. Optimize for the common case. In HTTP, that means viable multiplexing and priority, both of which are much more effective with frame size limited to 16k like we have it now.

It’s a very common use-case.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Wednesday, 25 June 2014 18:56:23 UTC