Re: #540: "jumbo" frames

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.

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!)

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.
--
Peace,
  -Nick