Re: #38 - HTTP2 min value for server supported max_concurrent_streams

Albert Lunde <atlunde@panix.com> Tue, 26 February 2013 11:31 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 AF72821F8992 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Feb 2013 03:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Level:
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFrl2ky3Q31y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Feb 2013 03:31:46 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4877921F88E3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Feb 2013 03:31:46 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UAIjq-0005tW-Bo for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Feb 2013 11:30:26 +0000
Resent-Date: Tue, 26 Feb 2013 11:30:26 +0000
Resent-Message-Id: <E1UAIjq-0005tW-Bo@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <atlunde@panix.com>) id 1UAIjh-0005sn-5f for ietf-http-wg@listhub.w3.org; Tue, 26 Feb 2013 11:30:17 +0000
Received: from mailbackend.panix.com ([166.84.1.89]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <atlunde@panix.com>) id 1UAIjc-0007lE-Ny for ietf-http-wg@w3.org; Tue, 26 Feb 2013 11:30:17 +0000
Received: from [192.168.15.4] (unknown [184.78.58.209]) by mailbackend.panix.com (Postfix) with ESMTP id 830FF2E0CB; Tue, 26 Feb 2013 06:29:51 -0500 (EST)
Message-ID: <512C9CB0.2030502@panix.com>
Date: Tue, 26 Feb 2013 05:29:52 -0600
From: Albert Lunde <atlunde@panix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: HTTP Working Group <ietf-http-wg@w3.org>
References: <B33F11E188FEAB49A7FAF38BAB08A2C001D31EBA@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <7D5CB237-97F8-4C6C-93F4-79E2C42D0EFF@checkpoint.com> <CAP+FsNcpbpXP8yAtTa4PgUhSrBjERDULyrHeOdjh-c70Ccu3Gg@mail.gmail.com> <CABkgnnXHuO-rYJ0buBzpFdF=eBCj2Lq_RzCf8p2wsVHf3ZUsCA@mail.gmail.com> <1E0AFABE-9300-41B8-9E0D-5FFCDEA574F3@checkpoint.com> <CAA4WUYhCLv5vv9tnm9TbYGaF5do-BzKNmuHv17XJ_GM7zFwSaA@mail.gmail.com> <B33F11E188FEAB49A7FAF38BAB08A2C001D32B31@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <CAA4WUYhTqzxLgrzoVGsKxbU=XqPgD=GexX0Mnq3m8HiZJSKBcw@mail.gmail.com> <B33F11E188FEAB49A7FAF38BAB08A2C001D34CA3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <B33F11E188FEAB49A7FAF38BAB08A2C001D34CA3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=166.84.1.89; envelope-from=atlunde@panix.com; helo=mailbackend.panix.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-1.558, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.704, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UAIjc-0007lE-Ny 257502b373e663f899457b76d2b3fb37
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #38 - HTTP2 min value for server supported max_concurrent_streams
Archived-At: <http://www.w3.org/mid/512C9CB0.2030502@panix.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16830
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 2/26/2013 2:34 AM, Osama Mazahir wrote:
> 1.Handshake Advertise: Advertise limits as part of 
> handshake/negotiation.  That way, upon session start each side knows the 
> other’s limit and can guarantee that it won’t violate it.  That way, we 
> can simplify all parts of the protocol that are dealing with 
> limit-exceed cases.

Would there be any merit to having a limited number of low-resource
profiles which would set several parameters? The chief virtue seems that
they might be specified in fewer bits.

I can't see this as a mechanism that scales up indefinitely unless the
profiles could be monotonically ordered, and the parameters given by
some sort of power or exponential function (this could be hard to tune).

So this idea is mainly an escape hatch for low-end clients or servers.