Re: #540: "jumbo" frames

I really don't understand why when it is pointed out that a significant
user base will have their user experience degraded without large data
frames, the response is: "go do that in an extension".

Yet when it is pointed out that a tiny fraction of traffic uses large
headers, the response is that we have to live with the known annoyance of
an acknowledged ugly kludge that has been only sparingly implemented/tested
and additional several DOS vectors.

Continuations are jumbo frames!  They are just really bad jumbo frames that
only apply to headers, can't be efficiently handled and don't have a
mechanism for end points to pre declare max acceptable sizes.   General
jumbo frames would handle the headers use-case, but also provide a solution
for those who need efficient large data.

h2 should either just support general jumbo frames for both headers and
data or no jumbo frames for either.  By supporting jumbo headers, but not
jumbo data, a double standard is being applied.

Anyway, enough said (by me) on this one.  If the chair really thinks that
the issues of large data have been given the same consideration as those
for large headers, then we have no issues to discuss here.

cheers








On 25 June 2014 23:26, Roberto Peon <grmocg@gmail.com> wrote:

> But it does not remove the continuation 'kludge'. It substitutes one
> 'kludge' for another 'kludge' and doesn't change the orthogonal requirement
> to handle arbitrarily large headers...
>
> Continuation has the advantage of being a known annoyance.
> There have been proposals for requiring that CONTINUATION (and similar
> non-stream-initiating-HEADERS frames) carry only non-state-modifying data,
> in which case many of the annoyances w.r.t. continuation go away.
> I'd prefer investigation into avenues like that, personally.
>
> Jumbo frames have the disadvantage of folks not realizing the harm they
> cause, and then causing it anyway.
> -=R
>
>
> On Wed, Jun 25, 2014 at 2:04 PM, <K.Morgan@iaea.org> wrote:
>
>> On 25 June 2014 22:22, grmocg@gmail.com wrote:
>> > The sender determines how to apportion data into frames.
>> > We were seeing whole files transmitted as a single frame.
>> > -=R
>>
>> The sender can only apportion data into frames less than
>> SETTINGS_MAX_FRAME length; and if you never change it, he has to use 16K or
>> less.
>>
>> This is exactly the point. The jumbo frames eliminates the CONTINUATION
>> "kludge" & allows use cases which need jumbo frames to have them if the
>> peer gives consent.  All while not preventing efficient muxing with 16K
>> frames.
>> This email message is intended only for the use of the named recipient.
>> Information contained in this email message and its attachments may be
>> privileged, confidential and protected from disclosure. If you are not the
>> intended recipient, please do not read, copy, use or disclose this
>> communication to others. Also please notify the sender by replying to this
>> message and then delete it from your system.
>>
>
>


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.