Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>

Ryan Hamilton <rch@google.com> Sat, 21 March 2015 23:42 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 9FF031A9074 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Mar 2015 16:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.389
X-Spam-Level:
X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 E5CUQMZM8BA7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 21 Mar 2015 16:42:09 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C221A1B45 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 21 Mar 2015 16:42:08 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YZSxv-0000qu-Fe for ietf-http-wg-dist@listhub.w3.org; Sat, 21 Mar 2015 23:38:03 +0000
Resent-Date: Sat, 21 Mar 2015 23:38:03 +0000
Resent-Message-Id: <E1YZSxv-0000qu-Fe@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <rch@google.com>) id 1YZSxk-0000q4-MB for ietf-http-wg@listhub.w3.org; Sat, 21 Mar 2015 23:37:52 +0000
Received: from mail-yh0-f45.google.com ([209.85.213.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <rch@google.com>) id 1YZSxh-0005E4-Uu for ietf-http-wg@w3.org; Sat, 21 Mar 2015 23:37:52 +0000
Received: by yhjf44 with SMTP id f44so54350626yhj.3 for <ietf-http-wg@w3.org>; Sat, 21 Mar 2015 16:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+TK851UwRiU1GyJx+9rOIZa7l+G7hHkJQZshDgLFD7Q=; b=o5/baB23FEXXxzsqAlJ+tQFCw0vPl2K8+X/dAt7nNxXca09qV5MiJ8Ud+8DHML9c4u /0oztMty7ChOidHToUXgwONhecF/dvCJJRbsg1LhmNEr04k4HpdzEMzGDDQL6a+i3E3c +QaHyHvxzzxe77aaBXjuybXQpsun6ZfLnbg0XbUB2cW+GxGA23IyAMxUmxaSWknsAz1A qIkWrbZzeASbEzrp3COrbvwAjA8pjHyKLCWOm1aocFdRZSF41ut1p8ZDcR2/maV8M7bC 9+PZ3w7ZuFY0obv9hiVs1dS/x17ckS6AzNV/iUC5upqRaQmS0kbUP0AWYvlIvdXWRJ7o qT9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+TK851UwRiU1GyJx+9rOIZa7l+G7hHkJQZshDgLFD7Q=; b=ld9+04csh4QZLk/wNtnTATX14An4VgbUE8YxPQRWXAomAVJ3+S6c3rIQ3zTwDje3Oe C9dDJeaEtNc+a+5xSAbN9elL2j55p4PIi4QmLbuDiw/XZtv1curLDuKk2ZT0lKDVOzul S3pGdWFCmDabrslV8900Ryq3HgivU/PJ4/0gnYSmnyePEhzFzCOBlTaPnTrdgQWGrkdL eTVgRulG0woyNHhowI3e6SkH6kS9ECmUoOMpvz9RGOflSt6W6XWXWTGCZxAZ+Oz9ob7f y/hystP//syHTWtLg7PVSVcdbADSogm5Fedtj5212xsJlHftA8Qy4EcreRD0zcCqvuaJ wIVg==
X-Gm-Message-State: ALoCoQlXbjBwdH+CKgbApYHovS4UG8S+60XU58Fmc35S9mvXt9GpEk5Uf0ZtXuBBsiUFTdx+rw/G
MIME-Version: 1.0
X-Received: by 10.52.152.131 with SMTP id uy3mr92998393vdb.27.1426981043753; Sat, 21 Mar 2015 16:37:23 -0700 (PDT)
Received: by 10.52.169.202 with HTTP; Sat, 21 Mar 2015 16:37:23 -0700 (PDT)
In-Reply-To: <550D289F.1060105@gmail.com>
References: <201503061443.t26EhiV9013453@bagheera.jungle.bt.co.uk> <CAAoo=c7Wov+WG9sMNHWumCaAF5v6mdudZWma3jxy6x3L-4DNtw@mail.gmail.com> <201503201822.t2KIMA75012552@bagheera.jungle.bt.co.uk> <550D289F.1060105@gmail.com>
Date: Sat, 21 Mar 2015 16:37:23 -0700
Message-ID: <CAJ_4DfREq=S7nBVNWs8SrtUqDrpSK7+V4aNW+=cCOk3SRprUNg@mail.gmail.com>
From: Ryan Hamilton <rch@google.com>
To: Stuart Douglas <stuart.w.douglas@gmail.com>
Cc: Bob Briscoe <bob.briscoe@bt.com>, Mike Belshe <mbelshe@chromium.org>, Roberto Peon <fenix@google.com>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="bcaec52be7c936ec3a0511d4eae8"
Received-SPF: pass client-ip=209.85.213.45; envelope-from=rch@google.com; helo=mail-yh0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.625, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1YZSxh-0005E4-Uu 131097c98acc4b8ccd8a1ab5fdb894ed
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>
Archived-At: <http://www.w3.org/mid/CAJ_4DfREq=S7nBVNWs8SrtUqDrpSK7+V4aNW+=cCOk3SRprUNg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29006
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 Sat, Mar 21, 2015 at 1:15 AM, Stuart Douglas <stuart.w.douglas@gmail.com>
wrote:

> Very much so. Per stream flow control is essential for buffer management
> on the server.
>
> Basically my server implementation has to keep reading from the socket, to
> make sure that any new messages are received and acted on in a timely
> manner, and to allow multiplexing to work correctly. Consider the case of a
> client uploading a large file, where for whatever reason the end user
> application is slow to read the data (perhaps it is doing some database
> operations before it starts to read the file data). If we did not have per
> stream flow control I would only have three options:
>
> - buffer a potentially unbounded amount of data
> - stop reading from the socket (HOL blocking)
> - kill the connection
>
> All these options suck, but with per stream flow control I know I will
> never have to buffer more than the window size (as we don't send
> WINDOW_UPDATE until the application has consumed the data).
>
> Another good example of why per stream flow control is necessary is a load
> balancer, with a fast connection to backend servers, and a slow connection
> to the remote clients. If we did not have per stream flow control the
> backend servers would just dump all their data straight to the load
> balancer, forcing it to either block or buffer (you implied that TCP level
> flow control should be sufficient for this case, however this is only true
> if your load balancer maintains a 1:1 connection between the client and a
> backend server, which is generally not the case.
>

​This is an excellent ​writeup! It captures exactly the tradeoffs which led
to the addition of per-stream flow control to the protocol. Well said!