Re: Framing and control-frame continuations

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <10784.1360140687@critter.freebsd.dk>, "Poul-Henning Kamp" writes:
>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.)

Hmm, maybe we should simply make the length field 32 bits, that would
be easier for everybody, and still not increase overhead too much.

-- 
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:58:36 UTC