- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 06 Feb 2013 08:51:27 +0000
- To: Roberto Peon <grmocg@gmail.com>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=ISO-8859-1 -------- In message <CAP+FsNemzHOH1YrDXbEqy_dMB8h=e2pD0QrgLzkz+cUtdHMaRw@mail.gmail.com> , Roberto Peon writes: > 0 1 2 3 4 5 6 7 > +--------+--------+--------+--------+--------+--------+--------+--------+ > | Length(16) |Type(8) |Flags(8)| Num-of-Entries-or-Stream-ID-or-ID | -> > +--------+--------+--------+--------+--------+--------+--------+--------+ > > 8..N > +========+ > | Data | > +========+ > > Length: An unsigned 16-bit value representing the number of bytes of > the data field. I don't think this is good enough. You'd need ~20k of these frames a second to fill a 10GB ethernet, and a very large fraction of present day web-objects would require more than one frame already. We should take a clue from TCP's history of window-scaling and not fence ourselves into 64kbytes for all time, nor should we make the "X is enough for Y" mistake with a fixed horizon extension mechanism. I suggest: 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mantissa(14) | E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length = Mantissa * 2^(8*E) (I don't particularly care if we put the E field in the left or right side.) -- 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 08:51:50 UTC