Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)

[James M Snell <[e-mail]>]

On Fri, May 10, 2013 at 11:11 AM, Roberto Peon <[e-mail]> wrote:
> The continuation bit is necessary for headers at a minimum, as we do have
> headers which are > 65k, and something indicating either
> end-of-semantic-header-block is necessary to support that.
>
>
> I don't understand why it makes sense to limit header frames by the window
> size.
> what if the window size is zero?
> What if it is 1 byte.
>

If the window size is unreasonably low, then communication would not
be possible. Simple as that.

Or, we can go ahead and set a lower-bound also.. say frame size is <=
min(WINDOW_SIZE,65k) && > 1k .. the low bound is fairly arbitrary and
we can set that at whatever is reasonable.

The rationale for tying this to window size is to limit the number of
knobs that have to be turned to control the communication flow. window
size is already established as the amount of data the receiver is
willing to accept at any given time, it's reasonable to consider that
significant thought will have gone into establishing that window size
and that it will be tuned to achieve maximum network utilization.

- James

> I don't see any real benefits for limiting control frames to anything having
> to do with the window size as compared to sending a SETTING and having the
> default before there and having it completely decoupled from window size,
> and I do see a number of complications and ewws :/
> -=R
>
>
> On Fri, May 10, 2013 at 10:58 AM, Hasan Khalil <[e-mail]> wrote:
>>
>> While I love the idea of limiting frames to 65535B, I hate the idea of a
>> continuation bit.
>>
>>     -Hasan
>>
>>
>> On Fri, May 10, 2013 at 1:54 PM, Martin Thomson <[e-mail]>
>> wrote:
>>>
>>> On 10 May 2013 10:40, William Chan (陈智昌) <[e-mail]> wrote:
>>> > [...] are we going to move forward with the frame
>>> > continuation bit?
>>>
>>> I think that this was implicit in our decision to limit frames to
>>> 65535 bytes (or less).
>>
>>
>