- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Mon, 23 Jun 2014 22:36:34 +1000
- 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