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

James M Snell <jasnell@gmail.com> Mon, 29 April 2013 21:00 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 9787521F9B9B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 14:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.373
X-Spam-Level:
X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 sgf3CoT67wcN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 14:00:52 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 390C721F9B94 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 14:00:52 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWvAW-0006xb-So for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 20:59:28 +0000
Resent-Date: Mon, 29 Apr 2013 20:59:28 +0000
Resent-Message-Id: <E1UWvAW-0006xb-So@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 1UWvAN-0006wr-Ht for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 20:59:19 +0000
Received: from mail-ob0-f181.google.com ([209.85.214.181]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UWvAM-0004aF-JA for ietf-http-wg@w3.org; Mon, 29 Apr 2013 20:59:19 +0000
Received: by mail-ob0-f181.google.com with SMTP id ta17so5780536obb.40 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 13:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4AqR3GfAAaH2E4RSvX2HNe8j+slzyzIKvfxfkBRfxss=; b=e6azb7FEc+eQxOHRakU1Vzu2H3o2fc/D7i94aPFZI5M2aySMlgLtKAZIYM+kVlqsQ6 Z5jAqaIbqZx+lA2PeoNEVhEWisoqLqaZL5FPI4e0x8qqZA3cju5dNGMLbK9PMm150PKn +id7otPaUwe7g67uBUjOTURVxlR7DaQGHqyKVJtQGIjRAQHf+JOdUXrTQZJzRFZYH6KN 64K7v0Enoryxlbf73tXdsXp+3NiYwC3/8yVdf304zQ2TCi3IhK9zbdXLpOZv8Y9Et9ct nadTdP0cETHImwB65s7F+aYswpJl76IeeWyna2wZdgk806Y2FqUO6s8AinAt8W2bDYJE 9sYg==
MIME-Version: 1.0
X-Received: by 10.182.14.39 with SMTP id m7mr28580175obc.96.1367269132646; Mon, 29 Apr 2013 13:58:52 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Mon, 29 Apr 2013 13:58:52 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Mon, 29 Apr 2013 13:58:52 -0700 (PDT)
In-Reply-To: <CAA4WUYhF6rAZoYEaz4aJO6xawaJxzxGt=Bkg4H9eBOP-LBSRmQ@mail.gmail.com>
References: <CABP7RbdBe-Xkx+CMvpN=_oNAqm6SyLyL+XNHRUKSqn8mjSDw1Q@mail.gmail.com> <CAA4WUYgCiyWerT0tUUVKcbNPqdTGuXHd_MG59DjcUsEWst5t7g@mail.gmail.com> <CABkgnnVdU=cZ53Bqg5Un=E80NMpcgYO37DVmwUFW0O-i7SNf8w@mail.gmail.com> <CAA4WUYhz64FsEGgGhx91RfWwuPPxWdAkesOV-bmqWVWE7ZxdjA@mail.gmail.com> <CABP7RbcKQkn1o4WZscwNmSmm6YzqE_TKxPr4jnozNdaVqpZ7=A@mail.gmail.com> <CAA4WUYhF6rAZoYEaz4aJO6xawaJxzxGt=Bkg4H9eBOP-LBSRmQ@mail.gmail.com>
Date: Mon, 29 Apr 2013 13:58:52 -0700
Message-ID: <CABP7RbdjRWxJeMZeeq_8Zknfe1VgLTqFf_X=4RbeCfnRUPfNtQ@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
To: =?UTF-8?B?Q2hhbldpbGxpYW0o6ZmI5pm65piMKQ==?= <willchan@chromium.org>
Cc: ietf-http-wg@w3.org, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=14dae9399ad1f6c08d04db8626bf
Received-SPF: pass client-ip=209.85.214.181; envelope-from=jasnell@gmail.com; helo=mail-ob0-f181.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.674, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UWvAM-0004aF-JA fec0ad7d0c19f642e4d7f6cb6cd70ffa
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/CABP7RbdjRWxJeMZeeq_8Zknfe1VgLTqFf_X=4RbeCfnRUPfNtQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17676
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>

On Apr 29, 2013 12:33 PM, "William Chan (陈智昌)" <willchan@chromium.org>;
wrote:
>
[snip]
>
> I guess I don't see per-stream state as being that expensive. Compression
contexts are a fixed state on a per-connection basis, meaning that
additional streams don't add to that state. The main cost, as I see it, is
the decompressed headers. I said potentially since that basically only
means the URL (unless there are other headers important for caching due to
Vary), and additional headers can come in the HEADERS frame. Also,
PUSH_PROMISE doesn't require allocating other state, like backend/DB
connections, if you only want to be able to handle
(#MAX_CONCURRENT_STREAMs) of those backend connections in parallel.
>
> If they're not specified, then we should specify it, but I've always
understood the header compression contexts to be directional and apply to
all frames sending headers in a direction. Therefore there should be two
compression contexts in a connection, one for header blocks being sent and
one for header blocks being received. If this is controversial, let's fork
a thread and discuss it.
>

I think we all have been working off that basic assumption but, again, it
hasn't been written down. I'll gladly take that to do...  Doing so would
help us to evaluate the proposals on the table so far...  In a separate
thread tho.

Regarding the original issue for this thread,  MAX_CONCURRENT_STREAMS as
currently defined, is simply not workable with pushed streams because of
the half closed issue.  There are several ways to address the problem,  we
just need to identify and pick one. I don't particularly care which one we
choose :-)

- James

>>
>> >>
>> >>
>> >> > As far as the potential problem above, the root problem is that
when you
>> >> > have limits you can have hangs. We see this all the time today with
browsers
>> >> > (it's only reason people do domain sharding so they can bypass
limits). I'm
>> >> > not sure I see the value of introducing the new proposed limits.
They don't
>> >> > solve the hangs, and I don't think the granularity addresses any of
the
>> >> > costs in a finer grained manner. I'd like to hear clarification on
what
>> >> > costs the new proposed limits will address.
>> >>
>> >> I don't believe that the proposal improves the situation enough (or at
>> >> all) to justify the additional complexity.  That's something that you
>> >> need to assess for yourself.  This proposal provides more granular
>> >> control, but it doesn't address the core problem, which is that you
>> >> and I can only observe each other actions after some delay, which
>> >> means that we can't coordinate those actions perfectly.  Nor can be
>> >> build a perfect model of the other upon which to observe and act upon.
>> >>  The usual protocol issue.
>> >
>> >
>> > OK then. My proposal is to add a new limit for PUSH_PROMISE frames
though, separately from the MAX_CONCURRENT_STREAMS limit, since
PUSH_PROMISE exists as a promise to create a stream, explicitly so we don't
have to count it toward the existing MAX_CONCURRENT_STREAMS limit (I
searched the spec and this seems to be inadequately specced). Roberto and I
discussed that before and may have written an email somewhere in spdy-dev@,
but I don't think we've ever raised it here.
>> >
>>
>> Well,  there is an issue tracking it in the github repo now, at least.
As currently defined in the spec,  it definitely needs to be addressed.
>
> Great. You guys are way better than I am about tracking all known issues.
I just have it mapped fuzzily in my head :)