Re: proposed WINDOW_UPDATE text for session flow control windows

Patrick McManus <mcmanus@ducksong.com> Tue, 12 February 2013 14:57 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 0B31421F8EA7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Feb 2013 06:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.736
X-Spam-Level:
X-Spam-Status: No, score=-9.736 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 EF2iHWAfB2Pv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Feb 2013 06:57:16 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 57CE521F8E75 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 Feb 2013 06:57: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 1U5HGM-0001O3-0z for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Feb 2013 14:55:14 +0000
Resent-Date: Tue, 12 Feb 2013 14:55:14 +0000
Resent-Message-Id: <E1U5HGM-0001O3-0z@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1U5HG1-0008WM-64 for ietf-http-wg@listhub.w3.org; Tue, 12 Feb 2013 14:54:53 +0000
Received: from mail-oa0-f54.google.com ([209.85.219.54]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <patrick.ducksong@gmail.com>) id 1U5HFw-0001tF-5K for ietf-http-wg@w3.org; Tue, 12 Feb 2013 14:54:53 +0000
Received: by mail-oa0-f54.google.com with SMTP id n12so157027oag.27 for <ietf-http-wg@w3.org>; Tue, 12 Feb 2013 06:54:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=VgUuoeq62YyNO5MCRRHWReZcl0t83m5ngyyneJDGqGY=; b=UJQfHtO9cqzqxwu+azj3jaRVmKEnuB410Q+kY7EaMO0P8TIlna14m3M6lK8DD1gFBh 1qnc7zKnQJwj1VZ7GVeq8JvDNtkhF37kqlrdDbOIj8zuVgGTG16QOEowQHU+iSzEr6kl P7jL5v0M5BfZiTQTsv98L/DsiLsS3ysf8Nl3fW4QMwPzqBHB5oeE2Vy1TTXLFNVZReq/ 2SACxA8+mHqIM/Op2LMogQYwmcgBD1uhauFM5J6EkamN6t6q++0tnH/pMBVXsuPd8LzL VItHBaYmQhWlxStkd7OVWvaA2nkfkkUwA7AG2RJs8Zkh1zuB1XqfRk304v13dmM/QhUC Y8+A==
MIME-Version: 1.0
X-Received: by 10.60.22.198 with SMTP id g6mr13956661oef.45.1360680861970; Tue, 12 Feb 2013 06:54:21 -0800 (PST)
Sender: patrick.ducksong@gmail.com
Received: by 10.76.80.98 with HTTP; Tue, 12 Feb 2013 06:54:21 -0800 (PST)
In-Reply-To: <CAA4WUYg2gn7Um1FZk3KBcP5aH=RpSCbYduFz3M+hZGQ_A4tsxQ@mail.gmail.com>
References: <CAA4WUYiH8tCF83=jsk_jsvhXkYvmJ+pPLFzhacAMq3O54z2YBw@mail.gmail.com> <CAOdDvNqCe3d7QerQaxiwdwJ+wC+4CGA4ZrLRYFY75nR2QFThog@mail.gmail.com> <CAA4WUYg2gn7Um1FZk3KBcP5aH=RpSCbYduFz3M+hZGQ_A4tsxQ@mail.gmail.com>
Date: Tue, 12 Feb 2013 09:54:21 -0500
X-Google-Sender-Auth: UuDl1gRNcPJRHkU6o-6t_zIHQ9I
Message-ID: <CAOdDvNqTNa=R1MzZe1mKZF34tW-=mhHnM_s_XPVzBBSEWHveVQ@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="e89a8fb2016e6e313c04d588336f"
Received-SPF: pass client-ip=209.85.219.54; envelope-from=patrick.ducksong@gmail.com; helo=mail-oa0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U5HFw-0001tF-5K 9c5e449c6d86437ec85ccbf1bc3a5c52
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/CAOdDvNqTNa=R1MzZe1mKZF34tW-=mhHnM_s_XPVzBBSEWHveVQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16585
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>

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