Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

James M Snell <> Mon, 29 April 2013 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 456AA21F9A68 for <>; Mon, 29 Apr 2013 11:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hs4OjqYxtcuj for <>; Mon, 29 Apr 2013 11:47:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 02A3A21F9A56 for <>; Mon, 29 Apr 2013 11:47:44 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UWt6W-0001W0-IH for; Mon, 29 Apr 2013 18:47:12 +0000
Resent-Date: Mon, 29 Apr 2013 18:47:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UWt6N-0001UV-By for; Mon, 29 Apr 2013 18:47:03 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UWt6M-0006S1-7n for; Mon, 29 Apr 2013 18:47:03 +0000
Received: by with SMTP id ef5so5842287obb.36 for <>; Mon, 29 Apr 2013 11:46:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4S7nAYFyX2krzdPa7d0AgHPpAXE091ATDFupU8+nz4A=; b=yhh2COb/VMLHD4f1JImQfuEwOM4GL0de8D67vM98Qas76lebvqnwX9FZU6fn721R01 1dS9CvU2Qdx7bwMjiVUzNPQ7Gn4Wjb0tng+DxLRoW4wc6zQbfxAtCrzapAbpCZ0ePBfj KK/Tn9KjgbLt+AQkv6vDdzJJIA1nn3DclrLRa5jphm0Ucckc5AFoYXCYjt2dINqipHIm QNrPsNSjhmOpjRyPZLIgaD87LtFAhOMyDUjpo1IBv4eMdCqLb7hjNG2N2sdfL21nCuE2 m92oQvlKYPfzQ3wjRCdfeywWVvrtrzNdN/oq3UrL3ZLRBeCp/+q8i08TraCjbYj3+Vtm 9m+w==
MIME-Version: 1.0
X-Received: by with SMTP id d5mr14877828obf.43.1367261196215; Mon, 29 Apr 2013 11:46:36 -0700 (PDT)
Received: by with HTTP; Mon, 29 Apr 2013 11:46:35 -0700 (PDT)
Received: by with HTTP; Mon, 29 Apr 2013 11:46:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 29 Apr 2013 11:46:35 -0700
Message-ID: <>
From: James M Snell <>
To: "ChanWilliam(陈智昌)" <>
Cc:, Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a11c2ef86ea6ff004db844d76"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.750, BAYES_00=-1.9, 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: 1UWt6M-0006S1-7n 1764db897e8e923a902da55c8d97fa8d
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17668
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Apr 29, 2013 11:36 AM, "William Chan (陈智昌)" <>
> Oops, forgot about that. See, the issue with that is now we've made
PUSH_PROMISE as potentially expensive as a HEADERS frame, since it does
more than just simple stream id allocation. I guess it's not really a huge
issue, since if it's used correctly (in the matter you described), then it
shouldn't be too expensive. If clients attempt to abuse it, then servers
should probably treat it in a similar manner as they treat people trying to
abuse header compression in all other frames with the header block, and
kill the connection accordingly.

Not just "potentially" as expensive..   As soon as we get a push promise we
need to allocate state and hold onto it for an indefinite period of time.
We do not yet know exactly when that compression context can be let go
because it has not yet been bound to stream state.  Do push streams all
share the same compression state? Do those share the same compression state
as the originating stream? The answers might be obvious but they haven't
yet been written down.

>> > As far as the potential problem above, the root problem is that when
>> > have limits you can have hangs. We see this all the time today with
>> > (it's only reason people do domain sharding so they can bypass
limits). I'm
>> > not sure I see the value of introducing the new proposed limits. They
>> > solve the hangs, and I don't think the granularity addresses any of the
>> > costs in a finer grained manner. I'd like to hear clarification on what
>> > costs the new proposed limits will address.
>> I don't believe that the proposal improves the situation enough (or at
>> all) to justify the additional complexity.  That's something that you
>> need to assess for yourself.  This proposal provides more granular
>> control, but it doesn't address the core problem, which is that you
>> and I can only observe each other actions after some delay, which
>> means that we can't coordinate those actions perfectly.  Nor can be
>> build a perfect model of the other upon which to observe and act upon.
>>  The usual protocol issue.
> OK then. My proposal is to add a new limit for PUSH_PROMISE frames
though, separately from the MAX_CONCURRENT_STREAMS limit, since
PUSH_PROMISE exists as a promise to create a stream, explicitly so we don't
have to count it toward the existing MAX_CONCURRENT_STREAMS limit (I
searched the spec and this seems to be inadequately specced). Roberto and I
discussed that before and may have written an email somewhere in spdy-dev@,
but I don't think we've ever raised it here.

Well,  there is an issue tracking it in the github repo now, at least.  As
currently defined in the spec,  it definitely needs to be addressed.