Re: #540: "jumbo" frames

Jumbo frames could easily be achieve without and extension bit if we change
the frame header to:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|                 Stream Identifier (31)                      |
    +-+-+-----------+---------------+---+---------------------------+
    |   Type (8)    |   Flags (8)   | R |     Length (14+)          |
    +-+-+-----------+---------------+---+---------------------------+
    |                   Frame Payload (0...)                      ...
    +---------------------------------------------------------------+

Where the length (14+) is the same variable length integer encoding used by
hpack.

This would support truly infinite frame sizes if desired, does not burn any
reserved bits and is not a hacked on extension, but just an specific length
encoding.

cheers





On 25 June 2014 11:35, <K.Morgan@iaea.org> wrote:

> On Wednesday,25 June 2014 06:11, mnot@mnot.net wrote:
> >
> > The simplest way to address this would be to un-reserve the first two
> bits of the length
> > <http://http2.github.io/http2-spec/#rfc.section.4.1>; that would get us
> back up to 64k,
> > letting Willy get to 35 Gbps. Given that 256k only got him to 40 Gbps,
> that seems like a
> > reasonable stopping point for HTTP/2.
>
> Bad idea IMO.  That would really paint HTTP/2 into a corner.  With no
> reserved bits left, there would never be a chance to go above 64K frames.
>  i.e. you could never " back-port bigger frames onto an existing protocol"
>
>
> > Doing more than 16 bits would take a lot more back-and-forth in the WG,
> > and is likely to encounter a lot of resistance from implementers, from
> what I've seen.
>
> We've been talking about jumbo frames for a week already and there hasn't
> been any resistance from "implementers".
>
> I'll point out again that jumbo frames are optional.  As Matthew points
> out, the proposed setting can simply be ignored.
>
>
> > WRT the "jumbo" frame (i.e., flagging that some prefix of the payload is
> actually an extension length)
> > -- this sort of hack is necessary to back-port bigger frames onto an
> existing protocol. Let's not do it out of the gate.
>
> Then make the frame length 64 bits and be done with it.  That's a lot of
> wasted bits though for those who just want to use 16K frames.
>
> So barring a change to 64 bits, you need the CONTINUATION hack or the
> "jumbo frame" hack.  Which hack is better?
>
> So far I've heard the following arguments in favour of "jumbo frames":
> - Willy: higher performance for large data sets
> - PHK: higher efficiency due to fewer system calls
> - Greg: easier to describe and understand (keith: less error prone)
> - "unlimited" HEADERS (albeit capped at some crazy large number)
>
> So far I've heard the following arguments in favour of CONTINUATION:
> - Greg: truly unlimited HEADERS
>
> 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.