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