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

James M Snell <> Fri, 03 May 2013 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2798C21F96B6 for <>; Fri, 3 May 2013 10:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D+jKpF4JCB8H for <>; Fri, 3 May 2013 10:41:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 824F721F8FE3 for <>; Fri, 3 May 2013 10:36:41 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UYJuI-00078a-Vb for; Fri, 03 May 2013 17:36:31 +0000
Resent-Date: Fri, 03 May 2013 17:36:30 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UYJu9-00077l-1C for; Fri, 03 May 2013 17:36:21 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UYJu8-00042g-6D for; Fri, 03 May 2013 17:36:20 +0000
Received: by with SMTP id j1so1868522oag.41 for <>; Fri, 03 May 2013 10:35:54 -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:content-transfer-encoding; bh=yAZ0Tw3Yob0MJlwYy8jsVVRkRpmCAp3DjDMhhM1xSLE=; b=lQEbIbTG1MDUqEE0iyeEprlmRR0vhKVKY2sVa/boCyqYQsTkx798UHzjbChA90eOMy 76PKdtoL2/IrNyNthKMmTHVRAHhE9yPnZtlE+fzxuASa3sSP/NNKHo/T21kcGWvG9vQt W6D+FpZolJJe4GDio1C3fHF61sCFJpEsYnGtMQxXdj8B5uHoHzj6vxC075QWCubvqUlD Cd87+RWKayp56/itNCtN0PtYdUshU2gR1l9emxOj50YlOyo8pkNJgse7P0EkhgRO42ed ufay7MgVSD2EWbQrZZwXHAudFei0DcWLH2263RtG+QXiNDqOPSuOQhCaFBZr3eXrjkKg VMeQ==
X-Received: by with SMTP id e5mr484353oed.46.1367602554161; Fri, 03 May 2013 10:35:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 May 2013 10:35:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: James M Snell <>
Date: Fri, 03 May 2013 10:35:34 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: "William Chan (陈智昌)" <>, Roberto Peon <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.701, 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: 1UYJu8-00042g-6D 811a275436325fb70451c6e2e07c0cbc
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17802
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, May 3, 2013 at 9:52 AM, Martin Thomson <> wrote:
> On 3 May 2013 09:44, William Chan (陈智昌) <> wrote:
>> I'd like server folks to chime in, but doing this makes me feel a bit
>> nervous. I feel this effectively disables the directional concurrent streams
>> limit. The bidirectional full-close essentially acts like an ACK, so
>> removing it might result in an unbounded number of streams.
> I think that I know what you mean here, but can you try to expand a
> little?  Do you refer to the possible gap between close on the
> initiating direction and the first frame on the responding direction;
> a gap that might cause the stream to escape accounting?  I think that
> is a tractable problem - any unbounded-ness is under the control of
> the initiating peer.

Well, there are really several issues here...

1. The server endpoint would be allowed to initiate an unbounded
number of push streams, up to MAX_CONCURRENT_STREAMS at any given
time, but with no reasonable upper limit on the overall total number
of streams. For instance, given a MAX_CONCURRENT_STREAMS of 10, it
could initiate 10 streams and close them, initiate 10 more and close
those, initiate 10 more.. ad infinitum. Generally speaking, I don't
believe this is really a serious issue, however. The receiving end can
simply opt to reject pushed streams from misbehaving servers once a
particular threshold was reached (which is where I was going with the
credit limit proposal before).

2. There may be (as you suggest) a gap of time between when the server
sends it's FINAL frame on a pushed stream and the time when a client
might send it's FINAL (if any FINAL frame comes at all). Here, again,
however, the MAX_CONCURRENT_STREAMS bounds the total number of open
streams the server can push at any given time and the client can opt
to reject additional streams if the flow becomes unmanageable.

Modeling this out, I believe that clients will definitely have to
implement some protections against abuse but those protections do not
need to be standardized. Clients would simply implement whatever
algorithm they wish to determine whether or not to accept new pushed
streams. MAX_CONCURRENT_STREAMS would cover only streams that are
initiated by and opened for the sending peer. If a peer closes it's
side, it decrements the counter for that peer. Half-open streams in
the other direction would not count. A receiving peer that is dealing
with a misbehaving endpoint can use RST_STREAM to refuse new pushes or
send a SETTINGS with a new, more restrictive MAX_CONCURRENT_STREAMS

Btw... Another possible dimension we could consider is a new
RST_STREAM error code indicating that a stream is being rejected
because too many streams are being opened too quickly.

- James