Re: #540: "jumbo" frames

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>
wrote:

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