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

William Chan (陈智昌) <willchan@chromium.org> Thu, 09 May 2013 21:04 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 DE31A21F8F11 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 14:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[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 OEU5zkcfgMgG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 14:04:07 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6243821F8EF7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2013 14:04:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UaXz0-0006mb-78 for ietf-http-wg-dist@listhub.w3.org; Thu, 09 May 2013 21:02:34 +0000
Resent-Date: Thu, 09 May 2013 21:02:34 +0000
Resent-Message-Id: <E1UaXz0-0006mb-78@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 1UaXyp-0006jY-Bh for ietf-http-wg@listhub.w3.org; Thu, 09 May 2013 21:02:23 +0000
Received: from mail-qe0-f53.google.com ([209.85.128.53]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UaXyo-0004du-8x for ietf-http-wg@w3.org; Thu, 09 May 2013 21:02:23 +0000
Received: by mail-qe0-f53.google.com with SMTP id cz11so2085985qeb.26 for <ietf-http-wg@w3.org>; Thu, 09 May 2013 14:01:56 -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=zgNUfPucp9DM9ORy9X88MzqGTFDBXlREum0wLzlCMZc=; b=nkMMKzX8k8aX4smj/L/otmwBDgVzbV2MOGJA2XVQ2GK/YmbwpJYHY1LIRklJZ0khEe LWXRFoYlkRndW9IcWpeQDZME9V/RfTwtLV47n+KbVsHuepYmDx0eB1u10UzuyXBYG2ye Fa64QXzTnZ3xSYjnaeSOjB3PVPB4zDnlb/z7ITtuWPTc+SiSjIoiO+eKpLnaVPOJkRgG MEDqDfCP9PnnAiZb6/C7P/deP4zhuD07HhheUYXE4+chxHQ3S+5tDPSqf2YRLMIG8f2R xJMlG/chejF6WQmYgqSnhIxy91uO9GkI5f3if9/iKHYmGSWkavkABpMn0/pwGHq+4DpI vhJw==
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=zgNUfPucp9DM9ORy9X88MzqGTFDBXlREum0wLzlCMZc=; b=P5o+XGNMe50LaGKQIExHs2NL4Y7ihyVgrTj0yJtOf2y8fQiKbuTWfbpdXHmcnD9MqM RWegCN25EynLN7AApi+qLflMlWqMgvYrKh1KFcbEnH6XX74TvxE1o5Zh0w68HHcSzdno yftu+MuDQtxOpLQdh3Env+j1y3AzVFv0GBxxI=
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=zgNUfPucp9DM9ORy9X88MzqGTFDBXlREum0wLzlCMZc=; b=dj9e2GPtyfQz9xT8gjJ4kpWYzOeqWxtw+71rzPOPWsnhl9q+ANu+Vze0cUE8c7Iqnx aVCozthLnEizq40XB3TRHu5vqYHfGBUUESevy+sKGfBMH/GT1e4dE/whzRAfEZJU8o9z UlGQPknB5p1Zu35WJzzzRIj4x7M8nP8evzXAQZ69KqGG1nfv4G+xu59P7a/sqqPPtXhJ zfEtakXhycBg4FYky9TNWuTWWs2We03U5RxBO4MeJNTCrEkI8ldMi98Y7Tf/hWwYuCwO D9K0HcQd20WiwhlhDPQ7GZA+E0jffJr3Q4GoZYWV+FuXVnYGWtSFswqeVrC4wInDRqOF 9//w==
MIME-Version: 1.0
X-Received: by 10.224.65.1 with SMTP id g1mr9894106qai.64.1368133316471; Thu, 09 May 2013 14:01:56 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Thu, 9 May 2013 14:01:56 -0700 (PDT)
In-Reply-To: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com>
References: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com>
Date: Thu, 9 May 2013 18:01:56 -0300
X-Google-Sender-Auth: ta72ZfT8ig86wDKwOYBBPbB2kgQ
Message-ID: <CAA4WUYiwNSzvrY1LF_Sex_82TSDwMbTvYqo7LyKfBAOu0j4pfQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>, Hasan Khalil <hkhalil@google.com>
Content-Type: multipart/alternative; boundary=001a11c2d96e55a69604dc4f5c80
X-Gm-Message-State: ALoCoQlSorts4GbKanwlQJoC6RWiE0yMAyI9aGd0y7pvQDshF3EISsO1Kx1moTtojTqUPTR1/jnRY4vm9WzqavPhNcagYhkhru5Oo1G29ZYf2TeKErqcvN+MqpC4kUOsJMTV5wyuIg9yLTz7KEgo9naA6d+eaFF2zY1jPAC6K1eI+uqPL+Fz0gCNoFjXYS3xnqnADFNqcv0C
Received-SPF: pass client-ip=209.85.128.53; envelope-from=willchan@google.com; helo=mail-qe0-f53.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.119, 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=-1.159, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UaXyo-0004du-8x 9945b548d81910f5cc8db22ec603d356
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/CAA4WUYiwNSzvrY1LF_Sex_82TSDwMbTvYqo7LyKfBAOu0j4pfQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17912
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>

I discussed this with Roberto and Hasan. Here are some thoughts on
including header blocks within flow control:

* In the proposed text, it appears that only the compressed header block is
counting towards the window. Is that really what's desirable in order to
properly control memory? Processing the header block requires decompressing
it, and that's what will be kept in memory buffers until drained by the
sink.
* One problem with having headers count toward the per-stream flow control
window is that, in non-HTTP semantic layering, the header metadata could be
used as a control channel for the stream. Similar to how it would be
unfortunate to block connection control frames with the session flow
control window, it might also be unfortunate to block stream header/control
frames on the per-stream flow control window.
* As previously noted in other threads, it's unfortunate that stream
headers aren't counted toward any flow control windows, since that means we
may have to use the last-resort option to prevent further memory
consumption - stop calling read().


On Wed, May 8, 2013 at 9:12 PM, 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.
> ...
>
> - James
>
>
>
> On Wed, May 8, 2013 at 1:56 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
> > In message <
> CABP7Rbc8rs4-ktyGKwVxVC4MztcvYtARqBDoyEBYujfcpo4YDw@mail.gmail.com>
> > , James M Snell writes:
> >
> >>Going back through this, here's a counter proposal:
> >>
> >>Let's get rid of the 8192 frame size rule and simply say that the
> >>maximum size for all DATA, HEADERS, HEADERS+PRIORITY and PUSH_PROMISE
> >>frames is either 65,535 or the current flow control WINDOW_SIZE,
> >>whichever is less.
> >
> > Hmm, *now* you're talking...
> >
> > I like it.
> >
> > --
> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> > phk@FreeBSD.ORG         | TCP/IP since RFC 956
> > FreeBSD committer       | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by
> incompetence.
>