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

Martin Thomson <> Mon, 29 April 2013 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1DFA21F9AAA for <>; Mon, 29 Apr 2013 11:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.186
X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=4.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ui8fE+JSnnNn for <>; Mon, 29 Apr 2013 11:22:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CEB721F9AB9 for <>; Mon, 29 Apr 2013 11:22:06 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UWshO-0004Hk-1J for; Mon, 29 Apr 2013 18:21:14 +0000
Resent-Date: Mon, 29 Apr 2013 18:21:14 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UWshI-0004H0-FX for; Mon, 29 Apr 2013 18:21:08 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UWshH-0005OC-Fs for; Mon, 29 Apr 2013 18:21:08 +0000
Received: by with SMTP id s43so5711253wey.27 for <>; Mon, 29 Apr 2013 11:20:41 -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:content-transfer-encoding; bh=O+u7xMlA8GefhA1C8lM8lwa6yRLOPctIZkBujieqwiM=; b=mrAHsxsEDjkdw1n641dedswfWOCtSk28e0VXQ3VpVlHzx0KzlOTeKyQO37zCwZiE2Q ytnedHf2GnzJ/2ipjVTI0dZHOaN2Je4AXzrQYJalYJClJ/ePgCY0fs9Rqwb8qBgCKmVe 8jYKorLfWhiMdhWJAMSs2RqrP/X842j9cAWj08a9RncfiV7zxlFBWMYPhZXoYmNHjngZ fXOto46Q1L7Vt/E5wUHHHIFKLfk6T+b9hmrBiG/rSJvsGa4swv10mMW7+NQnXamPyBA1 6LPw7WXq9F0sNg2X25ot8YP7oxjOR2G1hem3Xn74hF/EhLW5FG5mtNnnHWd+qbLbK2za zskg==
MIME-Version: 1.0
X-Received: by with SMTP id gf9mr9772420wic.32.1367259641141; Mon, 29 Apr 2013 11:20:41 -0700 (PDT)
Received: by with HTTP; Mon, 29 Apr 2013 11:20:41 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 29 Apr 2013 11:20:41 -0700
Message-ID: <>
From: Martin Thomson <>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
Cc: James M Snell <>, "" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.733, 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: 1UWshH-0005OC-Fs a62a5129cb9fece0acf1cd192eebc0b3
Subject: Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams
Archived-At: <>
X-Mailing-List: <> archive/latest/17666
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 29 April 2013 10:40, William Chan (陈智昌) <> wrote:
> I read this entire thread and don't really see the problem we want to solve.
> Can someone clarify? Let me reviewe the paint points as I understand them:
> * Stream data buffers are expensive - flow control solves this

s/solves/mitigates/  - they aren't free

> * Stream headers are potentially expensive - MAX_CONCURRENT_STREAMS
> mitigates this, although I'm not entirely convinced this is a complete
> solution, especially when you can keep adding HEADERS for a stream without
> bound (headers are problematic since you have to process them due to the
> shared compression context).

MAX_CONCURRENT_STREAMS also helps with the buffer size problem.

> * Stream ids are cheap. They're ids and don't require much context.
> Historically PUSH_PROMISEs were cheap, but now that they can carry header
> blocks, we've regressed on that. I forget why we added the header blocks
> into the PUSH_PROMISE, can someone remind me (better yet, link to the
> appropriate email thread)?

You have to signal what you intend to push to give the client a chance
to reject it.  That's all.  So the only things that have to be in the
promise are resource identification things (:scheme, :host, :path),
and maybe (maybe) things that help identify cache (content-type, vary,

> 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.