W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: <K.Morgan@iaea.org>
Date: Mon, 14 Jul 2014 13:42:27 +0000
To: <ynir.ietf@gmail.com>, <phk@phk.freebsd.dk>
CC: <ietf-http-wg@w3.org>
Message-ID: <0356EBBE092D394F9291DA01E8D28EC201187F1409@SEM002PD.sg.iaea.org>
On Monday,14 July 2014 11:21, phk@phk.freebsd.dk wrote:
> Why should we force applications for whom 256 is plenty to use something
> higher ?  Who gains anything by us doing so ?  And if we insist on some lower
> limit which is onerous for tiny devices, do you think they are going to spend 8
> times more for their microcontroller or ignore what we say ?

I think the issue can be broken down as follows:

1) What, if anything, is required if an endpoint's peer advertises a MAX_FRAME_SIZE *greater* than 16K?
2) What, if anything, is required if an endpoints' peer advertises a MAX_FRAME_SIZE *smaller* than 16K?

For 1), greater than 16K,
I think the answer is obvious.  The endpoint can either ignore the setting from its peer and continue using 16K as a max frame size, or if the endpoint so chooses, use larger frames up to the MAX_FRAME_SIZE declared by its peer.

For 2), smaller than 16K,
the answer is not so obvious.  I brought this up before, but it was ignored.  Is the endpoint allowed to continue using any frame size up to 16K, or is the endpoint *required* to honor MAX_FRAME_SIZE?

Allowing an endpoint to ignore settings below 16K makes the setting symmetric i.e. MAX_FRAME_SIZE is optional either way.  It also allows simple implementations to use a fixed 16K frame buffer and ignore the setting altogether.

On the other hand, resource-constrained implementations (e.g. IoT devices) would benefit, as PHK points out, from being able to use a much smaller frame buffer and force the peer to send frames that small.

-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 13:43:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:20 UTC