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

Yep, that's perfectly fine. As I've said, I'm just making sure these
items are documented and tracked. It may be that things are just fine
the way they are but we won't know for certain until we've tested the
hell out of everything :-) (And to be completely honest, I'm not
really all that concerned with whether the large scale implementations
have issues with this... my concerns are more with devices and
implementations working at the lower-end of the spectrum)

On Mon, May 13, 2013 at 2:58 PM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> That's kinda why I don't really want to take this change as is now. I'd
> rather wait for more implementation experience. AFAICT, we have at least 3
> very large scale SPDY server deployments (Google, Twitter, and Facebook),
> and none of them have yet asked for this to be fixed. Maybe they're fine
> with just not calling read() in these situations. I'd rather wait for people
> deploying SPDY & HTTP/2.0 draft implementations to come back and say that
> this is actually a problem and we need to fix it.
>
>
> On Mon, May 13, 2013 at 6:45 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> 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 22:04:39 UTC