Re: proposed WINDOW_UPDATE text for session flow control windows

Mark Nottingham <> Tue, 19 February 2013 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F31E521E8064 for <>; Tue, 19 Feb 2013 14:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.619
X-Spam-Status: No, score=-8.619 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wDHNrbGANLHk for <>; Tue, 19 Feb 2013 14:50:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3EB6B21E803A for <>; Tue, 19 Feb 2013 14:50:32 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U7vzR-0004DO-3J for; Tue, 19 Feb 2013 22:48:45 +0000
Resent-Date: Tue, 19 Feb 2013 22:48:45 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U7vzB-0004Ca-LH for; Tue, 19 Feb 2013 22:48:29 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1U7vzA-0001BY-NZ for; Tue, 19 Feb 2013 22:48:29 +0000
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 41DA4509B7; Tue, 19 Feb 2013 17:48:04 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 20 Feb 2013 09:48:00 +1100
Cc: Patrick McManus <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: =?utf-8?Q?William_Chan_=28=E9=99=88=E6=99=BA=E6=98=8C=29?= <>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-2.396, BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1U7vzA-0001BY-NZ 2880ae43acb6d34076a6c1447f5b1644
Subject: Re: proposed WINDOW_UPDATE text for session flow control windows
Archived-At: <>
X-Mailing-List: <> archive/latest/16688
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.


On 16/02/2013, at 11:10 AM, William Chan (陈智昌) <> 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 <> wrote:
> On Sun, Feb 10, 2013 at 2:14 PM, William Chan (陈智昌) <> 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