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

Ryan Hamilton <> Sat, 21 March 2015 23:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9FF031A9074 for <>; Sat, 21 Mar 2015 16:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.389
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E5CUQMZM8BA7 for <>; Sat, 21 Mar 2015 16:42:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9C221A1B45 for <>; Sat, 21 Mar 2015 16:42:08 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YZSxv-0000qu-Fe for; Sat, 21 Mar 2015 23:38:03 +0000
Resent-Date: Sat, 21 Mar 2015 23:38:03 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YZSxk-0000q4-MB for; Sat, 21 Mar 2015 23:37:52 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1YZSxh-0005E4-Uu for; Sat, 21 Mar 2015 23:37:52 +0000
Received: by yhjf44 with SMTP id f44so54350626yhj.3 for <>; Sat, 21 Mar 2015 16:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id uy3mr92998393vdb.27.1426981043753; Sat, 21 Mar 2015 16:37:23 -0700 (PDT)
Received: by with HTTP; Sat, 21 Mar 2015 16:37:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Sat, 21 Mar 2015 16:37:23 -0700
Message-ID: <>
From: Ryan Hamilton <>
To: Stuart Douglas <>
Cc: Bob Briscoe <>, Mike Belshe <>, Roberto Peon <>, Martin Thomson <>, "" <>
Content-Type: multipart/alternative; boundary="bcaec52be7c936ec3a0511d4eae8"
Received-SPF: pass client-ip=;;
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: 1YZSxh-0005E4-Uu 131097c98acc4b8ccd8a1ab5fdb894ed
Subject: Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>
Archived-At: <>
X-Mailing-List: <> archive/latest/29006
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Sat, Mar 21, 2015 at 1:15 AM, Stuart Douglas <>

> 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!