Re: proposed WINDOW_UPDATE text for session flow control windows

Martin Thomson <martin.thomson@gmail.com> Wed, 20 February 2013 17:21 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 4679921F8821 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 09:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.458
X-Spam-Level:
X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=3.841, BAYES_00=-2.599, 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 i6hTz2UXs7PM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 09:21:15 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8070E21F84B9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 Feb 2013 09:21:15 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U8DJH-0001xs-8y for ietf-http-wg-dist@listhub.w3.org; Wed, 20 Feb 2013 17:18:23 +0000
Resent-Date: Wed, 20 Feb 2013 17:18:23 +0000
Resent-Message-Id: <E1U8DJH-0001xs-8y@frink.w3.org>
Received: from madai.keio.w3.org ([133.27.228.221]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1U8DIH-0001ll-HB for ietf-http-wg@listhub.w3.org; Wed, 20 Feb 2013 17:17:48 +0000
Received: from we-in-x0232.1e100.net ([2a00:1450:400c:c03::232] helo=mail-we0-x232.google.com) by madai.keio.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1U8DID-0003JJ-J5 for ietf-http-wg@w3.org; Wed, 20 Feb 2013 17:17:20 +0000
Received: by mail-we0-f178.google.com with SMTP id x48so7226372wey.9 for <ietf-http-wg@w3.org>; Wed, 20 Feb 2013 09:16:10 -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:content-transfer-encoding; bh=UnI3LkOkiqtP4YDnL1wq9M7ewg0h4AvrhrJNbul4AAQ=; b=PoB4sJH0T9aJbxj1qT6PNn319ctwfeN2SdxlPpOueheMVoDORShtpc5XGN8pXeQ1n2 WXN5pcFre3MPEBhc6BAQeyxnWtDnsNZXBwN3y+zDBIgfoE1xOzeikkNdQu9a6Xb0TDeS s3YYXobLuLBze0q4Rpkbpt5Ca8XUrjUkGEE2RuQKkPOb+o/oLiQUEkAa4Sc13927Ui5x tfanAk6mnPSXxKcYENLV+tJBS3KNFUFbixmzPK4GyDTv6v4OI38QF72XyWgFHXsJuXr0 QbVj7B1R2WC8UJYpAVQjjnFEu9T+XMH5atES1BoL1B+ljda1qJMON9O2Z33hEQWG0VST wU4A==
MIME-Version: 1.0
X-Received: by 10.180.76.84 with SMTP id i20mr34559670wiw.9.1361380570095; Wed, 20 Feb 2013 09:16:10 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Wed, 20 Feb 2013 09:16:10 -0800 (PST)
In-Reply-To: <CAA4WUYg8ksyjKYmeX6YC3P1-iaRRSD_e5KDhpPw0d9i2CnvpSQ@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>
Date: Wed, 20 Feb 2013 09:16:10 -0800
Message-ID: <CABkgnnU4=OYYZEkS7sfxWjXum+Mpx7RzUdJSzYa9a+UybESQYw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:400c:c03::232; envelope-from=martin.thomson@gmail.com; helo=mail-we0-x232.google.com
X-W3C-Hub-Spam-Status: No, score=-2.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: madai.keio.w3.org 1U8DID-0003JJ-J5 a0b2a0802d7d5a6cc807b54131dacee7
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/CABkgnnU4=OYYZEkS7sfxWjXum+Mpx7RzUdJSzYa9a+UybESQYw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16690
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>

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/
>>
>>
>>
>