W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Framing and control-frame continuations

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 07 Feb 2013 13:36:23 +1300
Message-ID: <5112F707.2070406@treenet.co.nz>
To: ietf-http-wg@w3.org
On 7/02/2013 8:04 a.m., James M Snell wrote:
> A reasonable compromise here would seem to be: let's place limits on 
> control frame size but allow data frames to be variable with 32-bit 
> lengths. Done properly, control frames should never be too large. 
> Doing so ought to encourage developers to keep control-frame overhead 
> at a minimum while allowing optimization of data flow (honestly, I 
> think allowing 32-bit length control frames is just asking for trouble 
> by encouraging bad behavior). This would mean moving type and flags 
> before length.

See my alternative framing proposal mailed earlier.

We picked 24-bit length as an intermediary size between 16 and 32 bits 
which allows MB sized frames and also allows some frames to have the top 
8 bits defined as mandatory 0's for frames which need a smaller size 
limit. OR, the top 8 bits can be defined as a partial base when doing a 
compound mantissa. There is a vast size range that 24 bits can be used 
for. Same can be said for an aligned 16-bits, but the 'odd' 24-bits size 
lends itself better to use in complex length encodings if we want one (I 
don't think we do though).


Amos


>
>
> On Wed, Feb 6, 2013 at 6:30 AM, Poul-Henning Kamp <phk@phk.freebsd.dk 
> <mailto:phk@phk.freebsd.dk>> wrote:
>
>     Content-Type: text/plain; charset=ISO-8859-1
>     --------
>     In message
>     <CAP+FsNfTZ56An-g3qa5Xo6+ZH_hBUHFM2shHrn-NmM6VWzS_oQ@mail.gmail.com <mailto:CAP%2BFsNfTZ56An-g3qa5Xo6%2BZH_hBUHFM2shHrn-NmM6VWzS_oQ@mail.gmail.com>>
>     , Roberto Peon writes:
>
>     >In any case, if/when we implement and there are real performance
>     >bottlenecks, we can rev the protocol [...]
>
>     Yeah, and 640k is enough for everybody, trust us, we've tested this.
>
>     Sorry for getting a bit sarcastic here, but I am frankly flabbergast
>     here that anybody can even propose a <64kByte framesize for a protocol
>     which will not emerge from standardization for another five years
>     and which is supposed to last at least 10 years after that.
>
>     Just make it 32 bit length, and move on, ok ?
>
>     --
>     Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>     phk@FreeBSD.ORG         | TCP/IP since RFC 956
>     FreeBSD committer       | BSD since 4.3-tahoe
>     Never attribute to malice what can adequately be explained by
>     incompetence.
>
>
Received on Thursday, 7 February 2013 00:36:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2013 00:36:57 GMT