Re: proposed WINDOW_UPDATE text for session flow control windows

Mark Nottingham <mnot@mnot.net> Tue, 19 February 2013 22:50 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 F31E521E8064 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Feb 2013 14:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.619
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDHNrbGANLHk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Feb 2013 14:50:32 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6B21E803A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 19 Feb 2013 14:50:32 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7vzR-0004DO-3J for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Feb 2013 22:48:45 +0000
Resent-Date: Tue, 19 Feb 2013 22:48:45 +0000
Resent-Message-Id: <E1U7vzR-0004DO-3J@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1U7vzB-0004Ca-LH for ietf-http-wg@listhub.w3.org; Tue, 19 Feb 2013 22:48:29 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1U7vzA-0001BY-NZ for ietf-http-wg@w3.org; Tue, 19 Feb 2013 22:48:29 +0000
Received: from [192.168.1.80] (unknown [118.209.197.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (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 <mnot@mnot.net>
In-Reply-To: <CAA4WUYiW6xsT8g--1cL7HZTVYS_+5Y-WKpzfbx2JCLRqHXNgcQ@mail.gmail.com>
Date: Wed, 20 Feb 2013 09:48:00 +1100
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2595AFA8-9928-4511-B569-3DFC36B73C5C@mnot.net>
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>
To: "William Chan (陈智昌)" <willchan@chromium.org>
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
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: maggie.w3.org 1U7vzA-0001BY-NZ 2880ae43acb6d34076a6c1447f5b1644
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/2595AFA8-9928-4511-B569-3DFC36B73C5C@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16688
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>

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/