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

William Chan (陈智昌) <willchan@chromium.org> Mon, 13 May 2013 21:59 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 E1CA121F8607 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 14:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.176
X-Spam-Level:
X-Spam-Status: No, score=-7.176 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 AmA0hre08RYl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 14:59:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61EC121F947C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 May 2013 14:59:18 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uc0lk-0001TZ-R4 for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 21:58:56 +0000
Resent-Date: Mon, 13 May 2013 21:58:56 +0000
Resent-Message-Id: <E1Uc0lk-0001TZ-R4@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1Uc0lZ-0001Sm-81 for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 21:58:45 +0000
Received: from mail-qc0-f170.google.com ([209.85.216.170]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1Uc0lY-0002jP-7s for ietf-http-wg@w3.org; Mon, 13 May 2013 21:58:45 +0000
Received: by mail-qc0-f170.google.com with SMTP id s11so3666295qcw.15 for <ietf-http-wg@w3.org>; Mon, 13 May 2013 14:58:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HbKpIa8qjYQ/9psvl6acopG/OcO+oEVNhdmnhJe51yo=; b=hc5YK3ttWyjP/hx0gN2p5ALHLZRtQl7x7PfmiYdtbbfRUXiPSuWYfnLH5FxVE3Qxq6 F0gkpmsMist+ouyVmauouvsLHUVd6kkxwVTyUarRWnCB+dwk/IyKW4RkieMGNKv+lGZP 4/2K+Ulj46U7zTVPZ01X9sBJ54kyEfBAgsXfaDyZVMjFa7LxGzT7exvE8wp8sXefLFJ4 oJVsi4PHG1QINJJoMzNXA4XlZR8itbhwddWCWfLEzSgkYu0AGM2xaF56jejlm9s7NN5V ehxJ48jJAEguX6rJR/cGuVjfuUVYSomwRb1+xACTPe22oO6i71GawnzeM7C/TsVmoNar igcw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HbKpIa8qjYQ/9psvl6acopG/OcO+oEVNhdmnhJe51yo=; b=h9YsiRVF2eyjbCu6k7TSIl2Ky2Pr5w8Ua3KV26wHcx4gBD02/Osgh3iLHQZUQ2i1Rg c6+Fj/g7iDpAbu8XQW2/Z66hTdbtV7u/HS61jFwIfxGcdr5XCVV8mmEzo7YSVVtzCZCE gLZkD5P1paLdb6wwJXd5mfyO+I2eJdgaDYpqE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=HbKpIa8qjYQ/9psvl6acopG/OcO+oEVNhdmnhJe51yo=; b=lPjZUaWpXaJtMGA1N3/kd77SIhSY5kZlkjcM7o2UczJkqg6wpfMtC/y+y0+2MLZPfn /L2A1++2Lm0y1nVivhtizqzt4aywGXDUYazZ3cCKIlar5vjUxBw/GCx4QtE6qLpG0Xxg Fa4qOFb9zjjs/JhvjnKWJfZGPRaB/EhJamMre+xxcEvUhg0O6BVeeXdMI7GvJqYu4+WZ ZVSFUBfeS44AjEcJwnJzShsGZv2ElEnxTuoAuRVvSSVvMzlx/zfycI9K+BmwHSvm4/bd yen1wb1beTVfv3xdrWYfsORMJgAnNmKaA7yD8724bNRfDUfp22V/fRA+KUU4LA/zotRA dEzg==
MIME-Version: 1.0
X-Received: by 10.224.11.199 with SMTP id u7mr22248488qau.76.1368482298451; Mon, 13 May 2013 14:58:18 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.61.25 with HTTP; Mon, 13 May 2013 14:58:18 -0700 (PDT)
In-Reply-To: <CABP7Rbe9rNi8Y5arMzBZqrRK_QyCruqH-zmHFQhG2xw6sRm3aA@mail.gmail.com>
References: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com> <CABkgnnWyVULO5r2boCpz23fTXezTogjmYLa25gwcT-9k4fxNzA@mail.gmail.com> <CABP7Rbe9rNi8Y5arMzBZqrRK_QyCruqH-zmHFQhG2xw6sRm3aA@mail.gmail.com>
Date: Mon, 13 May 2013 18:58:18 -0300
X-Google-Sender-Auth: FbuHSX_RHLu1k8AwJ03nH4rElOk
Message-ID: <CAA4WUYjj8HCd-4h+xuQwFBJX1TW4xL-2w_HtmraxBhvv8vaceg@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
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: multipart/alternative; boundary=089e0141a95e47f88404dca09dda
X-Gm-Message-State: ALoCoQksh6eI/K2xeEfTi/uh6YjXZjiAV3zjKdYX51g7RRJ7Qtv2kxsB+mDgCTJmfhCk9KHH1Sr1AyxQTG6Rtpj6zsKsf6HEQsOeI/mnMVA4arnaQGgX7nKpwNOyTXp1cwE64X8UlpJxSb+3xAVdaiBwMBusLvP4cqhaU4agvySPUQTJZf08ysh0GdehKCU+UM29cWUfyVCq
Received-SPF: pass client-ip=209.85.216.170; envelope-from=willchan@google.com; helo=mail-qc0-f170.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.418, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.629, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Uc0lY-0002jP-7s fe500211c86b0615b8c158ed6c224789
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/CAA4WUYjj8HCd-4h+xuQwFBJX1TW4xL-2w_HtmraxBhvv8vaceg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17980
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>

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