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

William Chan (陈智昌) <willchan@chromium.org> Fri, 10 May 2013 19:14 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 EFEDC21F9423 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 12:14:32 -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 mG6DRaOw6DEh for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 12:14:27 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA5521F93EC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 May 2013 12:14:27 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uasl7-0007rZ-7I for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2013 19:13:37 +0000
Resent-Date: Fri, 10 May 2013 19:13:37 +0000
Resent-Message-Id: <E1Uasl7-0007rZ-7I@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 1Uaskv-0007qX-Sv for ietf-http-wg@listhub.w3.org; Fri, 10 May 2013 19:13:25 +0000
Received: from mail-qc0-f172.google.com ([209.85.216.172]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1Uasku-0004iY-Hk for ietf-http-wg@w3.org; Fri, 10 May 2013 19:13:25 +0000
Received: by mail-qc0-f172.google.com with SMTP id z1so2453677qcx.31 for <ietf-http-wg@w3.org>; Fri, 10 May 2013 12:12:58 -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=Qs5VufoevEPjItQzRyO/ugM7KGq0AiEe9O8nq6qnnb0=; b=R8SsTWuuJQJFPKZOshrTPoUX0OYMn6xTVctO83cbtZEkjV7HQAPqstvSHR2ZOcMAK5 nisu6puJlKqqV9DzluhvyX8UgS6T86tf+x5rl3ajWaqGDvmY/TWB37+HSQHw9uMJeUDh iJVhWRbK0oXCqES7o8J0G7nKb9DniBrXpHHqYrXOj7nxaE2Sus/EIfZkNG6J2SQ5wirS rH9cDJOiGXlwURbhhftAMD6uwVAg+Tv2qbOvvhNPc8OCiqcOOvjLFC3pV+BjtFw4FN2+ LZPIpnX0O4UjPUy/gMchYL93gin0p+S2yQ14ckYuvJfLxBdkxOzPHBJ5nYeLmTFEY4UR bDCw==
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=Qs5VufoevEPjItQzRyO/ugM7KGq0AiEe9O8nq6qnnb0=; b=Y05Prof+3bUnML7mkq7Hjz4S+8tIKrMqHHCEz+/ieOxMt/YJVl6PPiS9q3JZTz6vna 6oZ7DTUhnfQfm8U9O3xQ/qMk8otn/DABTaru+IrR4BCjO2W9zfbFurF6Jl+anemzLtMX zO1kE3VKLcXOhV8dDvWidS2n40lDkaB+GN6Pw=
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=Qs5VufoevEPjItQzRyO/ugM7KGq0AiEe9O8nq6qnnb0=; b=WxYCGg+Y6IR+v3aoOp0ZMkrwV7ytYAU2/jGOHpyZolgGxTxxyKNIDBQaUDLPMuM62H Xv0v1eeCTzVudmsAr3TqEM3dd/Wu9DMJKiLMnrHONTb1x26erIg7DHavrwlnS/1yca3s INwduelbdo6RehZ8fCZw0ys4fxph4jxcQCTR+R8W6E5B9Q5kgH7epHkmzA7NJuuADPUA AMMrJzuf+A+rHh7RbHpP4Wih8qQgnycnZklQrP5zQsj/3kS4BGhiZa9pyjorYhzLE75U yrLo18DqMQ6PYXihOZ4I0T1l5xPBMMl8XWe/rzm/2PON26gA3zX5cSzxKMq7OG2GPJXR eO8w==
MIME-Version: 1.0
X-Received: by 10.229.155.3 with SMTP id q3mr4541877qcw.71.1368212729578; Fri, 10 May 2013 12:05:29 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Fri, 10 May 2013 12:05:29 -0700 (PDT)
In-Reply-To: <CABP7RbcF3VXuhvP5StN9hHVj4K-2WMvBr37ur3iHmH-=2WAbHw@mail.gmail.com>
References: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com> <CAA4WUYiwNSzvrY1LF_Sex_82TSDwMbTvYqo7LyKfBAOu0j4pfQ@mail.gmail.com> <CABP7RbdqnH0JK-UaMiaR5rLvZo8txywEcXXSUXa_y95hrLC5yA@mail.gmail.com> <CABP7Rbd-VfTFYurZ-JEKjHKOeKvZCKoYLGMXf+0mi-_wbdKYqA@mail.gmail.com> <CAA4WUYgfu=rcji-bdxNPsE9KCE4T67+vN9b0iojnvycx5R-StA@mail.gmail.com> <CABkgnnX=AemYGrBzWGX1VEUgKKrk+hR6YV0jg9qVMSdPiimBAA@mail.gmail.com> <CAFA1p16FHaSf7b1=mhe_Cb=ZqV1m0HVwkQNdW+pkJ0OkA9L-5A@mail.gmail.com> <CAP+FsNdifoF3aqQLB-EZjYqL3O2_uNEmNJ_+zAktu9zapKmT7w@mail.gmail.com> <CABP7RbcF3VXuhvP5StN9hHVj4K-2WMvBr37ur3iHmH-=2WAbHw@mail.gmail.com>
Date: Fri, 10 May 2013 16:05:29 -0300
X-Google-Sender-Auth: ZMseRTz7zxfNa2KG6bTAydb7Cvs
Message-ID: <CAA4WUYgFccqU5-65mFPF_3i4OOROZQCdS+tEUeDMk4HP4JJX5Q@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, Hasan Khalil <hkhalil@google.com>, 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=f46d04478b0fb991d204dc61d9e0
X-Gm-Message-State: ALoCoQkzSZtxcb7QFpgSHTOYG4mXMOQYLWDgBfuJ2KZgXj8d0wGzI7Pzxgy8gpombGcE2hlRRFYoi6kMqNRxSLGcPrQ0LA7UQJutmKw+f2PhTDS/3IVxupX5bhuOL9MiM/Cer7+7jT33sp0MQK4wgC/GuLE1dc0kxW7BTIq/om3USPJLEn39HHBpUp1L5EGdnWYmbQDPblMq
Received-SPF: pass client-ip=209.85.216.172; envelope-from=willchan@google.com; helo=mail-qc0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.073, 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.315, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1Uasku-0004iY-Hk b1d6a5363f8b5d177005e30dacf146dc
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/CAA4WUYgFccqU5-65mFPF_3i4OOROZQCdS+tEUeDMk4HP4JJX5Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17926
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>

On Fri, May 10, 2013 at 3:23 PM, James M Snell <jasnell@gmail.com> wrote:

> On Fri, May 10, 2013 at 11:11 AM, Roberto Peon <grmocg@gmail.com> wrote:
> > The continuation bit is necessary for headers at a minimum, as we do have
> > headers which are > 65k, and something indicating either
> > end-of-semantic-header-block is necessary to support that.
> >
> >
> > I don't understand why it makes sense to limit header frames by the
> window
> > size.
> > what if the window size is zero?
> > What if it is 1 byte.
> >
>
> If the window size is unreasonably low, then communication would not
> be possible. Simple as that.
>
> Or, we can go ahead and set a lower-bound also.. say frame size is <=
> min(WINDOW_SIZE,65k) && > 1k .. the low bound is fairly arbitrary and
> we can set that at whatever is reasonable.
>
> The rationale for tying this to window size is to limit the number of
> knobs that have to be turned to control the communication flow. window
> size is already established as the amount of data the receiver is
> willing to accept at any given time, it's reasonable to consider that
> significant thought will have gone into establishing that window size
> and that it will be tuned to achieve maximum network utilization.
>

I don't really understand the point of this halfway stance of not counting
towards the window, yet having the frame size be bounded by the window.
DATA frames count towards the window, and their frame sizes are bounded by
the window as well (otherwise it'd be a PROTOCOL_ERROR). All the control
frames don't count towards any flow control window, and don't have their
frame sizes bounded by any window either.

I kinda get the impression from reading this email of yours that you think
window sizes are fairly static, and while it's true that the target window
size may be somewhat static (target the size to match the buffers), in
practice window sizes as viewed by the sender shrink and grow (every time
you send bytes, you use up more of the window(s) and hence it shrinks, and
requires a WINDOW_UPDATE to grow it(them)). If the sender sends data faster
than the receiver can process, I believe that the connection window will be
0 (from the sender's perspective, although a WINDOW_UPDATE may be incoming
to increase the window), which will block the sender from sending any
header frames.


>
> - James
>
> > I don't see any real benefits for limiting control frames to anything
> having
> > to do with the window size as compared to sending a SETTING and having
> the
> > default before there and having it completely decoupled from window size,
> > and I do see a number of complications and ewws :/
> > -=R
> >
> >
> > On Fri, May 10, 2013 at 10:58 AM, Hasan Khalil <hkhalil@google.com>
> wrote:
> >>
> >> While I love the idea of limiting frames to 65535B, I hate the idea of a
> >> continuation bit.
> >>
> >>     -Hasan
> >>
> >>
> >> On Fri, May 10, 2013 at 1:54 PM, Martin Thomson <
> martin.thomson@gmail.com>
> >> wrote:
> >>>
> >>> On 10 May 2013 10:40, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
> >>> > [...] are we going to move forward with the frame
> >>> > continuation bit?
> >>>
> >>> I think that this was implicit in our decision to limit frames to
> >>> 65535 bytes (or less).
> >>
> >>
> >
>