W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 26 Feb 2013 08:58:02 -0500
Message-ID: <CAOdDvNrtwSrcn=KQq7aZ1sayxGdeuscPXjAoFxHjDMatw9Pk8A@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Osama Mazahir <OSAMAM@microsoft.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, Feb 26, 2013 at 4:08 AM, Eliot Lear <lear@cisco.com> wrote:

> On 2/23/13 9:49 PM, Patrick McManus wrote:
>> 8 is simply way too low for today's internet subresource count.. and
>> The default should be at least on the order of 100 (as I believe it
>> currently is), but honestly with the newer flow control measures in
>> place should perhaps be even higher to let the parallelism and
>> prioritization mechanisms work unobstructed.
> 1.  What is the default value?
> That is, if SETTINGS_MAX_CONCURRENT_STREAMS isn't set what value is
> chosen?  Currently the default indicates no limit.

The draft provides the advice that all implementations should support
100. That is decently sized to the problem being solved by a parallel
prioritized protocol. imo it should actually be bigger. 8 is crazy
small. It also provides a mechanism to reject streams greater than it
wants to support should you create a server incapable of doing this
(i.e. it can send a settings followed by the rsts)

The cost of setting it to 8 means you force queuing in the very common
"fetch 84 subresources from this CDN" case. Honestly, that case is
where http-2 gets almost all of its performance benefit and addresses
a well known weakness with http/1. It's pipelining with mux and
prioritization done to eliminate client side queues - that's the key
to the whole shebang. We need to emphasize the parameters that make
that work well (i.e. parallelism, responsive frame sizes, well
structured priorities). Adding a round trip just to figure out that
the protocol designed for parallelism does a decent amount of
parallelism is counter productive.

Received on Tuesday, 26 February 2013 13:58:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC