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

James M Snell <jasnell@gmail.com> Mon, 13 May 2013 22:05 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55AA21F949A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 15:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.432
X-Spam-Level:
X-Spam-Status: No, score=-9.432 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug-3O17Gg-sW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 15:05:24 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1989B21F9488 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 May 2013 15:05:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uc0rS-0007KV-8w for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 22:04:50 +0000
Resent-Date: Mon, 13 May 2013 22:04:50 +0000
Resent-Message-Id: <E1Uc0rS-0007KV-8w@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1Uc0rH-0007Ho-8N for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 22:04:39 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1Uc0rG-0002tr-LA for ietf-http-wg@w3.org; Mon, 13 May 2013 22:04:39 +0000
Received: by mail-ob0-f177.google.com with SMTP id uz6so2241529obc.22 for <ietf-http-wg@w3.org>; Mon, 13 May 2013 15:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=L6VBLsj8XBHd+MW0XXvsXbgxvvvmFkkKxH3sWQNpo4E=; b=RSQ3piytNtc2MNtUy9KIF1sqI5+tGzftrf6xFhiijAdaIUCS1bJFzwl2EhX2jOx92G G6g8AH+JUNRAiU07Fc5wqDsVcXmPctYjDoZ1QyJ/jCJFTTdO1glUNLn5lG2Swp06NZEy CNQ8nA08u+3aT3jTiiYOR3biVnCSa7JgmlEwSyjoSRS82EomHUBsbMCMtEtfVUQC8bqK /LugdufNePqOW7J0duAlqoR4KOixf341LoeJjQ6iHIFC4zUVel2CYCNMnS5oneLs5w5F EWOUKtN2tPk+aO/uCRlALrN6mFTFLd4y71eCPD6vghRkyuMBWjWc9eBQYV7CNMw8+ccv eqdQ==
X-Received: by 10.60.60.10 with SMTP id d10mr14268390oer.6.1368482652488; Mon, 13 May 2013 15:04:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Mon, 13 May 2013 15:03:52 -0700 (PDT)
In-Reply-To: <CAA4WUYjj8HCd-4h+xuQwFBJX1TW4xL-2w_HtmraxBhvv8vaceg@mail.gmail.com>
References: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com> <CABkgnnWyVULO5r2boCpz23fTXezTogjmYLa25gwcT-9k4fxNzA@mail.gmail.com> <CABP7Rbe9rNi8Y5arMzBZqrRK_QyCruqH-zmHFQhG2xw6sRm3aA@mail.gmail.com> <CAA4WUYjj8HCd-4h+xuQwFBJX1TW4xL-2w_HtmraxBhvv8vaceg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Mon, 13 May 2013 15:03:52 -0700
Message-ID: <CABP7RbfVHvjWJt4SkKcnQV8S+juTRnK27c6ecQiYPe9U7AZ5VQ@mail.gmail.com>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.177; envelope-from=jasnell@gmail.com; helo=mail-ob0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.683, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Uc0rG-0002tr-LA 4ef41fc158afd3fa6a222426111a43c3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)
Archived-At: <http://www.w3.org/mid/CABP7RbfVHvjWJt4SkKcnQV8S+juTRnK27c6ecQiYPe9U7AZ5VQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17981
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.
>
>