Re: proposed WINDOW_UPDATE text for session flow control windows

Martin Thomson <martin.thomson@gmail.com> Wed, 20 February 2013 23:02 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 46BE021E8037 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 15:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IBSvXvDI5tWf for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 Feb 2013 15:02:11 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9CF21E8030 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 Feb 2013 15:02:11 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U8IfO-0004Ks-Bi for ietf-http-wg-dist@listhub.w3.org; Wed, 20 Feb 2013 23:01:34 +0000
Resent-Date: Wed, 20 Feb 2013 23:01:34 +0000
Resent-Message-Id: <E1U8IfO-0004Ks-Bi@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1U8IfC-0004Hr-Ao for ietf-http-wg@listhub.w3.org; Wed, 20 Feb 2013 23:01:22 +0000
Received: from mail-wi0-f179.google.com ([209.85.212.179]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1U8If4-00060f-VL for ietf-http-wg@w3.org; Wed, 20 Feb 2013 23:01:22 +0000
Received: by mail-wi0-f179.google.com with SMTP id ez12so6892169wid.12 for <ietf-http-wg@w3.org>; Wed, 20 Feb 2013 15:00:48 -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; bh=81scnd3tscXlxAWSKvKGG36EFCWm52KLOIaetO7c5iQ=; b=j3v2qJjbXO7/188ZryuzL5Lu8RoSdPVo5kWd3E2ikkmGfPhtzaYOBCKHALaJe08Icq jwTGcv7ArmTAokt8VdAl5TZDjqmA0o3JQaGTcAQzjqQnbKu/NBUZ9AAurv6pNsYziWGm Apg/DoRP0iia98xx7OqXOcbPnAT9X4u+crFJyFHR9+aYUSNBj/SRDMXI6NvydoFsl/Xn 2JuM671IGovuLu0oRuw2plZvyfQs5icb3iwQQwf/UjfVJ7DL8B8/BAELW6LoiqdBpVVf HREcAzGkgMdlH6h9epTOZqVXH+oIBmZkoIdHFoBr+cxvpg4Kd78Y53KUXt/MSpVLcAI9 e+2Q==
MIME-Version: 1.0
X-Received: by 10.194.88.202 with SMTP id bi10mr37371593wjb.5.1361401248806; Wed, 20 Feb 2013 15:00:48 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Wed, 20 Feb 2013 15:00:48 -0800 (PST)
In-Reply-To: <CAP+FsNd5bCpcVg7Z9Q=D1goYZ2keGnxPmy2G79O+h5K6bSa=cA@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> <CAA4WUYh1qU6HPbeZTsFTy7i5svxWS2dATgUNyaoGnzbMLkCELg@mail.gmail.com> <CABkgnnUH5_t4BesWz2K5gtR0k0+ve42k-EWEaObK_nteh9fOUw@mail.gmail.com> <CAP+FsNcZrQ072mQikMSnyFrKqN0yDYhh=-8G4848YxdO_M-_zw@mail.gmail.com> <CABkgnnU8Okqrq5POYZqDyFUoFzkQwjRAvQJQQ_jhCO9heaFYNA@mail.gmail.com> <CAP+FsNd5bCpcVg7Z9Q=D1goYZ2keGnxPmy2G79O+h5K6bSa=cA@mail.gmail.com>
Date: Wed, 20 Feb 2013 15:00:48 -0800
Message-ID: <CABkgnnWgNHHHuCSXNpDQSVbaBTp=ZYnPH+MX9-_CXvaj4VD83w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>, 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
Received-SPF: pass client-ip=209.85.212.179; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f179.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U8If4-00060f-VL 3a9f64a876d0416c8b49e591510de141
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/CABkgnnWgNHHHuCSXNpDQSVbaBTp=ZYnPH+MX9-_CXvaj4VD83w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16698
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 20 February 2013 14:52, Roberto Peon <grmocg@gmail.com> wrote:
> I'm afraid of simply sending a large window size, because I suspect that
> simple implementations will mess it up for objects > 31 bits in size.

Yes. Absolutely.

> If we don't have a SETTINGS thing, then we're requiring flow control for the
> first RT for any stream.

Yes, that's the implication.  Though a client is always able to
disable flow control without consequence, because it speaks first,
before the server sends anything.  It's only servers that need to
worry about having it on briefly.  The consequences are minimal - they
just don't receive as many packets as they possibly could - but then
that is always true for two reasons: TCP INIT CWD and the time it
takes to send the WINDOW_UPDATE.

> I like the flag solely because it is difficult to do by accident, unlike
> using zero (which is technically fine otherwise)

I don't believe in accidents, but I see your point.

> The other thing to consider is when, if ever, one can transition from
> flow-control disabled to requiring its use again.
> Even if we don't allow this, it will require text explaining it.

I thought about this.  The obvious choice is to start again from zero
when a WINDOW_UPDATE comes in.  The problem is knowing (at the
receiver end) when counting started.  Once you stop counting, that's
the real difficulty.  I believe that once it's off, flow control will
need to stay off.