Re: h2 proxy and connection flow control
Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Fri, 22 August 2014 04:47 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 89F481A0016 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Aug 2014 21:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.669
X-Spam-Level:
X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 iJ535jTqzwWL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Aug 2014 21:47:02 -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 9A8731A0010 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 Aug 2014 21:47:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XKghT-0005Nc-6d for ietf-http-wg-dist@listhub.w3.org; Fri, 22 Aug 2014 04:43:43 +0000
Resent-Date: Fri, 22 Aug 2014 04:43:43 +0000
Resent-Message-Id: <E1XKghT-0005Nc-6d@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <tatsuhiro.t@gmail.com>) id 1XKggy-0005Ds-7S for ietf-http-wg@listhub.w3.org; Fri, 22 Aug 2014 04:43:12 +0000
Received: from mail-ig0-f180.google.com ([209.85.213.180]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <tatsuhiro.t@gmail.com>) id 1XKggw-0005Mf-95 for ietf-http-wg@w3.org; Fri, 22 Aug 2014 04:43:11 +0000
Received: by mail-ig0-f180.google.com with SMTP id l13so13982777iga.7 for <ietf-http-wg@w3.org>; Thu, 21 Aug 2014 21:42:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l1yi0SSAMRFBZwzYVrpyOqNkW6KlTcDBgiXa686tyso=; b=DUEfdfx20sU3W69i4wrqsiD5XbcUK1LnE0oeWrGf3wNkuwIYvywOqNr4XAsVehWrgn kLDRatCOKrC72LjbBktbHcpB9Fl0z7NFVjJEF4ogDQK6T324EuwfF/SQ9s3dP2Eyz9fo GIEJnyyBfmZrFmlfE099eTumAsjNLWnwk50a47z6LmG0gaGZPx0ufYwGJtO3ayhJw7jv v6pfAzWMYbbQB8J6qPN4VI06oWl3QX5i3gCLyFytoeHZJ6xGF9GIXNnom8eFUkI7MPv1 3y4oooq6iLUgKbiESAUkFRLie2YOWxDJoa9NFWUF9UizmPHCu+tK6UuClEj9kfw6EhvW 9HUA==
MIME-Version: 1.0
X-Received: by 10.43.164.130 with SMTP id ms2mr7600109icc.9.1408682564444; Thu, 21 Aug 2014 21:42:44 -0700 (PDT)
Received: by 10.64.14.144 with HTTP; Thu, 21 Aug 2014 21:42:44 -0700 (PDT)
Received: by 10.64.14.144 with HTTP; Thu, 21 Aug 2014 21:42:44 -0700 (PDT)
In-Reply-To: <53F614C2.3020509@treenet.co.nz>
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> <53F614C2.3020509@treenet.co.nz>
Date: Fri, 22 Aug 2014 13:42:44 +0900
Message-ID: <CAPyZ6=JRarLFJqHnSt9uNURu62x_9Z8W4LhfZ8zYpg0Ps30wTw@mail.gmail.com>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="001a11c30ad0dae9c10501307782"
Received-SPF: pass client-ip=209.85.213.180; envelope-from=tatsuhiro.t@gmail.com; helo=mail-ig0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.687, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 1XKggw-0005Mf-95 76be236edd5d9a6e6100ff820ec2544a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: h2 proxy and connection flow control
Archived-At: <http://www.w3.org/mid/CAPyZ6=JRarLFJqHnSt9uNURu62x_9Z8W4LhfZ8zYpg0Ps30wTw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26702
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>
2014/08/22 0:53 "Amos Jeffries" <squid3@treenet.co.nz>: > > 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. This is great hint. The failure I made is always update stream and connection window at the same time. It should be updated independently. So when Frontend Proxy sends data to Browser, it only sends connection level WINDOW_UPDATE to Backend. Stream level WINDOW_UPDATE is deferred until Browser sends strean level WINDOW_UPDATE for data which is not acked. Obviously this requires that Frontend Proxy's stream window is not larger than Browser's. Best regards, Tatsuhiro Tsujikawa > > Amos > >
- h2 proxy and connection flow control Tatsuhiro Tsujikawa
- Re: h2 proxy and connection flow control Patrick McManus
- Re: h2 proxy and connection flow control Tatsuhiro Tsujikawa
- Re: h2 proxy and connection flow control Patrick McManus
- Re: h2 proxy and connection flow control Tatsuhiro Tsujikawa
- Re: h2 proxy and connection flow control Amos Jeffries
- Re: h2 proxy and connection flow control Martin Thomson
- Re: h2 proxy and connection flow control Tatsuhiro Tsujikawa
- Re: h2 proxy and connection flow control Ilari Liusvaara
- Re: h2 proxy and connection flow control Tatsuhiro Tsujikawa
- Re: h2 proxy and connection flow control Martin Thomson