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

Re: Framing and control-frame continuations

From: James M Snell <jasnell@gmail.com>
Date: Wed, 6 Feb 2013 11:04:39 -0800
Message-ID: <CABP7Rbdv-zuAg3=O6oHRqJY0=xBYsBZ7kQpV0cqjePjk3+O2EA@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Roberto Peon <grmocg@gmail.com>, Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
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.

On Wed, Feb 6, 2013 at 6:30 AM, Poul-Henning Kamp <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>
> , 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 Wednesday, 6 February 2013 19:05:28 UTC

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