Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

James M Snell <> Thu, 25 April 2013 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 774DC21F967F for <>; Thu, 25 Apr 2013 10:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.537
X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10Ga+eiHS-Zt for <>; Thu, 25 Apr 2013 10:54:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4D82C21F9692 for <>; Thu, 25 Apr 2013 10:54:01 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVQKf-0001HS-C9 for; Thu, 25 Apr 2013 17:51:45 +0000
Resent-Date: Thu, 25 Apr 2013 17:51:45 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVQKU-0001Gi-GZ for; Thu, 25 Apr 2013 17:51:34 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVQKQ-00036g-2e for; Thu, 25 Apr 2013 17:51:34 +0000
Received: by with SMTP id uk5so2798824obc.11 for <>; Thu, 25 Apr 2013 10:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=4pSEaX7B0DgcFnshGIU0rPubEbFU8y57k2aezk5Wt0I=; b=UI3psfG5DMLpsrhBCHF4ByVbkmEtYp9gDgl1FOCHUqLP8rlsBFze09lROKNUsm3LEn /L/HGEmcRRKer1AoNYtQ/GlwWSQETSJN9EgMHQunNlI94PQo0Y9zQXgz8JcmmFL0orLu LhFIGRg/SqWUw9t0V15H8CtSAIX8F0JsOOeaxnxryqKrXneUxpLVedRiTd3yK83L6RA/ VCCI6DgGHUBOeZpQw9EbIKfbd0wm1jCNx/b1x6v1LmrTwL+0aRA/D2Y+XO/+ZJoVZiHB 6NpAGOXoIz+pyH8cVCjUiA+zn0vf6BJfFCvT0iL+5V6hC6S5vBVKeCsWVUVOJwGaxfHp OV9w==
X-Received: by with SMTP id b20mr1631846oen.135.1366912264064; Thu, 25 Apr 2013 10:51:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 25 Apr 2013 10:50:44 -0700 (PDT)
From: James M Snell <>
Date: Thu, 25 Apr 2013 10:50:44 -0700
Message-ID: <>
To: "" <>
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.682, 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: 1UVQKQ-00036g-2e 2927f5d5e23dc54d89a2139997a66e6f
Subject: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17566
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

In the current draft (-02), we state that:

A. Any endpoint can initiate and half-close a fully unidirectional
stream that does not require any action or acknowledgement from the
receiving peer. Once half-closed, these remain in a constant
half-closed state with the receiving peer having the option of sending
frames for that stream at any time for the full duration of the

B. An endpoint MUST NOT exceed the maximum concurrent streams limit
set by it's peer and that streams initiated by the endpoint that are
half-closed in any direction count towards this limit.

C. Unless I missed it somewhere, clients are never required to
half-close PUSH_PROMISE streams.

The potential problem here is simple:

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.