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

Martin Thomson <> Thu, 25 April 2013 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F5B321F96BA for <>; Thu, 25 Apr 2013 12:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ySxrKrHXs2E3 for <>; Thu, 25 Apr 2013 12:26:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7917921F9659 for <>; Thu, 25 Apr 2013 12:26:33 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVRo4-0002eq-8Z for; Thu, 25 Apr 2013 19:26:12 +0000
Resent-Date: Thu, 25 Apr 2013 19:26:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVRnz-0002eA-Kg for; Thu, 25 Apr 2013 19:26:07 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVRnv-0007TD-2a for; Thu, 25 Apr 2013 19:26:07 +0000
Received: by with SMTP id m1so2918496wea.40 for <>; Thu, 25 Apr 2013 12:25:37 -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=vJ10L6rg2S3BdYtk5kmeKr7YLAhmvb0Pm9gyZ2pBxoU=; b=KVfMW2lJwXLorBwQMeNwcyAoJsqTqilYZP5gjksqjGWQ45iLDT7Aldp9GrQYYoa7OJ uS3SRy2N7wwJX0pnOIEM48li3iHPsV2JTzrqqxYh7swJaUkXOvc7YvW9+83J2/ABq9cD 4j29zS9tAKUjfvSwjLQeBpa8V8/vfKkLfXZVbvvEnEh/5HXuSDOeOMg6PrVeEPOxXAJ2 62neGqjdanBSAB/jlbJaqfgNDfxr0U1MlskEv7w4qnR7aaUBf4SB29DP/QaQ8Qkdyjha RiemnxT2AWi9dPZtDYEJXiqKp12o4aAgUcFK425185DmeT3FKi9NeAI8QmUOpItbHWwZ jBrA==
MIME-Version: 1.0
X-Received: by with SMTP id uo4mr5902612wjc.30.1366917936924; Thu, 25 Apr 2013 12:25:36 -0700 (PDT)
Received: by with HTTP; Thu, 25 Apr 2013 12:25:36 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 25 Apr 2013 12:25:36 -0700
Message-ID: <>
From: Martin Thomson <>
To: James M Snell <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.730, BAYES_00=-1.9, 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: 1UVRnv-0007TD-2a 29321d9ab3bdea8dfc70c7e147a2d3cf
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17573
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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.