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


From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thu, 3 Jul 2014 10:07:22 +0300
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <2DEF2AD2-A6BB-4AB8-9686-08518080B2B7@gmail.com>
To: Mark Nottingham <mnot@mnot.net>

On Jul 3, 2014, at 9:36 AM, Mark Nottingham <mnot@mnot.net> wrote:

> On 3 Jul 2014, at 4:29 pm, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> On 2014-07-03 00:29, Poul-Henning Kamp wrote:
>>> PPS:
>>>   I'm looking for co-authors for a jumboframe extension draft.
>> Do you really need them? if you publish a sensible draft I expect several of us not liking CONTINUATION would implement.
> Would you (or any of the other Jumbo advocates) mind explaining why on its own itís better than CONTINUATION, beyond syntactic sugar?

(I probably donít really count as an advocate, but Iíll give it a try anyway)

I think it mostly is syntactic sugar, but it makes for a more sane layering of software. Youíre going to have a layer that deals with TCP (that does the actual SkRead). The next layer - letís call it the framing layer - will read a header (with length) followed by the body of the frame. Then, depending on the type of frame, it will move the data to some handler (data handler, header handler). 

With jumboframes (and more importantly - no continuation) the ďheader handlerĒ never needs to buffer - it can just handle the whole thing at once. A requirement that CONTINUATION frames immediately follow HEADERS/PP frames with no intervening frames achieves a close enough goal, and that is already in the draft.

So I donít think thatís a huge issue, as the data handler has to live with continuations (more DATA frames) anyways.

Jumboframes for data are a different issue. They have a marginal increase in efficiency (in that you donít have to send an 8-byte header every 16KB). Itís tempting to always send a data jumboframe that contains as much data as is either left or allowed by flow control, but I suspect that would have a really bad interaction with the flow control.

Received on Thursday, 3 July 2014 07:07:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC