Re: h2 proxy and connection flow control

Amos Jeffries <squid3@treenet.co.nz> Thu, 21 August 2014 15:52 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B113B1A024C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Aug 2014 08:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO4QFGy9UWQk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Aug 2014 08:52:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB531A0414 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 Aug 2014 08:52:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XKUcA-0006D1-Cy for ietf-http-wg-dist@listhub.w3.org; Thu, 21 Aug 2014 15:49:26 +0000
Resent-Date: Thu, 21 Aug 2014 15:49:26 +0000
Resent-Message-Id: <E1XKUcA-0006D1-Cy@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XKUbl-00068w-Dg for ietf-http-wg@listhub.w3.org; Thu, 21 Aug 2014 15:49:01 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XKUbi-0004nr-HU for ietf-http-wg@w3.org; Thu, 21 Aug 2014 15:48:59 +0000
Received: from [192.168.2.97] (unknown [203.184.52.78]) by treenet.co.nz (Postfix) with ESMTP id 55C0AE700F for <ietf-http-wg@w3.org>; Fri, 22 Aug 2014 03:48:30 +1200 (NZST)
Message-ID: <53F614C2.3020509@treenet.co.nz>
Date: Fri, 22 Aug 2014 03:48:18 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <CAPyZ6=+9sEFaaEBHSvhbzck6mLthatDVamMckYfnUXVMhVbiVg@mail.gmail.com> <CAOdDvNqX0H7hhxtx3ODniuYQU5wt9Qi91BDjOcENssi_m4PbQA@mail.gmail.com> <CAPyZ6=J1b6VYaBJ==H7FsO9ofe9BTv53+DoDTCeRtW8TPmx=Bw@mail.gmail.com> <CAOdDvNr3g5Ch80ypTThNvZDPftPG5Qive6WmHrvHgsw4NEXOTA@mail.gmail.com> <CAPyZ6=+0Ot1XRNw38rBX1hH04hJ1i6pVDpL+CsLUifozB1tDQw@mail.gmail.com>
In-Reply-To: <CAPyZ6=+0Ot1XRNw38rBX1hH04hJ1i6pVDpL+CsLUifozB1tDQw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.0
X-W3C-Hub-Spam-Report: AWL=-3.018, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001
X-W3C-Scan-Sig: lisa.w3.org 1XKUbi-0004nr-HU b2ca8ea4f18632891ee5d3e3efb06248
X-Original-To: ietf-http-wg@w3.org
Subject: Re: h2 proxy and connection flow control
Archived-At: <http://www.w3.org/mid/53F614C2.3020509@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26693
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 22/08/2014 2:56 a.m., Tatsuhiro Tsujikawa wrote:
> On Thu, Aug 21, 2014 at 11:12 PM, Patrick McManus wrote:
> 
>>
>>
>>
>> On Thu, Aug 21, 2014 at 10:09 AM, Tatsuhiro Tsujikawa wrote:
>>
>>>
>>>
>>>
>>> ​In this scenario, proxy has no room to expand. Therefore I wrote that​
>>> all streams on backend connections are stalled.
>>>
>>>
>> This is my point. If the proxy really has no room to expand (its out of
>> ram) - then we've got a resource problem not a protocol problem. If it does
>> have more ram, then just use the protocol to open the window to match the
>> resources available.
>>
>>
> ​So if there is no ram to spend for that connection, is stalling entire
> connection inevitable consequence (and we should not care about it)? ​
> Connection flow control is limit the memory commitment for proxy then why
> do we need to extend it in the response to a client behavior?

For the browser connection the browser has explicitly indicated with its
matching stream and connection windows that it is happy for the other
streams to stall.
The proxy should not allow itself to stall the server connection. Namely
by reducing its window on all streams from that client as soon as it
detects the clients connection window getting low.

Proxies have to operate under the assumption that a number of other
clients and/or streams will be arriving very soon and need to use
resources. So no resource can be allocated beyond what can be passed on
quickly.

Amos