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

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

From: James M Snell <jasnell@gmail.com>
Date: Mon, 23 Jun 2014 08:54:58 -0700
Message-ID: <CABP7Rbc8DU4u39F_UFwH0r7PA_WN-NsMGiXZz5oJZfiy_Nq1Ow@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: K.Morgan@iaea.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
+1... especially if it means getting rid of CONTINUATION.

On Mon, Jun 23, 2014 at 5:36 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> 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 15:55:50 UTC

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