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

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.

-P

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