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

Why 1?
On mobile devices you often end up reconnecting, and waiting yet and extra
RT to continue your session (likely using multiple streams) would add
latency. :/

With HTTP/2 (as inherited from SPDY), the server has a mechanism to tell
the client that it didn't process a stream at all, so the race is already
handled.
If a client sends 8 concurrent streams, and the server only wants to handle
6 (say, because it is particularly resource limited right now), then it
will reset two of the streams with an error code that essentially says
try-again-later, and it can do so after sending the SETTINGS frame.

-=R


On Fri, Feb 22, 2013 at 1:47 AM, Yoav Nir <ynir@checkpoint.com> wrote:

> Hi Osama
>
> Wouldn't 1 be a better initial value?  This would allow minimal
> implementations with no concurrency at all. It's usually the case for
> browser that the first round-trip contains exactly one request (for the
> HTML file), and only when the response is received do more requests come
> out. So this wouldn't slow us down much.
>
> Yoav
>
> On Feb 22, 2013, at 7:00 AM, Osama Mazahir <OSAMAM@microsoft.com> wrote:
>
> > Hi,
> >
> > Issue #38 [1] tracks:
> >       (1) What is the minimum number of concurrent client-initiated
> streams that a server must be able to support?
> >       (2) What is the default value?
> >
> > We have a race condition where the client can initiate more streams to
> the server before the server can advertise its stream accept limit to the
> client.  I suggest making the default the same as the minimum so that we
> can prevent that race.  And tighten the wording on what is legal.  For
> example, something like:
> >
> > A server MUST be able to handle at least 8 concurrent streams initiated
> by the client. A server MUST NOT advertise a value less than 8. A client
> MUST generate a session error if it receives a value less than 8 from the
> server. The default value server limit is 8.
> >
> > Thanks,
> > --Osama.
> >
> > [1] https://github.com/http2/http2-spec/issues/38
>
>
>