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: Eliot Lear <lear@cisco.com>
Date: Tue, 26 Feb 2013 10:08:51 +0100
Message-ID: <512C7BA3.6020008@cisco.com>
To: Patrick McManus <pmcmanus@mozilla.com>
CC: Osama Mazahir <OSAMAM@microsoft.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

On 2/23/13 9:49 PM, Patrick McManus wrote:
> 8 is simply way too low for today's internet subresource count.. and
> we can't rely on the main resource (html) round trip to establish the
> setting as subresources are often served from a different host (e.g. a
> cdn).
> the guiding metric shouldn't be http/1 conns-per-hostname (6) but
> rather the realistic conns-per-page we see with sharding. Which is
> MUCH higher.
> 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.

Osama asked two questions.  Let's separate them:

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.  One approach is to
NOT have a default and require an advertised value at the beginning. 
That would lead to lock step behavior, however, which would add
latency.  Therefore, seems to me that 8 is actually a good number until
another number is received.  Except for one thing.  What to do about
tiny implementations?

2.  What is the minimum value?

That is, what are legal values for SETTINGS_MAX_CONCURRENT_STREAMS?

Is there a reason why a very simple implementation should NOT be able to
advertise a value of 1?

Received on Tuesday, 26 February 2013 09:09:20 UTC

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