Re: proposed WINDOW_UPDATE text for session flow control windows
Roberto Peon <grmocg@gmail.com> Wed, 20 February 2013 21:51 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 B6D8721E803F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 13:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.536
X-Spam-Level:
X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bxt7MT5eeDyq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 13:51:10 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B070C21E803A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 Feb 2013 13:50:43 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U8HXx-0001un-SV for ietf-http-wg-dist@listhub.w3.org; Wed, 20 Feb 2013 21:49:49 +0000
Resent-Date: Wed, 20 Feb 2013 21:49:49 +0000
Resent-Message-Id: <E1U8HXx-0001un-SV@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U8HXo-0001u3-Ir for ietf-http-wg@listhub.w3.org; Wed, 20 Feb 2013 21:49:40 +0000
Received: from mail-oa0-f46.google.com ([209.85.219.46]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U8HXd-0005HU-Et for ietf-http-wg@w3.org; Wed, 20 Feb 2013 21:49:40 +0000
Received: by mail-oa0-f46.google.com with SMTP id k1so8600897oag.33 for <ietf-http-wg@w3.org>; Wed, 20 Feb 2013 13:49:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wpvSitAYWn+bBGgx2PYrkXjcU//SajgJfYMKwGyp8zA=; b=wLuGMmgb259MbxF+HUvFm324MY+d/2eQ8FvSXQcm176SuYX8NuBOry4mSVWp1j/iPk MSfZTkjMNFPwh494DGytp1d8tgrtGtjzm/VTceYzO4LU9B9+FCsCP6d2G8tVD4YZFbvA ZgOEiSO9ZbAkRtr2EEqcpZ1ZwrXXMlgdvIYOvQCpUGBYhYZYv84vqW9ApepeOkWJR4jT /T/uhQvGFFjFwAGD/UQVDfHVGYF1+lS5THFOcUsWOEpXtJLtu3uGX8sh2IHvl/AHmP3h DjVNROqIoTGQzdEXHyCzpfiqkl0+kGTFbV8xUah8lgb+qhCTYNFXWQ0zpgVsW2iHORNc YqHA==
MIME-Version: 1.0
X-Received: by 10.182.183.2 with SMTP id ei2mr9702887obc.84.1361396943322; Wed, 20 Feb 2013 13:49:03 -0800 (PST)
Received: by 10.76.167.193 with HTTP; Wed, 20 Feb 2013 13:49:03 -0800 (PST)
In-Reply-To: <CABkgnnUH5_t4BesWz2K5gtR0k0+ve42k-EWEaObK_nteh9fOUw@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>
Date: Wed, 20 Feb 2013 13:49:03 -0800
Message-ID: <CAP+FsNcZrQ072mQikMSnyFrKqN0yDYhh=-8G4848YxdO_M-_zw@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="f46d04479f2934803104d62eed19"
Received-SPF: pass client-ip=209.85.219.46; envelope-from=grmocg@gmail.com; helo=mail-oa0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.682, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U8HXd-0005HU-Et 94c87fecac3fb5b10bd65aafc069dc56
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/CAP+FsNcZrQ072mQikMSnyFrKqN0yDYhh=-8G4848YxdO_M-_zw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16695
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>
By flags, do you mean SETTINGS thingies, or do you mean values in the flags byte (I'm assuming SETTINGS thingies?) -=R On Wed, Feb 20, 2013 at 1:43 PM, Martin Thomson <martin.thomson@gmail.com>wrote: > I believe that many people will want to turn it off and keep it off. > Besides, if you send multiple huge WINDOW_UPDATE frames, your peer > (who is tracking the window size) will be forced to send you a > RST_STREAM when their window goes off the scale. > > Another alternative: > Send a WINDOW_UPDATE with a value of zero. This could temporarily > disable flow control on the referenced stream (or the session for > stream ID 0). Similarly, sending a SETTINGS_INITIAL_WINDOW_SIZE value > of zero would disable flow control for all new streams. > > The current doc implicitly permits a value of zero on WINDOW_UPDATE, > with zero net effect. A zero on SETTINGS_INITIAL_WINDOW_SIZE would be > bad, and thus might be considered "reserved" in a special kind of way. > > More flags is always an option, but that seems like it is a heavier, > blunter instrument than this. > > On 20 February 2013 12:10, William Chan (陈智昌) <willchan@chromium.org> > wrote: > > Do we need a protocol mechanism for this? What's wrong with advertising a > > huge window and sending huge WINDOW_UPDATE frames as needed? Is the goal > to > > allow implementations to actually not implement receiver flow control at > > all, and just disable it? Considering implementations always need to > support > > the peer's receive window advertisements, I view the extra implementation > > difficulty of supporting receive windows correctly as pretty marginal. > That > > said, I do guess it's possible for implementations to set it to extremely > > high, and in their testing never hit those window limits, and have > > everything hang because they never sent out more WINDOW_UPDATEs. I do > admit > > that'd be bad. > > > > I guess I don't feel too strongly. Just wanted to make sure there was an > > agreement that we needed an extra protocol mechanism rather than just > > advertising huge windows and updating as needed. > > > > > > On Wed, Feb 20, 2013 at 12:02 PM, Roberto Peon <grmocg@gmail.com> wrote: > >> > >> Two proposals: > >> > >> 1) Assuming we need/want this on a per-stream basis: > >> Use a flag value (lets say 0x2) with the delta-window-size field set to > >> all bits on (i.e. 0xFFFFFF). > >> all-bits-on is currently illegal (the top bit is reserved so that we > might > >> use negative window updates in the future, should we decide to do > that), so > >> this should be quite difficult to screw up. > >> > >> Setting this on stream '0' would disable the session-level flow control. > >> > >> 2) Change SETTINGS so that it also includes the flag byte. This would be > >> accomplished by adding a new settings ID (10). The LSB of that settings > >> value would be interpreted as the flag-byte, as if received as in > scheme 1. > >> Thus, a settings with id:7, value 0xFFFFFFFF and with id:10 > value:0x00000002 > >> would disable flow control > >> > >> > >> > >> > >> On Wed, Feb 20, 2013 at 9:16 AM, Martin Thomson < > martin.thomson@gmail.com> > >> wrote: > >>> > >>> I need to know how to advertise an infinite window so that receivers > >>> are able to turn flow control off. Does anyone want to propose > >>> something? > >>> > >>> On 19 February 2013 14:54, William Chan (陈智昌) <willchan@chromium.org> > >>> wrote: > >>> > I've sent out the first pull request for > >>> > SETTINGS_MAX_NUM_CONCURRENT_STREAMS. After that goes in, I'll rebase > >>> > and > >>> > re-run the HTML generator for the flow control change, and send a > pull > >>> > request for that. > >>> > > >>> > On Tue, Feb 19, 2013 at 2:48 PM, Mark Nottingham <mnot@mnot.net> > wrote: > >>> >> > >>> >> William, can you send a pull request for your changes? > >>> >> > >>> >> Patrick, if you want to open an issue to remind us to revisit > negative > >>> >> window updates, please feel free. > >>> >> > >>> >> Cheers, > >>> >> > >>> >> > >>> >> On 16/02/2013, at 11:10 AM, William Chan (陈智昌) < > willchan@chromium.org> > >>> >> wrote: > >>> >> > >>> >> > Thanks for the thoughts here. I will need to investigate on our > end > >>> >> > how > >>> >> > much RAM we see get consumed here and if this would bring > practical > >>> >> > wins. If > >>> >> > you feel strongly or anyone else supports this, let's add protocol > >>> >> > support. > >>> >> > Otherwise, out of inclination for fewer features and also a mild > >>> >> > fondness > >>> >> > for being able to be stricter in the protocol (enforcing > >>> >> > WINDOW_UPDATE > >>> >> > compliance). I don't feel strongly and I'm happy to revisit later > >>> >> > on. This > >>> >> > part is easy to change if desired. > >>> >> > > >>> >> > > >>> >> > On Tue, Feb 12, 2013 at 6:54 AM, Patrick McManus > >>> >> > <mcmanus@ducksong.com> > >>> >> > wrote: > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Sun, Feb 10, 2013 at 2:14 PM, William Chan (陈智昌) > >>> >> > <willchan@chromium.org> wrote: > >>> >> > Do servers often have a need to immediately revoke buffer size > >>> >> > promises? > >>> >> > In absence of negative window updates, I would think servers would > >>> >> > just stop > >>> >> > sending WINDOW_UPDATEs. Is that mechanism insufficient? > >>> >> > > >>> >> > > >>> >> > s/servers/receivers > >>> >> > > >>> >> > In this case I was thinking about firefox. In general we don't > have > >>> >> > a > >>> >> > ram budget for transactions in the way a server does, so the > >>> >> > reasonable > >>> >> > thing to do in the general case is to set flow control to a very > >>> >> > high value > >>> >> > to ensure it isn't a choke point, right? However, RAM does have a > >>> >> > way of > >>> >> > suddenly appearing to be low and we get notifications of that. > Lots > >>> >> > of times > >>> >> > this is due to other unrelated system activity - this is > especially > >>> >> > true on > >>> >> > mobile. Currently we do a handful of things in reaction to that > >>> >> > (dumping > >>> >> > decoded image caches for example). Another reasonable reaction to > >>> >> > that is to > >>> >> > squelch some active streams and shrink their associated buffers.. > >>> >> > this is > >>> >> > the context I was thinking about. > >>> >> > > >>> >> > waiting for a very large window to drain via lack-of-updates could > >>> >> > take > >>> >> > an extremely long time. > >>> >> > > >>> >> > > >>> >> > All in all, I don't feel very strongly on this. I'd rather hear > from > >>> >> > more proxy/server vendors that they want this, rather than adding > it > >>> >> > in just > >>> >> > because it might be useful. Or are you suggesting that Firefox > would > >>> >> > like to > >>> >> > use this? > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > >>> >> -- > >>> >> Mark Nottingham http://www.mnot.net/ > >>> >> > >>> >> > >>> >> > >>> > > >>> > >> > > >
- proposed WINDOW_UPDATE text for session flow cont… William Chan (陈智昌)
- Re: proposed WINDOW_UPDATE text for session flow … Patrick McManus
- Re: proposed WINDOW_UPDATE text for session flow … William Chan (陈智昌)
- RE: proposed WINDOW_UPDATE text for session flow … RUELLAN Herve
- RE: proposed WINDOW_UPDATE text for session flow … Roberto Peon
- Re: proposed WINDOW_UPDATE text for session flow … Patrick McManus
- Re: proposed WINDOW_UPDATE text for session flow … William Chan (陈智昌)
- Re: proposed WINDOW_UPDATE text for session flow … William Chan (陈智昌)
- Re: proposed WINDOW_UPDATE text for session flow … Mark Nottingham
- Re: proposed WINDOW_UPDATE text for session flow … William Chan (陈智昌)
- Re: proposed WINDOW_UPDATE text for session flow … Martin Thomson
- Re: proposed WINDOW_UPDATE text for session flow … Roberto Peon
- Re: proposed WINDOW_UPDATE text for session flow … William Chan (陈智昌)
- Re: proposed WINDOW_UPDATE text for session flow … Martin Thomson
- Re: proposed WINDOW_UPDATE text for session flow … Roberto Peon
- Re: proposed WINDOW_UPDATE text for session flow … Martin Thomson
- Re: proposed WINDOW_UPDATE text for session flow … Roberto Peon
- Re: proposed WINDOW_UPDATE text for session flow … Martin Thomson
- Re: proposed WINDOW_UPDATE text for session flow … Mark Nottingham
- Re: proposed WINDOW_UPDATE text for session flow … Martin Thomson
- Re: proposed WINDOW_UPDATE text for session flow … Roberto Peon
- Re: proposed WINDOW_UPDATE text for session flow … William Chan (陈智昌)
- Re: proposed WINDOW_UPDATE text for session flow … Martin Thomson