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
  http://matthew.kerwin.net.au/
Received on Monday, 23 June 2014 12:37:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:27 UTC