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

James M Snell <> Mon, 29 April 2013 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB93021F9968 for <>; Mon, 29 Apr 2013 14:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.534
X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bjQ4NCSkH+Cj for <>; Mon, 29 Apr 2013 14:31:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 19B4321F9965 for <>; Mon, 29 Apr 2013 14:31:31 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UWvf3-0002gf-6q for; Mon, 29 Apr 2013 21:31:01 +0000
Resent-Date: Mon, 29 Apr 2013 21:31:01 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UWvet-0002fv-89 for; Mon, 29 Apr 2013 21:30:51 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UWves-0005Yd-3P for; Mon, 29 Apr 2013 21:30:51 +0000
Received: by with SMTP id oi10so5787782obb.24 for <>; Mon, 29 Apr 2013 14:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aNYUS3MXqBtxP2QkdhEMeePpe1uL2mAfACC4Ttl/Z0I=; b=FF6rxopp6mydJ3dbbtTna5nCaDv2Waf1xLODDOS1sM9yMfj8O/RIXwPi1cbaaZ4jDT fKe9K6ycVMoaapKSJ9Uhm+sSRXj/LhGqzGTljXzV77JnkPh3JxFol1D1woWyCNb/D0SX x14W+4fiSV3bVW9WSAHW3JHI0Qh/bwhisIgFzaCJwHGKXfceNeqB4rwDJxtjHsaArOL8 kwpfnD5/k+MORNpi5JrqYu1hphmGL+vrxFZfw1ydgfZ0drMSHh5UIfrkb3PKtRAaj98N 5t5wQK23e6rRl0THZ4MB6099lHO+yeKURR7PoHl7o9pfa5UZBTZGoDQkMBq70L3bfImx f11w==
MIME-Version: 1.0
X-Received: by with SMTP id n10mr29966917oew.63.1367271024033; Mon, 29 Apr 2013 14:30:24 -0700 (PDT)
Received: by with HTTP; Mon, 29 Apr 2013 14:30:23 -0700 (PDT)
Received: by with HTTP; Mon, 29 Apr 2013 14:30:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 29 Apr 2013 14:30:23 -0700
Message-ID: <>
From: James M Snell <>
To: Martin Thomson <>
Cc: "ChanWilliam(陈智昌)" <>,
Content-Type: multipart/alternative; boundary="047d7b33d4bab3079504db869709"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.636, 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: 1UWves-0005Yd-3P 82c592bb7d1011878d8fb936ff7a9896
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17681
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Oh,  and fwiw, I'm basing this on how things are captured in the spec, not
necessarily how it's actually implemented anywhere.  It may not be a
problem in in running code,  but as written there could be issues.  The
fact that push stream open is tied to originating stream state,  for
instance, is not nearly as obvious in the text as it could be.  The fact
that closing the origin stream causes pushed streams to full close,
thereby decrementing the concurrent stream counter,  is not obvious in the
current text. Perhaps it's just an editorial issue masquerading as a design
issue, but my gut is telling me that placing hard limits on push is going
to be problematic.  I'm liking Roberto's approach more the more I think
about it.
On Apr 29, 2013 2:08 PM, "James M Snell" <> wrote:

> It does not attempt to solve the core problem completely.  If anything it
> just pushes it down the road a bit.  As currently defined,  servers will
> top out quickly on the number of streams they can push.  With the revised
> scheme I proposed, we would give the recipient more control over the
> decision making process. A server will run up to the limits just as fast,
> but the recipient could allow the server to keep right on going if it
> wishes. In other words,  less coordination required between the endpoints.
> On Apr 29, 2013 11:20 AM, "Martin Thomson" <>
> wrote:
> [snip]
> >
> > 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.