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

Re: #540: "jumbo" frames

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Wed, 25 Jun 2014 11:48:08 -0400
Message-ID: <CAEn92TrQ3mOAwSmDRK_zrv_hVGzmywxa8EBUT+gtVYSMN6a-iw@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Mark Nottingham <mnot@mnot.net>, 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>
FWIW, I don't buy the premise that the current framing mechanism requires
more frequent system calls, or must imply "lower performance" for large
sends. One frame != one system call to write or read that frame.

Vectored IO API's are available to write multiple frames with a single
call. One could even repeat a common DATA frame header buffer in your iovec
array: No additional allocation required, over that of a single frame.
When running over SSL, one already has to perform a mapping of frames to
TLS records. It doesn't need to be 1:1.

On Wed, Jun 25, 2014 at 10:38 AM, Patrick McManus <pmcmanus@mozilla.com>

> 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 15:48:35 UTC

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