Re: proposed WINDOW_UPDATE text for session flow control windows

William Chan (陈智昌) <willchan@chromium.org> Thu, 28 February 2013 05:03 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 A598221F8B38 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 27 Feb 2013 21:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.47
X-Spam-Level:
X-Spam-Status: No, score=-9.47 tagged_above=-999 required=5 tests=[AWL=0.206, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AInyERDzhfvo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 27 Feb 2013 21:03:05 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1021221F8B36 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 27 Feb 2013 21:03:03 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UAvcn-0004QZ-O7 for ietf-http-wg-dist@listhub.w3.org; Thu, 28 Feb 2013 05:01:45 +0000
Resent-Date: Thu, 28 Feb 2013 05:01:45 +0000
Resent-Message-Id: <E1UAvcn-0004QZ-O7@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 1UAvcc-0004Pj-W4 for ietf-http-wg@listhub.w3.org; Thu, 28 Feb 2013 05:01:35 +0000
Received: from mail-oa0-f52.google.com ([209.85.219.52]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UAvcb-0008Hx-Sj for ietf-http-wg@w3.org; Thu, 28 Feb 2013 05:01:34 +0000
Received: by mail-oa0-f52.google.com with SMTP id k14so2781364oag.25 for <ietf-http-wg@w3.org>; Wed, 27 Feb 2013 21:01:07 -0800 (PST)
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=4NpmkrfW3Akq7v5edwzoH6bzDGUIOkosZfiMa9IFMCc=; b=Aqg6QBIg/6LQSJ0SSQS+zvZ+B/1Um7xl61T+KUmVqe9Msg4qfyZf8kBM0BCuJxUnr1 +Xz96O/3oJXD2PNfMYSVS71MsssG7l3VzhZcnsmqECpWK2tmF+2bZIjEuS/dPxOL2use 8AVw+4q2seLmTOSzM83g5MfdSQnKNf3THY/XcCBhFz5ZBbB7zD5DeC9z7moDKLbTAcEK fteTFZAbh9kcdrXMrxhdiX1zqXREEZWRKx/LX5gkQhZ7bYJZRM8kL0hh5kT6JHw/evAU Ti0FUPS3IfxbASowWbzVkKrzvDvkoRz+GnpgB60ZQvbE6QJ48V/iJddkFaEyfAZwPT0L SEmg==
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=4NpmkrfW3Akq7v5edwzoH6bzDGUIOkosZfiMa9IFMCc=; b=kJENry41a5pDkiR0VNTjryCwKndvzGedTGYy0LQBuBjaM89Lnt7pxeBC0ZPBPULy99 gxHt79rkHa2D9IOugiGkMLd9VYBRrvLrVC6euYOJkvhVutTzcl617NMgBDKS1uIx+6FR L2Xp5foqI0B0Fs4YkTiuxpy9IS3kExkTLhx9Y=
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=4NpmkrfW3Akq7v5edwzoH6bzDGUIOkosZfiMa9IFMCc=; b=cDqNSr+siR3niJVjBIIx3eewSczHnF3qkxnRMA50JmtKUz6NHXwb5y9sEAoKUhpNza Qu9iCsQfDF7qBv2lqct8JY68JpS22opaOxg5EuTnaUtO1XlzeVON6UVNpUyfB94hCW7d c2Kz1vp5soAB3AGPvT4JpLYR4OWXMPX9YxHCus0/SxaqMEMD/svqzK9GKz15mbD8bJpY MUi4uyCi2iQm4QOjM7sGAlQKAId5zI5P3UheGMbU0XHX1PWGf2G9u9WznIaHtQSb7ZHj 429/cIh3JR+8ULZRTGlRh1nUm9R9MemPDidv3AdxDp3ppiQ0pmDhGG3K2rnrnnfs9hcT qNcQ==
MIME-Version: 1.0
X-Received: by 10.182.180.113 with SMTP id dn17mr4693838obc.5.1362027667632; Wed, 27 Feb 2013 21:01:07 -0800 (PST)
Sender: willchan@google.com
Received: by 10.182.186.6 with HTTP; Wed, 27 Feb 2013 21:01:07 -0800 (PST)
In-Reply-To: <CAP+FsNc5WKbRRDXQ4-GLXXNaxp1njuKFvVHAO8ffa6VDhvBqRQ@mail.gmail.com>
References: <CAA4WUYiH8tCF83=jsk_jsvhXkYvmJ+pPLFzhacAMq3O54z2YBw@mail.gmail.com> <CAOdDvNqCe3d7QerQaxiwdwJ+wC+4CGA4ZrLRYFY75nR2QFThog@mail.gmail.com> <CAA4WUYg2gn7Um1FZk3KBcP5aH=RpSCbYduFz3M+hZGQ_A4tsxQ@mail.gmail.com> <CAOdDvNqTNa=R1MzZe1mKZF34tW-=mhHnM_s_XPVzBBSEWHveVQ@mail.gmail.com> <CAA4WUYiW6xsT8g--1cL7HZTVYS_+5Y-WKpzfbx2JCLRqHXNgcQ@mail.gmail.com> <2595AFA8-9928-4511-B569-3DFC36B73C5C@mnot.net> <CAA4WUYg8ksyjKYmeX6YC3P1-iaRRSD_e5KDhpPw0d9i2CnvpSQ@mail.gmail.com> <CABkgnnU4=OYYZEkS7sfxWjXum+Mpx7RzUdJSzYa9a+UybESQYw@mail.gmail.com> <CAP+FsNcDxJeU=7+x8Jx5TO0hm_P2yCKPu7_tEZF0GEtjMbQ2Xg@mail.gmail.com> <CAA4WUYh1qU6HPbeZTsFTy7i5svxWS2dATgUNyaoGnzbMLkCELg@mail.gmail.com> <CABkgnnUH5_t4BesWz2K5gtR0k0+ve42k-EWEaObK_nteh9fOUw@mail.gmail.com> <CAP+FsNcZrQ072mQikMSnyFrKqN0yDYhh=-8G4848YxdO_M-_zw@mail.gmail.com> <CABkgnnU8Okqrq5POYZqDyFUoFzkQwjRAvQJQQ_jhCO9heaFYNA@mail.gmail.com> <CAP+FsNd5bCpcVg7Z9Q=D1goYZ2keGnxPmy2G79O+h5K6bSa=cA@mail.gmail.com> <CABkgnnWgNHHHuCSXNpDQSVbaBTp=ZYnPH+MX9-_CXvaj4VD83w@mail.gmail.com> <A89944B3-8BB6-4B09-AF80-4F2C683A14EF@mnot.net> <CABkgnnVm30edw=ZQbyq9zUbLqQfWMi_YS9Y4n5MjNQTeM5GESg@mail.gmail.com> <CAP+FsNc5WKbRRDXQ4-GLXXNaxp1njuKFvVHAO8ffa6VDhvBqRQ@mail.gmail.com>
Date: Wed, 27 Feb 2013 21:01:07 -0800
X-Google-Sender-Auth: 50g6fbUi7hk-FBCRQwxJrmz54YA
Message-ID: <CAA4WUYhAQ_SLZvtumiuDV9rW7-FmJfY4PeQky1LZ6HpF7BpHUQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=f46d041827344e406c04d6c1c707
X-Gm-Message-State: ALoCoQnQ/R92/EQROm0DCSD28uvxL42JB+fz5lezamIvzczgQh+WrgLOHrp8U42Ug4GGcD+sPKk3FrJMLkt7lwtbkdmSKNRYX1ehi8fIBcv4sI9bJhtDBaPo4wtW53K88m46g3UDo/Qt/tA9RIokzdd8NnKKFQQpVliEHo4bhwVQ7hcJbc+ofWsl4u4BUHL/ZHmOhGJzGKnq
Received-SPF: pass client-ip=209.85.219.52; envelope-from=willchan@google.com; helo=mail-oa0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.290, 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.703, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UAvcb-0008Hx-Sj e34f474d4b03ad103749bf3db9f9f7da
X-Original-To: ietf-http-wg@w3.org
Subject: Re: proposed WINDOW_UPDATE text for session flow control windows
Archived-At: <http://www.w3.org/mid/CAA4WUYhAQ_SLZvtumiuDV9rW7-FmJfY4PeQky1LZ6HpF7BpHUQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16924
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>

* Is there a reason to disable stream flow control, but not session flow
control? Feels weird to me.
* I see more reason to allow stream flow control without session flow
control, but I feel like if people truly wanted simplicity, why don't they
just disable flow control entirely? Do we really need the granularity here
of stream vs session?

I know there are people who want to disable flow control entirely. Are
there people who only want to disable stream or session flow control? If
someone truly wants this, then sure. Otherwise, I'd err on the side of
fewer changes and keeping the spec simpler for now.

Nit: I don't want to bikeshed too much, but my preference is to call the
shed DISABLE_FLOW_CONTROL instead of END_FLOW_CONTROL. But whatever.


On Wed, Feb 27, 2013 at 8:41 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Seems reasonable to me at least.
> -=R
>
>
> On Wed, Feb 27, 2013 at 5:28 PM, Martin Thomson <martin.thomson@gmail.com>wrote;wrote:
>
>> Just started out on this, taking Roberto's suggestion of having a
>> setting and a WINDOW_UPDATE flag.  A few minor points came up.
>>
>> Disabling flow control for the session potentially has two different
>> mechanisms: settings and window update.  Is this OK, or would people
>> prefer to only have the WINDOW_UPDATE?  I think that for simple
>> implementations, the settings will be a more attractive prospect.
>>
>> I've said that using SETTINGS to disable flow control has an effect on
>> both new *and existing* streams.  Again, this makes an attractive
>> option for implementations that don't want flow control.
>>
>> Re-enabling flow control is an error.  Basically, we have no mechanism
>> to unambiguously identify when flow control starts.  I don't believe
>> that it is worthwhile to provide such a mechanism.
>>
>> See
>> https://github.com/http2/http2-spec/commit/d8013a3e1659696debc8773e9467b8ad829c49ee
>>
>> On 25 February 2013 17:00, Mark Nottingham <mnot@mnot.net> wrote:
>> > Opening as:
>> >   https://github.com/http2/http2-spec/issues/44
>> > ... and marking as ready for the editors to have a kick at it.
>> >
>> > Regards,
>> >
>> >
>> > On 21/02/2013, at 10:00 AM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>> >
>> >> On 20 February 2013 14:52, Roberto Peon <grmocg@gmail.com> wrote:
>> >>> I'm afraid of simply sending a large window size, because I suspect
>> that
>> >>> simple implementations will mess it up for objects > 31 bits in size.
>> >>
>> >> Yes. Absolutely.
>> >>
>> >>> If we don't have a SETTINGS thing, then we're requiring flow control
>> for the
>> >>> first RT for any stream.
>> >>
>> >> Yes, that's the implication.  Though a client is always able to
>> >> disable flow control without consequence, because it speaks first,
>> >> before the server sends anything.  It's only servers that need to
>> >> worry about having it on briefly.  The consequences are minimal - they
>> >> just don't receive as many packets as they possibly could - but then
>> >> that is always true for two reasons: TCP INIT CWD and the time it
>> >> takes to send the WINDOW_UPDATE.
>> >>
>> >>> I like the flag solely because it is difficult to do by accident,
>> unlike
>> >>> using zero (which is technically fine otherwise)
>> >>
>> >> I don't believe in accidents, but I see your point.
>> >>
>> >>> The other thing to consider is when, if ever, one can transition from
>> >>> flow-control disabled to requiring its use again.
>> >>> Even if we don't allow this, it will require text explaining it.
>> >>
>> >> I thought about this.  The obvious choice is to start again from zero
>> >> when a WINDOW_UPDATE comes in.  The problem is knowing (at the
>> >> receiver end) when counting started.  Once you stop counting, that's
>> >> the real difficulty.  I believe that once it's off, flow control will
>> >> need to stay off.
>> >
>> > --
>> > Mark Nottingham   http://www.mnot.net/
>> >
>> >
>> >
>>
>
>