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

James M Snell <> Thu, 25 April 2013 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D781721F973B for <>; Thu, 25 Apr 2013 16:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.274
X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IP9g2JiCP9Fj for <>; Thu, 25 Apr 2013 16:46:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 310A321F970F for <>; Thu, 25 Apr 2013 16:46:56 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVVrP-00069w-Gn for; Thu, 25 Apr 2013 23:45:55 +0000
Resent-Date: Thu, 25 Apr 2013 23:45:55 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVVrK-00068J-Tx for; Thu, 25 Apr 2013 23:45:50 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVVrK-0007jI-91 for; Thu, 25 Apr 2013 23:45:50 +0000
Received: by with SMTP id 16so3043126obc.37 for <>; Thu, 25 Apr 2013 16:45:24 -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=wdWiG6aJ9X/iUPGcJYKKL3bur2EmlGVTeFKKM1AhJNE=; b=RNEW+6cTo3vnRiGt1FyLj5X6vZ7b9P/7H53JdmZ5pGyjgD1azBXtXggPV6pSY1zCua 07865dfKLACnM6RcaxulXYjiN85WnsJiXFpdElwb0MihO6OW84ZG3AzaJNiM4aAbR6JW n6GZofuNRI/Ve0pnuNbTF/LCJIE15RpJX8e/B+jTi71p/G5fx97EfyX/zrBCozarK9cZ ZGtZEgRMtW3rPXZV+HhryKt10iDVXS3wvF7BWaMEBNJWevZAJ9oo4YK5tziqA6TPbaQI DcYbdT9vx8EK7xRKAECIhYOvUYHYOLl2xxSmG7CXjRwzP/VdX6M5UYwU5bwAWCkuDjND OVRA==
X-Received: by with SMTP id b20mr2339304oen.135.1366933524345; Thu, 25 Apr 2013 16:45:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 25 Apr 2013 16:45:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: James M Snell <>
Date: Thu, 25 Apr 2013 16:45:04 -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=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.718, 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: 1UVVrK-0007jI-91 7262d52f2478503659d5b746d9f46e13
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17586
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Yes, it does become a bit tricky here. Not quite sure exactly what the
solution ought to be. One possible approach would be for the
intermediary to use flow-control mechanisms to effectively rate limit
the clients requests. For instance, if the intermediary allows the
client to open 10 concurrent streams, and the client opens and
half-closes those streams at too high of a rate without giving the
server time to properly respond, the intermediary can hold new streams
for a period of time or reject the new streams until the server
catches up.

Alternatively, a secondary MAX_OPEN_STREAMS parameter can be used. The
sender would be limited to initiating no more than
MAX_CONCURRENT_STREAMS open outbound streams at any given time and
would be allowed to initiate new streams after half-closing; however,
all open and half-open streams would count against the separate
MAX_OPEN_STREAMS limit. If that limit has not been hit, the newly
initiated streams are accepted, otherwise they are either held or
rejected until the half-open streams are closed. The assumption is

Yes, with low MAX_OPEN_STREAMS values we still run the risk of
starving out pushed streams, so the idea would be to use
MAX_OPEN_STREAMS intelligently (and possibly allow the value to change
dynamically through the life of a session) so that we avoid the issue.

These, of course, aren't the only possibilities :-)

- James

On Thu, Apr 25, 2013 at 4:18 PM, Martin Thomson
<> wrote:
>> On Thu, Apr 25, 2013 at 4:11 PM, Martin Thomson
>> <> wrote:
>>> Do you mean that only outward bound streams count toward the
>>> concurrency limit.  That could be workable; it's certainly easier to
>>> explain.
> On 25 April 2013 16:13, James M Snell <> wrote:
>> Yes, Outward bound only.
> This has the biggest impact on servers and intermediaries.  How do
> they feel about having clients initiating more requests while the
> server is sending responses.
> Thinking on this more, it does add an interesting pipelining-like
> problem.  If all I'm doing is sending GET requests, then I can
> probably open up thousands of streams, but the server can only respond
> to a limited subset of those requests, holding requests (or responses)
> in waiting until the response logjam frees up.  I think that this is
> an undesirable property of the solution.  (MAX_CONCURRENT_STREAMS
> could then look very much like HTTP/1.1 with pipelining.)