Re: Design Issue: Frame Size Items

On Tue, May 7, 2013 at 11:07 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 7 May 2013 08:19, James M Snell <jasnell@gmail.com> wrote:
>> 1. There is an existing ed note in the draft indicating that we
>> currently do not have any way of specifying the maximum frame size.
>> There are several possibilities:
>>
>>   a. We decide we don't need to report a maximum frame size.
>
> This has been discussed.  The problem is that you have to then FIX the
> maximum frame size and require that all implementations support that
> size.  No one can decide on a goldilocks number: 4096, 8192, 16384,
> 32768 or 65536 have all been variously proposed.  Others want to add
> extra bits to the length field to open up other options (i.e.,
> petabytes).
>
>>   b. We introduce a MAX_FRAME_SIZE setting for the SETTINGS frame.
>
> This introduces another "known state" issue (see Gabriel's issues).
> You have to have a default (see above), and then a robust way to
> change.
>

Option (b) certainly isn't perfect but it works. Since our frame size
field is expressed as an unsigned 16-bit integer, we already have a
fixed maximum size (2^16-1 + 8) which ought to be the default
MAX_FRAME_SIZE. If an implementation needs it to be smaller, they can
specify so using the SETTINGS.

>>   c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..
>
> I'm not following you.
>

I was being silly.. never mind ;-)

>>   I think I prefer option (a) but (b) works too.
>>
>> 2. In the current draft we say that all implementations MUST be
>> capable of supporting frames up to 8192 octets in length. We don't
>> say, however, whether that size includes the 8-byte header or is that
>> just payload octets?
>
> That's a simple fix.  Toss a coin.  ;)

Ok, coin toss says the 8-byte header is not included. That work for everyone?

- James

Received on Tuesday, 7 May 2013 19:08:15 UTC