Re: Call for Consensus: Frame size (to address #553)

On 14 Jul 2014, at 17:19, "jpinner@twitter.com" <jpinner@twitter.com> wrote:
>
> With a 10 byte header (to fit a 32-bit length field), setting the
> MAX_FRAME_SIZE to 256 is almost a 4% !! overhead in the transmitted
> bytes just for framing the data.

That's a trade off the embedded device has to decide to make when choosing 1) whether to use h2 at all*, and 2) what frame size to use.

*http used to be a no-brainier for many embedded devices


> I can't imagine I would do anything other than send a GO_AWAY and
> close the connection.

Why? Would you consider it a DoS? The point of the minimum was to disallow setting MAX_FRAME_SIZE to 1 byte which would only be useful for a DoS.


> Can we just keep the minimum frame size the same as today and use
> settings to increase only?

The point of the setting is to allow tuning the frame size up _and down_ for specific network conditions, etc.

e.g. Consider a mobile device that detects it's on a really slow network. It's in its best interest to tell the server to use smaller frames. Otherwise, as has been pointed out by Patrick, the server can't respond quickly to control frames from the client (e.g cancel stream).


> The argument against doesn't make sense to me, embedded clients
> already have to deal with a 16-bit IP length field so the idea that
> they can't handle a 14-bit HTTP length field seems absurd.

Your argument seems absurd :)

The device certainly doesn't receive 2^16 bytes in a single packet. There are micro-controllers that don't even have enough RAM to hold that much data. Rather, it will deal with the data packet-by-packet, frame-by-frame.

-Keith



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Monday, 14 July 2014 20:27:53 UTC