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

I'm not convinced it completely solves the problem either, but it at
least does something. I have the distinct feeling that the *right*
solution won't truly become obvious until we get better implementation
and testing across the board.

On Mon, May 13, 2013 at 2:33 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 8 May 2013 17:12, James M Snell <jasnell@gmail.com> wrote:
>> Suggested replacement text for the current "Frame Size" discussion in
>> the spec...
>>
>> ...
>>    While the flow control protocol and framing mechanisms defined by
>> this specification are largely independent of one another, the flow
>> control WINDOW_SIZE places an upper limit on the total amount of data
>> an endpoint can send to a peer at any given time. DATA, HEADERS,
>> HEADERS+PRIORITY and PUSH_PROMISE frame sizes MUST NOT exceed the
>> current WINDOW_SIZE for the stream or connection and MUST NOT be
>> greater than 65,535 bytes. The 8 bytes of the frame header are not
>> counted toward this limit.
>>
>>    When a new connection is established, both endpoints are permitted
>> to begin sending frames prior to the establishment of an initial flow
>> control WINDOW_SIZE. Accordingly, there is a risk that an endpoint
>> might initially send frames that are too large for the peer to handle.
>> To mitigate this risk, it is RECOMMENDED that, until the initial
>> WINDOW_SIZE is established, the total size of individual
>> header-bearing frames not exceed the current TCP Maximum Segment Size
>> (MSS) and that individual DATA frames are no larger than 4096 bytes.
>> The 8-byte frame header is included in these limits.
>>
>> If an endpoint is unable to process a frame due to its size and the
>> frame specifies any stream identifier field value other than 0x0, the
>> endpoint MUST respond with a <xref target="StreamErrorHandler">stream
>> error</xref> using the FRAME_TOO_LARGE error code. If the stream
>> identifier field value is 0x0, the endpoint MUST send a <xref
>> target="ConnectionErrorHandler">connection error</xref> using the
>> FRAME_TOO_LARGE error code.
>> ...
>
> I think that there is good advice here, namely: don't send a frame
> larger than the current window (actually, both of them) permits.
>
> What bothers me is that this is the only control on frame size.  And
> it's not a very good one.  Unless you are operating at the
> teeny-window end of the flow control space, then you probably want a
> wider open window than this.  And the commitment that processing a
> frame of size X imposes is greater than the commitment that buffering
> a frame of size X imposes.
>
> I'm not sure that this solves the problem.  At least not all of it.

Received on Monday, 13 May 2013 21:46:07 UTC