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

James M Snell <> Thu, 25 April 2013 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2B8F21F94B1 for <>; Thu, 25 Apr 2013 12:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.545
X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VhEPFR9BpIH3 for <>; Thu, 25 Apr 2013 12:34:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1F67321F91B2 for <>; Thu, 25 Apr 2013 12:34:49 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVRwA-0007qr-W6 for; Thu, 25 Apr 2013 19:34:35 +0000
Resent-Date: Thu, 25 Apr 2013 19:34:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVRw2-0007pH-DW for; Thu, 25 Apr 2013 19:34:26 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVRvx-0007QQ-FI for; Thu, 25 Apr 2013 19:34:26 +0000
Received: by with SMTP id eh20so2893599obb.29 for <>; Thu, 25 Apr 2013 12:33:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cY2nY35c/qbFbWspC2UGa8z3m4xdqEkYaaqHQ2nQk88=; b=xU+mtk/CYdSWUQRtA4s4I4v03O3qjqah+jJkWZXwdECpnstWioFHBX4xM/2MQWm1RB ZTXzr52mBZo/y5vCwjjpxJWwCaO/WK/qVH5Y6825QbRLYItWbVsxLYC4pFJlQUlXlvxD 4fqZOys7YejHZuoAz4fAEFtTqmPj+dnz9npO+rVCswpZwd931mO3eTfWKEd4yxS07FLZ uQGJgBiYVjLLdtxX/+cleSMRMjA3zstFbHbNEFZAIpY8YV42No071z1WyQNrrq2l/eJ2 8Yd4lR1+rXILNvg1Lr1wvpWbt7ttqRVfNpC5TpbqjDUuk5ysg4fbOIAduTc/1FLW/ONE ag8w==
X-Received: by with SMTP id cj9mr16403576oeb.31.1366918435512; Thu, 25 Apr 2013 12:33:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 25 Apr 2013 12:33:35 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: James M Snell <>
Date: Thu, 25 Apr 2013 12:33:35 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.652, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UVRvx-0007QQ-FI f651856b4560c7944101a186ce4718f6
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17575
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Perhaps a simpler approach would be to just redefine the limit such
that an endpoint MUST NOT have more than MAX_CONCURRENT_STREAMS in the
Open state at any given time. We have already established that once
the stream is half-closed, new frames cannot be sent, so once the
server half-closes a steam it initiates, the counter is decremented
and the server is permitted to initiate another stream. The client can
choose to reject those additional streams if it chooses.

On Thu, Apr 25, 2013 at 12:25 PM, Martin Thomson
<> wrote:
> On 25 April 2013 10:50, James M Snell <> wrote:
>> If a client sets a limit of 4 concurrent streams, and the server
>> initiates 4 separate PUSH_PROMISE streams that the server half-closes
>> but that are never half-closed by the client, the server will not be
>> able to initiate new push streams for the duration of the session.
> Yep, it's a problem.  We got rid of the unidirectional flag that
> addressed this.  I can't speak for others, but I was aware of the
> issue at the time, but I had a solution in mind.  That never got
> written down, partly because we didn't have this discussion :)
> On first blush, the only way to avoid the problem is to expect the
> framing layer to be aware of what is going on above, but that's
> probably not sensible.  But there's a better way:
> Each stream has two separate state variables, each with three state
> values: no packet yet, open, half-closed.  Streams that have inbound
> == open || outbound == open are "in use" and count toward the stream
> limit.  Documenting this might help clarify how the accounting is
> done.
> Importantly, this means that promised streams do not count toward the
> limit.  It does however also imply that implementations will need to
> be careful about how they allocate stream resources.  Pushes
> complicate that a little because the lifecycle of headers doesn't
> match stream lifecycles.  Again, I'd suggest an approach where
> implementations defer commitment of flow control buffers until the
> first flow-controlled frame arrives (memory pre-allocation might be
> advisable for performance reasons, but that would not be an actual
> commitment) and to ensure that any state for send and receive don't
> have the same lifecycle.