RE: #540: "jumbo" frames

Great idea, though I would vote for the ASN.1 variable length integer style because (if I understand correctly - which is probably not true), the HPACK variable length integer is designed to work on non-byte boundaries because of the huffman encoding.



-keith





On Wednesday,25 June 2014 12:24, gregw@intalio.com wrote:

>

> 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.