Re: #540 jumbo frame, was: Stuck in a train -- reading HTTP/2 draft.

I like the concept of jumbo frames.

If we are to get rid of CONTINUATIONS, then a single
SETTINGS_MAX_FRAME_SIZE may not sufficient to replicate what we currently
have.  Currently headers + continuations are unlimited in combined size,
while data frames do have a fixed limit.

So we might need to have a separate settings for HEADERs, with an unlimited
possibility if we are to replicate exactly what we have.   Personally I
think that end points should declare the maximum header size they are
prepared to handle as I doubt there are truly unlimited impls out there.

I also think that the window update should be enhanced to include the
ability to increase the allowed frame size for a stream.   This would allow
a client that has started receiving a download to note that a) it is large;
b) there are no outstanding requests for other resources; c) there are no
outstanding push promises; hence it can make the decision to increase frame
size for the stream without a immediate problem of HOL blocking.  Of course
new requests can always arrive, but the endpoint can make a determination
about a balance between HOL risk and efficient data transfer.

If the client really goofs and increases the frame size to be too large,
then it can always open another connection if a new request turns up and
there is no expectation of an imminent finish to the large frame being
received.

Jumbo frames removes the complexity of CONTINUATION at the cost of the
jumbo frame mechanism, which is probably not a lot simpler.  However it is
easier to describe and understand.  It is equally simple for impls to
ignore if they wish to not support large frames, however there is added
incentive for impls to support it because it does support a mode for
efficient large downloads.

Note that it does not allow headers to be flow controlled - so it is not a
perfect solution to all the issues raised about headers.

cheers











On 24 June 2014 17:47, <K.Morgan@iaea.org> wrote:

> Added this as issue #540: https://github.com/http2/http2-spec/issues/540
>
> -keith
>
> On Monday,23 June 2014 17:55, jasnell@gmail.com wrote:
> +1... especially if it means getting rid of CONTINUATION.
>
> On Mon, Jun 23, 2014 at 5:36 AM, Matthew Kerwin <matthew@kerwin.net.au>
> wrote:
> > On 23/06/2014, K.Morgan@iaea.org <K.Morgan@iaea.org> wrote:
> >> On Sunday,22 June 2014 14:36, phk@phk.freebsd.dk wrote:
> >>> , Matthew Kerwin writes:
> >>>
> >>>>I realise I should probably clarify my thoughts on what to do if a
> >>>>single header doesn't fit in a 16K frame.  The option I like best
> >>>>comes from one of PHK's earlier posts, where one of the reserved
> >>>>bits in the frame header is used as a "jumbo frame" marker such that
> >>>>if it's set the first, say, four octets of payload space is actually
> >>>>an extra 32 bits of payload length
> >>>
> >>> I would have it be the max length of *any* frame we're willing to
> >>> accept, and the default would then obviously be the 16kbyte
> >>> currently implicit in the standard.
> >>>
> >>
> >> So are you proposing the "jumbo frame" marker for all frames, not
> >> just the HEADERS frames?
> >
> > I suppose so. It makes no sense on a fixed-length frame like PING, but
> > it simplifies the machinery no end if all frames have the same
> > handling -- that's the whole idea, in fact.
> >
> >> I think it's a great idea, but I know it makes a bunch of people
> >> nervous about HOL blocking if you allow more than 16K in a DATA
> >> frame.
> >>
> >
> > Hence the setting.
> >
> > --
> >   Matthew Kerwin
> >   http://matthew.kerwin.net.au/
> >
>
> 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.