Re: Stream State and PRIORITY Frames

Cory Benfield <> Tue, 17 January 2017 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7DF1129462 for <>; Tue, 17 Jan 2017 10:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mjPJqmcc49Ze for <>; Tue, 17 Jan 2017 10:28:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1517A127ABE for <>; Tue, 17 Jan 2017 10:28:43 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cTYSj-0005mC-6A for; Tue, 17 Jan 2017 18:26:29 +0000
Resent-Date: Tue, 17 Jan 2017 18:26:29 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cTYSf-0005lS-Ns for; Tue, 17 Jan 2017 18:26:25 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cTYSZ-0004BZ-80 for; Tue, 17 Jan 2017 18:26:20 +0000
Received: by with SMTP id c85so212121771wmi.1 for <>; Tue, 17 Jan 2017 10:25:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yu9spxaZ6GgNAXpbv6VgZZpiM39aYo9hd0AEV7wIts8=; b=Fdhk2zK5x0vdaynNz0h0Ml8YbLFQeZd2DbKqO+52n1ER8QaejyVsFOe0rDoCYCLygW dGzKV8cdV/Hy8/R+cKPL7A8GOKS47hU8z847f8XBWCf7LPtu/lgfuRoKRNGuPcXFILc8 gFtgCgtEZPVult5Wqn+Pn3Wsz0iwpJCAhwjrmF/PETukTcMyCGTqVJNGWj1Ma6/R515A Rv7myMnVX68gxhWKsf/+PtlGdc1AusSLAaH2ZYmOaPXuAkSWWgH7z+3aM4cVvybKD1jr VldXIsCKhynbwvCeLlPAxRiBMb/ryXG+8hWIZNQ3Qop62HEhYe7rP7+PZ4VREAZxVvOO fajw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yu9spxaZ6GgNAXpbv6VgZZpiM39aYo9hd0AEV7wIts8=; b=YUMffKHYnwuL032e07rSgTS0HeZ3Z7IkMy668oC6bHA/xfvonNYOGXDyhREy/I1tUa 2ah5VZQgCHHwv7WXgCzB+av2e+fZ8GNzTysySf9s+Aii3SPYpUnYmX4r1GoW6gPX/x2t M0tiY4VwES/1Q2GKgxgnyvpJIhjFvt1KxZVnF1lHPICobi/GCCdVK5IcyLb3eEIkBgp1 JfZAqu/Nz4/f4Y9Ub34/2OLHNIeHxOGbiZjHSc5Fog8PC7bySYrOdDGw7kDvt0V1aPNm /NYksnADNKGUu0YJ8PfLOqNSNPblA+rUWjLOahbd2Mx28zy02PvpQJKcZW5qtePjdm5M 4fIQ==
X-Gm-Message-State: AIkVDXJO9QCKKnFwJcEI+dK25Nx84o8+wrr733uJg3Z3D97rKbs0NJDdw5P8G9vKddf+MQ==
X-Received: by with SMTP id k40mr13796217wrk.24.1484677552080; Tue, 17 Jan 2017 10:25:52 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id f76sm38790677wmd.15.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 10:25:51 -0800 (PST)
From: Cory Benfield <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB8B1A17-6B05-45B0-B396-442DA97B650D"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 17 Jan 2017 18:25:49 +0000
In-Reply-To: <>
Cc: Benedikt Christoph Wolters <>, HTTP Working Group <>
To: Scott Mitchell <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.408, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cTYSZ-0004BZ-80 bb473cf6b8fbf08db1bc7681eb63e428
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <>
X-Mailing-List: <> archive/latest/33306
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 17 Jan 2017, at 18:16, Scott Mitchell <> wrote:
> Thanks for responses everyone. There seems to be recognition that the specification lacks clarity but there also seems to be momentum behind "Option 1".
> This leads to the practical concern of bounding the amount of memory committed to streams in this state. SETTINGS_MAX_CONCURRENT_STREAMS limits number of streams in "open" or "half-closed", but the specification doesn't (to my knowledge) define a way to limit the number of "reserved" streams or "idle"/"closed" streams which have had only PRIORITY frames exchanged. The specification allows for implementations to discard PRIORITY more or less at their discretion [3], but limiting "reserved" streams is another issue. "SETTINGS_ENABLE_PUSH" is limited to 0 or 1 [4] so there is no way for a client to advertise how many "reserved" streams it is willing to accept. What are the practical approaches folks have taken to address these issues?
> [3] <>
> > The retention of priority information for streams that are not counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a large state burden for an endpoint. Therefore, the amount of prioritization state that is retained MAY be limited.
> [4] <>
> > The initial value is 1, which indicates that server push is permitted.  Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 <>) of type PROTOCOL_ERROR.

SETTINGS_MAX_CONCURRENT_STREAMS is used to limit the number of pushed streams.

The key thing to understand is that there are *two* values of SETTINGS_MAX_CONCURRENT_STREAMS on each connection: one set by the client and one set by the server. The one set by the server limits the number of client-initiated streams there may be (that is, streams initiated by HEADERS frames). The one set by the client limits the number of server-initiated streams there may be (that is, streams initiated by PUSH_PROMISE frames).

This is laid out explicitly in RFC 7540 Section 8.2.2:

> A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
> the number of responses that can be concurrently pushed by a server.
> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
> server push by preventing the server from creating the necessary
> streams.  This does not prohibit a server from sending PUSH_PROMISE
> frames; clients need to reset any promised streams that are not
> wanted.