Re: Design Issue: Frame Size Items

Going back through this, here's a counter proposal:

Let's get rid of the 8192 frame size rule and simply say that the
maximum size for all DATA, HEADERS, HEADERS+PRIORITY and PUSH_PROMISE
frames is either 65,535 or the current flow control WINDOW_SIZE,
whichever is less. That way, if a device needs a smaller frame size,
it uses the existing flow control mechanisms to specify it.

Along with that, we would declare that flow control applies to header
bearing frames in addition to data frames and add language encouraging
implementations to never encode header bearing frames larger than the
current TCP MSS (if known)

- James



On Tue, May 7, 2013 at 11:34 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <CABP7Rbe+N+JEesvsV4EeQnc-7YSyiUmp2_46cD7znAA9OcNTZQ@mail.gmail.com>
> , James M Snell writes:
>
>>Proposal: Let's define that 8192+8 is the default MAX_FRAME size.
>
> 8192 is a pretty arbitrary choice, wouldn't it make sense to do a
> bit of math on typical MTU's and TCP/IP header sizes and see if
> any numbers work out more optimal ?
>
> --
> 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, 8 May 2013 19:50:09 UTC