Re: #541: CONTINUATION

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.

Yoav

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