W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 23 Jun 2014 22:36:34 +1000
Message-ID: <CACweHNDvJ7w9kZ7VmvyPv3hDk68cx+fXG1vT4-iJ2AiSQFtYEg@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: phk@phk.freebsd.dk, mnot@mnot.net, squid3@treenet.co.nz, ietf-http-wg@w3.org
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
Received on Monday, 23 June 2014 12:37:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC