Re: proposed WINDOW_UPDATE text for session flow control windows

William Chan (陈智昌) <willchan@chromium.org> Wed, 20 February 2013 20: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 08CB521E8049 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 12:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.386
X-Spam-Level:
X-Spam-Status: No, score=-9.386 tagged_above=-999 required=5 tests=[AWL=0.290, 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 xHXdcyo0Z3J8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 12:12:33 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5608121E8041 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 Feb 2013 12:12:33 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U8G10-0002cC-K9 for ietf-http-wg-dist@listhub.w3.org; Wed, 20 Feb 2013 20:11:42 +0000
Resent-Date: Wed, 20 Feb 2013 20:11:42 +0000
Resent-Message-Id: <E1U8G10-0002cC-K9@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 1U8G0q-0002ZA-CS for ietf-http-wg@listhub.w3.org; Wed, 20 Feb 2013 20:11:32 +0000
Received: from mail-qc0-f170.google.com ([209.85.216.170]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1U8G0j-0002JW-LL for ietf-http-wg@w3.org; Wed, 20 Feb 2013 20:11:32 +0000
Received: by mail-qc0-f170.google.com with SMTP id d42so3278127qca.29 for <ietf-http-wg@w3.org>; Wed, 20 Feb 2013 12:10:59 -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=e3eCBCevHk2iDoZw2wszvQa/27nUiqCwk60DgB1r9Tw=; b=FR3ccjRpnWSTJJYQxWB2hrsPIDU0u68jLPOuX9LaCV8z0ocyl2xpp4WDiUDMuPvRku AfJVgf9F8HSgyZLtoA/n28LZHrHjIWEzzKbzGH6gG2cdV7YLFAV61WEzexK1kFnhP3wW 0TJd194/dP+Im2zauV4dl8ae17+GVzfh5Z+U2p+95T6XspNFrGua605diLAwHnQ8zrkh ez+wdRgVmAHtaghsUltk+W8NURjSYcNn5xvveOTjBDS+qHUtUiQkCkh11aa1FfpYEQ4V 66oiEvBP5NHngWAOQVege5/Adfn5sUlKmrwS68gWeFfNjpUtZvijXr+Ij7ZSjnn9/+od HnKw==
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=e3eCBCevHk2iDoZw2wszvQa/27nUiqCwk60DgB1r9Tw=; b=TzMOyQXWI5nz6DJR6mzWvwfP9KxqbV7QmtJSUHb6htSaeC34pvcuOJB12Y8Rioy58L hz2vSOyYnmVgkmw8E8jCwV0Q/D318WMwqUUj66aG4WvnPsMnOvoTer0GpBnREKF62sUp Hi8abjFKMUuHGRHLcQ4eg9tEZK+WVJZPB9BLE=
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=e3eCBCevHk2iDoZw2wszvQa/27nUiqCwk60DgB1r9Tw=; b=VqRCbMvJ4ltwO8NIjzOeNVk66HwNA8FKcOY/7rgbU0QMQsMWu5aoc7y0mE5nIGnx5Y Si7quJQRnKzTHA9yXMGDgDl5MfuH1hpLx4SwU1ra4z4uoJ6x0leRWOVornwxcSEDIjoB M4hLWWWxRqNR9nVBvV5KkykB2IRd2vb6elDC2koIrmfOo+1RjG9a6MeDIBqDrbouym39 jz6i9PhwTh5W6hFD7oYNcmXR5nT/h+vQVz5Q4TPKq1Q6koNLcCF9NGpypBWEc82etNOE AmsLSq7CyhnxgBJY9hPDTdFbA6PYvAt552eps4So+bni6BlP9Jm3oZ/mk2sz2hghE4xM pzqg==
MIME-Version: 1.0
X-Received: by 10.224.108.136 with SMTP id f8mr2475223qap.46.1361391059472; Wed, 20 Feb 2013 12:10:59 -0800 (PST)
Sender: willchan@google.com
Received: by 10.229.135.210 with HTTP; Wed, 20 Feb 2013 12:10:59 -0800 (PST)
In-Reply-To: <CAP+FsNcDxJeU=7+x8Jx5TO0hm_P2yCKPu7_tEZF0GEtjMbQ2Xg@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> <CABkgnnU4=OYYZEkS7sfxWjXum+Mpx7RzUdJSzYa9a+UybESQYw@mail.gmail.com> <CAP+FsNcDxJeU=7+x8Jx5TO0hm_P2yCKPu7_tEZF0GEtjMbQ2Xg@mail.gmail.com>
Date: Wed, 20 Feb 2013 12:10:59 -0800
X-Google-Sender-Auth: AeeQHRnmHGhc6MRItsCAeG7liwA
Message-ID: <CAA4WUYh1qU6HPbeZTsFTy7i5svxWS2dATgUNyaoGnzbMLkCELg@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=20cf3074b69680110904d62d8e2b
X-Gm-Message-State: ALoCoQkH0/56ZcOQdTucsdIAV+Ciwmahpa/01rXtEAwh0eDh/9Xb+6Aj49Jzr/F+bkKVpBw/zCMvAOECxY/8P1a3S4ahezgGhpagnz3IrZxvnLC0mkAcAm+Gf0ud22WvPm67GmQiPPhBtGfSAZ17UhHIgDmuaS2CXSdEnv5FG60H7MDQMeRczY3Lhg2p2v1BBOBXpJts+XYy
Received-SPF: pass client-ip=209.85.216.170; envelope-from=willchan@google.com; helo=mail-qc0-f170.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.378, 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.593, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U8G0j-0002JW-LL 0b5d6f6c56cb34e2f35e1e38fd3139a0
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/CAA4WUYh1qU6HPbeZTsFTy7i5svxWS2dATgUNyaoGnzbMLkCELg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16692
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>

Do we need a protocol mechanism for this? What's wrong with advertising a
huge window and sending huge WINDOW_UPDATE frames as needed? Is the goal to
allow implementations to actually not implement receiver flow control at
all, and just disable it? Considering implementations always need to
support the peer's receive window advertisements, I view the extra
implementation difficulty of supporting receive windows correctly as pretty
marginal. That said, I do guess it's possible for implementations to set it
to extremely high, and in their testing never hit those window limits, and
have everything hang because they never sent out more WINDOW_UPDATEs. I do
admit that'd be bad.

I guess I don't feel too strongly. Just wanted to make sure there was an
agreement that we needed an extra protocol mechanism rather than just
advertising huge windows and updating as needed.


On Wed, Feb 20, 2013 at 12:02 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Two proposals:
>
> 1) Assuming we need/want this on a per-stream basis:
> Use a flag value (lets say 0x2) with the delta-window-size field set to
> all bits on (i.e. 0xFFFFFF).
> all-bits-on is currently illegal (the top bit is reserved so that we might
> use negative window updates in the future, should we decide to do that), so
> this should be quite difficult to screw up.
>
> Setting this on stream '0' would disable the session-level flow control.
>
> 2) Change SETTINGS so that it also includes the flag byte. This would be
> accomplished by adding a new settings ID (10). The LSB of that settings
> value would be interpreted as the flag-byte, as if received as in scheme 1.
> Thus, a settings with id:7, value 0xFFFFFFFF and with id:10
> value:0x00000002 would disable flow control
>
>
>
>
> On Wed, Feb 20, 2013 at 9:16 AM, Martin Thomson <martin.thomson@gmail.com>wrote;wrote:
>
>> 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/
>> >>
>> >>
>> >>
>> >
>>
>>
>