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

Re: #540: "jumbo" frames

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 25 Jun 2014 10:38:10 -0400
Message-ID: <CAOdDvNq7oOqPDOj+MFC3v-Q052OMdib2HzraDfq_+=AiUVxtPA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: K.Morgan@iaea.org, 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 Wed, Jun 25, 2014 at 6: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.
>

indeed. If the IETF process can't converge to something we can ship after
all this time, based on experience with running code both before and during
the process, there isn't a lot of point of discussing it in this forum.
Redoing the base framing at this point is fairly close to declaring IETF
fail at this stage. I would hope we wouldn't do that.

different pov's will continue to crop up and the wg has decided to have an
extension mechanism available to try some of them out among their own
advocates. (as we know, I'm not a huge fan of that - but there it is.) This
will get runtime experience with them. Changing framing is certainly
something that can be done this way. It takes a RTT to take effect but the
swtichover can certainly take place mid stream among consensual peers. (so
it need not add a rtt of overall latency).

it would be interesting to get experience with an extension that did this
and bundled a MAX_CONCURRENT of 1 semantic (or requirement) with it
because you can't really expect to mux successfully in such an environment.
At that point the value of running h2 is kind of questionable - h2
fundamentally needs mux and priority. And that's why I think this whole
path is the wrong thing to do.

I'm looking at a spdy trace right now that sends huge frames because it was
convenient for the developer to do so - and priority doesn't work at all as
a consequence. That's real feedback that improved h2 over spdy.

-P
Received on Wednesday, 25 June 2014 14:38:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC