#540: "jumbo" frames

<https://github.com/http2/http2-spec/issues/540>

On 24 Jun 2014, at 11:24 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <20140624102030.GC25779@1wt.eu>, Willy Tarreau writes:
> 
>> Instead, (I remember that it was already discussed here in the past), I
>> really think we'd need to support large frames for large data sets, that
>> are typically usable for such sites which have few streams per client but
>> very large ones.
> 
> I agree.
> 
> Moving objects which are trivially megabytes and gigabytes in size
> using 16kB frames just doesn't make any sense, in particular not
> given that MTUs above 9K are actively being discussed again.


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.

Personally, I think that's a reasonable change -- the argument for 14 bits was to make sure people didn't abuse multiplexing and that they properly implemented continuation, etc.; I think those goals could be met by some prose in the spec and proper testing.

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.

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.

Those are just my personal impressions. I'd very much like to hear from other folks in the WG what they think.

Regards,

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 25 June 2014 04:11:18 UTC