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

James M Snell <jasnell@gmail.com> Thu, 25 April 2013 23:46 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D781721F973B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 16:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.274
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP9g2JiCP9Fj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 16:46:56 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 310A321F970F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 16:46:56 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVVrP-00069w-Gn for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Apr 2013 23:45:55 +0000
Resent-Date: Thu, 25 Apr 2013 23:45:55 +0000
Resent-Message-Id: <E1UVVrP-00069w-Gn@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UVVrK-00068J-Tx for ietf-http-wg@listhub.w3.org; Thu, 25 Apr 2013 23:45:50 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UVVrK-0007jI-91 for ietf-http-wg@w3.org; Thu, 25 Apr 2013 23:45:50 +0000
Received: by mail-ob0-f178.google.com with SMTP id 16so3043126obc.37 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 16:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.60.47.84 with SMTP id b20mr2339304oen.135.1366933524345; Thu, 25 Apr 2013 16:45:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Thu, 25 Apr 2013 16:45:04 -0700 (PDT)
In-Reply-To: <CABkgnnXrku1B8ehWWeCCaWBeTfhsWGTagHTKbA3F_HYe0Fux0Q@mail.gmail.com>
References: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com> <CABkgnnW=Ve=9p2do5PncTVswTYCZqt-LMK50SYCKV1r8zEg=SQ@mail.gmail.com> <CABP7Rbc=hYTxuGm7jn=eDipbA23UW3MUc_jx2ALHfqHQt94OJg@mail.gmail.com> <CABkgnnVoHv+Wf=oYN=RSq2GHod-KrZ5gPq-gYmNvcRpMWFjNEQ@mail.gmail.com> <CABP7RbdH+YnH2V8HX=1YzrT-m06ggdXNGqvEMwng2nDv5AeXXg@mail.gmail.com> <CABkgnnXrku1B8ehWWeCCaWBeTfhsWGTagHTKbA3F_HYe0Fux0Q@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Thu, 25 Apr 2013 16:45:04 -0700
Message-ID: <CABP7Rbc49-VPGggp3auHCRDKCc6BYfTwO2pZzg68Kfgi_VQdCg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.214.178; envelope-from=jasnell@gmail.com; helo=mail-ob0-f178.google.com
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: maggie.w3.org 1UVVrK-0007jI-91 7262d52f2478503659d5b746d9f46e13
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <http://www.w3.org/mid/CABP7Rbc49-VPGggp3auHCRDKCc6BYfTwO2pZzg68Kfgi_VQdCg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17586
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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
that MAX_OPEN_STREAMS >= MAX_CONCURRENT_STREAMS.

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
<martin.thomson@gmail.com>; wrote:
>> On Thu, Apr 25, 2013 at 4:11 PM, Martin Thomson
>> <martin.thomson@gmail.com>; 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 <jasnell@gmail.com>; 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.)