Re: proposed WINDOW_UPDATE text for session flow control windows

William Chan (陈智昌) <willchan@chromium.org> Tue, 19 February 2013 22:56 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 3B70B21F88EA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Feb 2013 14:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.379
X-Spam-Level:
X-Spam-Status: No, score=-9.379 tagged_above=-999 required=5 tests=[AWL=0.297, 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 UnB474NI154A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 19 Feb 2013 14:56:36 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6A79F21F8788 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 19 Feb 2013 14:56:30 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7w5x-0007va-Lh for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Feb 2013 22:55:29 +0000
Resent-Date: Tue, 19 Feb 2013 22:55:29 +0000
Resent-Message-Id: <E1U7w5x-0007va-Lh@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1U7w5n-0007uT-7b for ietf-http-wg@listhub.w3.org; Tue, 19 Feb 2013 22:55:19 +0000
Received: from mail-qe0-f44.google.com ([209.85.128.44]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1U7w5m-0001Mo-0Q for ietf-http-wg@w3.org; Tue, 19 Feb 2013 22:55:19 +0000
Received: by mail-qe0-f44.google.com with SMTP id a11so3406697qen.3 for <ietf-http-wg@w3.org>; Tue, 19 Feb 2013 14:54:51 -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=nKgXxaIOFojISP/EWKAACk906ds6mqObi1yNLs3Lu2o=; b=BcC3YVDZeplydiBeo2K7pVrL7Aun1o7QyZFHLSeT5Fz3ZmPuhxt00tFswSAoDIKrXw wJPhbERwp9bqwtsfWBq3idQ756yHnCw4YpsSpmSqbR+zcB2s29YUkOn1t3ko2Dd0bJKl Z6icsRDFO4aDlZUfeVnXW4odo5exaIEDcqoCNux3QM6UZx8MgbvD0zSf7BiBgeygxqaJ 8EaWiCmsEbfzGLnAW1SOLO3WBcezYqJubgChikgZPBL/yheiGB9uJWkq+gDY9zWjT5r0 ORFcwKeJ2hMKCBdr+jz47i1wnVv4FI+x3rmVZw0rtz/PHZMb3klot+vl7eggE4pY+Awm Wq6Q==
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=nKgXxaIOFojISP/EWKAACk906ds6mqObi1yNLs3Lu2o=; b=aCdVp5i/cjXOqAlMEDfpYv/srk61pjxA/esTn21qeyx2JFCrqwK9Yzo6XqkOw/mVQR DAJ3w4sPDeflicIf1glPMCXi3vKrifAANSvkzlV4bwBJRFqMH0eZzkNsvmKHH1CDeJY2 Ad6GVvO7jsSlWc58v7MpY9Wb5Y5w6hLP02CaI=
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=nKgXxaIOFojISP/EWKAACk906ds6mqObi1yNLs3Lu2o=; b=h9oO+XW6uXtw6qBLL0G6AGC3LS2Z1lD/LL0nestwR+FBw++AOS3UxgN22a6Pnrc4dj sKBvDq0YTz1QAvrTVvqPSvTslVuPai0INq4ZYGYkvWicAv2YrMkCkRVnVOqDA91FoL4Z 6pwMegCTcpmeazf+hdCTRwPgoKJ8ui/WovkL0Ur+QvCNfEpeNnlY+6re/SpR6XhLCZhP InpRpDcyA78HpELSh2FjyjrJ9t/+3523xqTMfPXF4dzKFs0FTcysO6+voCoREu03xHtQ TRIroB2IljDpYu1qZ4GeIa2TVWN70r3R1c7C8Ll4AsiWxQEes8tpFmH11zGxjE+21+/b v3DA==
MIME-Version: 1.0
X-Received: by 10.224.108.136 with SMTP id f8mr611533qap.46.1361314491481; Tue, 19 Feb 2013 14:54:51 -0800 (PST)
Sender: willchan@google.com
Received: by 10.229.135.210 with HTTP; Tue, 19 Feb 2013 14:54:51 -0800 (PST)
In-Reply-To: <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> <2595AFA8-9928-4511-B569-3DFC36B73C5C@mnot.net>
Date: Tue, 19 Feb 2013 14:54:51 -0800
X-Google-Sender-Auth: DlpRHfVr3iMgjG1omLwo3S4NTs0
Message-ID: <CAA4WUYg8ksyjKYmeX6YC3P1-iaRRSD_e5KDhpPw0d9i2CnvpSQ@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Mark Nottingham <mnot@mnot.net>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf3074b696b140b204d61bba9d
X-Gm-Message-State: ALoCoQldDYGTMA8am9Q6oLh/nkqiR+HRFlN+VCqfj6oysyvRx41GawEvuXOoucVF1QO+qZUsYRXajwA9q6d2VTWdvDK03P3TWYFszaVkdhF+fDR47YoceT8Jb/FaEBXU/RtRlgSf3ygygRVE9lxofKYshySGo2SDl+tA7M898YnH7FalHDa4RRfwvMmQ0ftuSH6Q1N+9wSfa
Received-SPF: pass client-ip=209.85.128.44; envelope-from=willchan@google.com; helo=mail-qe0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-1.404, BAYES_00=-1.9, 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.637, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U7w5m-0001Mo-0Q 34041a4697cd213840424843ec21a2ad
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/CAA4WUYg8ksyjKYmeX6YC3P1-iaRRSD_e5KDhpPw0d9i2CnvpSQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16689
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'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/
>
>
>
>