Re: proposed WINDOW_UPDATE text for session flow control windows

William Chan (陈智昌) <willchan@chromium.org> Sat, 16 February 2013 00:12 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 0EE4521F84C0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Feb 2013 16:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.328
X-Spam-Level:
X-Spam-Status: No, score=-9.328 tagged_above=-999 required=5 tests=[AWL=0.348, 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 s8q9rquZKjhk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 15 Feb 2013 16:12:29 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F2A4821F84BB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 15 Feb 2013 16:12:28 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U6VMy-0002zl-28 for ietf-http-wg-dist@listhub.w3.org; Sat, 16 Feb 2013 00:11:08 +0000
Resent-Date: Sat, 16 Feb 2013 00:11:08 +0000
Resent-Message-Id: <E1U6VMy-0002zl-28@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 1U6VMo-0002x6-VJ for ietf-http-wg@listhub.w3.org; Sat, 16 Feb 2013 00:10:59 +0000
Received: from mail-qa0-f43.google.com ([209.85.216.43]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1U6VMn-0001xi-UP for ietf-http-wg@w3.org; Sat, 16 Feb 2013 00:10:58 +0000
Received: by mail-qa0-f43.google.com with SMTP id dx4so552078qab.16 for <ietf-http-wg@w3.org>; Fri, 15 Feb 2013 16:10:32 -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=FyIiMGUuaXE5KYUcQLh17FLdMRdx9ijO+ZdBZv4IiDc=; b=mfWzsv3eZCmraMwbDk18vrRafykgS/4yXuFxQaOMQvzdeZLQH1CFf4kIxdOrh/83un KAkPbBT4jdYyFuzCEnYDsYHZucOgnh6OsEZm4IBYpxxUZecKed8eegxe9Q38Ohg+5fF4 fR7ggqXrGmr/TcPRWvzwjf6Mv2pfPa/u7Qr02B2Ds9iYlXLFpuc9lDuBEtEZLwI6L8QZ 3gsSOgvJqpKwE6baVJLVsDMzVqWaULFZblYKmoxTJKKMnqIKql0+r0alWIKRtNWY7HGG 48Q7EtwS9TBuO7Ad2o0RcUTVrUaENS8YrZoZVF5vntDKQYxabRXOVfICnj/Mput803Hg /MeA==
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=FyIiMGUuaXE5KYUcQLh17FLdMRdx9ijO+ZdBZv4IiDc=; b=Gcpm+Z3HycSCRJrNExIhC5GV7sctYgY22PVve38K8FUH4/70XkWkJmAkDppYzvLx95 AF8vD6Mw6Du4Ti92rJmwyvz9BMZ7pl5XWZUCEdb/DkGcyEmPS+WIhDslR6aeBcnYJMUk vaa/3HlFeOq9OiQvXWDXjd19v+lTc2YGSRHpo=
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=FyIiMGUuaXE5KYUcQLh17FLdMRdx9ijO+ZdBZv4IiDc=; b=gEl7nmXYOq9eQWtoDYxA0Ug/YSXSIIy8wc0829YypvZQpMByxsNp+pHxIzMM0yO5yX UGNujrNzBkrUORXJLGjG0/Eas1no0W1hW/+p5cKtiYTE6kW4k/6uP7C3euwOz1S6zGh1 HjLlwBzvO3yDAsOiPvs8pFfaXILCDF/pVevfQIjyT4mDQtYrOolIzImf2u9DC/03nAV3 qy2ArMvh/6mfsfwIsmOxQOvj08GECUx5FIccTSoj1EaTLqEYmHrz2rLghrzYBsxjbfZi doX8hU1iMmlW4TKnWyQzG8+iym5Vi+fVM8MyOoBdCdknkCX1hnINzlR8W5y9yiQmnv1O eD3A==
MIME-Version: 1.0
X-Received: by 10.229.198.22 with SMTP id em22mr355442qcb.2.1360973431996; Fri, 15 Feb 2013 16:10:31 -0800 (PST)
Sender: willchan@google.com
Received: by 10.229.135.210 with HTTP; Fri, 15 Feb 2013 16:10:31 -0800 (PST)
In-Reply-To: <CAOdDvNqTNa=R1MzZe1mKZF34tW-=mhHnM_s_XPVzBBSEWHveVQ@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>
Date: Fri, 15 Feb 2013 16:10:31 -0800
X-Google-Sender-Auth: Ce90LB43ciXpLehZ8yeyeaF_jqw
Message-ID: <CAA4WUYiW6xsT8g--1cL7HZTVYS_+5Y-WKpzfbx2JCLRqHXNgcQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001636d33be2f682a204d5cc51ca
X-Gm-Message-State: ALoCoQn8a6SprgvlVPEMzIxay7hwx+g3xm8pS0z5rASvDamwWTl4n4ouBSrs/YoiD9sTgEy9IAjR2a3jTfbM7507AKpaS1bKsDnvkLbDX7IHfsLoBg7qlqJt4YztybL1t4resiS/szL0xb5YC2NVttXID5vkZxgn4X14MGmhx3jPaNYD/d9V+oC4hOOrSqztPCDhCnszgSQO
Received-SPF: pass client-ip=209.85.216.43; envelope-from=willchan@google.com; helo=mail-qa0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.599, 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.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U6VMn-0001xi-UP 8a97265f189af28915badc6c8b53a2e9
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/CAA4WUYiW6xsT8g--1cL7HZTVYS_+5Y-WKpzfbx2JCLRqHXNgcQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16614
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>

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;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?
>>
>>
>>
>