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

On 14 Jul 2014, at 16:19, "phk@phk.freebsd.dk" <phk@phk.freebsd.dk> wrote:
>
> In message <0356EBBE092D394F9291DA01E8D28EC201187F1409@SEM002PD.sg.iaea.org>, K.Morgan@iaea.org w
> rites:
>>> 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?
>
> Substitute "whatever this endpoint prefers" for 16K, since 16K isn't magic either.
>
> Answer:  Send frames no larger than the smaller of the two endpoints wants.
>
> There can only ever be an issue with the first request, which is
> typically sent before the peers SETTINGS arrive.

Ok, now I understand. You're advocating for MAX_FRAME_SIZE to be a hard limit regardless of the default value. The default value of the setting is 16K, but an endpoint can immediately change that on connection open to something lower if it doesn't want to support 16K frames.  (This is also true with respect to the hpack table size setting default 4096 value.)

During the time between connection open and the ack of its settings, the endpoint has to decide to temporarily support frames up to 16K or RST_STREAM with STREAM_REFUSED and hope the client retries.

As I mentioned before, if I understood Jeff correctly, he didn't like this approach because he couldn't just always use a fixed 16K frame size.

-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:10:13 UTC