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

William Chan (陈智昌) <willchan@chromium.org> Fri, 10 May 2013 20:01 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 AF1CE21F85ED for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 13:01:11 -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 duet8LIsp7wC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 May 2013 13:01:06 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id A3DF421F881F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 May 2013 13:01:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UatUh-0004BE-Q6 for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2013 20:00:43 +0000
Resent-Date: Fri, 10 May 2013 20:00:43 +0000
Resent-Message-Id: <E1UatUh-0004BE-Q6@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 1UatUW-00043O-EA for ietf-http-wg@listhub.w3.org; Fri, 10 May 2013 20:00:32 +0000
Received: from mail-qe0-f51.google.com ([209.85.128.51]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UatUV-00079S-8k for ietf-http-wg@w3.org; Fri, 10 May 2013 20:00:32 +0000
Received: by mail-qe0-f51.google.com with SMTP id x7so2679143qeu.38 for <ietf-http-wg@w3.org>; Fri, 10 May 2013 13:00:05 -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=ZyESCYxuH4K8ce4vkIXV+K7sWl7eou2Hr+Oc7dBKf0U=; b=cOQLbyqFMgIWjsDXjwsK4eznAfI8jW9gWlIuAbLPYejbftT0k7/gEiWdxX+pEkLRaZ JqE1mkVZZ+I/yDsLREwA05pg+NY8Xi+Tp0koOrvds2Wn+ZywNdkMw2nTUJ3ccFg75EGb 3I63YIcE6hh0F4HAO4QRkBW39A0r1/uCbEt7z1TSJCrqTlzBDp+0pHFuy32xJGRJc8/F 2k5HVjWN8T7ypPvJ45Rz79sggzKl9aGF8FvlO9BhYt5HEy9ex+g0thD+dV48wCfRHfak rMTCVZEAI+vx0glVlHAIqVk+C0Q1wZKdRcKJbluveJivPu28kc5nLCoB+1g5ymGmlqum 9Tvw==
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=ZyESCYxuH4K8ce4vkIXV+K7sWl7eou2Hr+Oc7dBKf0U=; b=QzONz+TUL+lSufJZ68rt1GhPGFbj8uT+L7SWuchvrQUuLC9t2oVOBmjT+Qr7D8S4jc 2L6xUdURLsQkBCyTS4hyvafMNQwLpDX3V0jZqN0NjG4XrUPKebe6Zmflf0JsCXRdCWUe x+eKOn+Ei9ARis4nwVtucVJuDO5Lk09O7pCmo=
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=ZyESCYxuH4K8ce4vkIXV+K7sWl7eou2Hr+Oc7dBKf0U=; b=PCERy6LASvf2QJVBD0EtmbwxHr+NyRY8YhFf0jnex/+gG/vLJutTI+F4UiVfrlC79E 4BopWobBlA9U33DAAuqXPcmTTG/r2tQ4reSVoMdEkcNOu02yHTDHjkl97bDXbSBo49UW 4DzghSYr3fvCC0joErBca3ypWVHbawII/5ARtotU8u9Y7nMv/mpiSE3+UNN4Fog/zqNb ZPddZ20BBhSX4Rf/7744xti+BlOtHrDxmNNgAnVMB5vXlnmKlms8RS/UxxgyL6HDmK96 aKqwGtK0U6isvjPX8crabdoCiO1mieVD3eW8q3nM4+pO5gGEwBhJRMuTL9XrXTmV7x/q /AJQ==
MIME-Version: 1.0
X-Received: by 10.224.57.82 with SMTP id b18mr13113449qah.36.1368216005508; Fri, 10 May 2013 13:00:05 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Fri, 10 May 2013 13:00:05 -0700 (PDT)
In-Reply-To: <CABP7RbcQMEhu9ciuTQoR1dRw3UiUB=E_AeMjaNrhFgMPmmi+EQ@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> <CAA4WUYgFccqU5-65mFPF_3i4OOROZQCdS+tEUeDMk4HP4JJX5Q@mail.gmail.com> <CABP7RbcQMEhu9ciuTQoR1dRw3UiUB=E_AeMjaNrhFgMPmmi+EQ@mail.gmail.com>
Date: Fri, 10 May 2013 17:00:05 -0300
X-Google-Sender-Auth: dnCVi_wRVihV43Z0-PqaKaEmre4
Message-ID: <CAA4WUYjFgJ28O5Jb58a5eodJMWe+CSe18Ow1wpETWJcjmedXRQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>, Hasan Khalil <hkhalil@google.com>
Content-Type: multipart/alternative; boundary=089e01538d54fc362004dc629c48
X-Gm-Message-State: ALoCoQnxSqGvDHEMDU3Csy2btMku+WBEADSyQn8dKelphxUlbNRoO10cOpy5Kn4WlWGeCDuEp3PM6JCXczeu7zNimjBC/cDtgeWaqc4yPrsDxnhF9H+56mgimX/m8tj3rGPLpWesreOrv4fUncF8u1s0YWX0O4lb93PtoI9hwNwFZRYFQqSQGmCo/xsPkYrT9QykPmmTFyVh
Received-SPF: pass client-ip=209.85.128.51; envelope-from=willchan@google.com; helo=mail-qe0-f51.google.com
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: AWL=-2.044, 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 1UatUV-00079S-8k 5d06069bf5fde3db963a4f8958e5bdd1
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/CAA4WUYjFgJ28O5Jb58a5eodJMWe+CSe18Ow1wpETWJcjmedXRQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17935
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 4:50 PM, James M Snell <jasnell@gmail.com> wrote:

>
> On May 10, 2013 12:05 PM, "William Chan (陈智昌)" <willchan@chromium.org>
> wrote:
> >
> > 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.
> >
>
> Other control frames don't contain arbitrarily large sets of user or
> application provided data like header bearing frames do.
>
> > 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.
> >
>
> I do not presume the Window to be static at all.  In fact, quite the
> opposite,  I expect it to be quite variable.  I do not want header frames
> that are beyond an endpoints ability to process at any given point in
> time.  It's conceivable that if the widow size is 0, the receiver really
> doesn't want the sender to initiate any new requests or to send arbitrarily
> large blocks of headers.
>
I don't get it. Then what does a halfway stance buy you? If you really want
to prevent them from sending data, say that headers are included in flow
control. If you're only shrinking the max frame size, but we can use a
frame continuation bit, or there's a lower-bound on the frame-size, then
the receiver isn't able to prevent the sender from sending arbitrary
amounts of header data, but it's just forcing the sender to break it up
into smaller frame sizes.

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