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: Roberto Peon <grmocg@gmail.com>
Date: Fri, 22 Feb 2013 08:26:56 -0800
Message-ID: <CAP+FsNfvLMzqwRDcHNnVuY6QH=uf9grKhRUnqgzUonXOOiWFAg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Yoav Nir <ynir@checkpoint.com>, Osama Mazahir <OSAMAM@microsoft.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Fri, Feb 22, 2013 at 8:16 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 22 February 2013 05:18, Roberto Peon <grmocg@gmail.com> wrote:
> > Why 1?
>
> 1 seems a little restrictive, especially since 6 concurrent
> connections is the current expectation in many browsers.
>
> > 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.
>
> This is not isomorphic with a lower stream limit simply because the
> client will have sent some amount of data for the 2 rejected streams,
> expending some of what is a fairly limited resource (INIT CWD being as
> it is).  That's probably OK if you consider that it's the client
> prerogative and responsibility.
>

Well, we get to waste resources either way unless the default MAX_STREAMS
is already optimal (fat chance)-- one way wastes bandwidth by pushing at
most 1 BDP worth of bytes on the wire, and the other has the connection
idle for a BDP or more. :/

I'm guessing that the latter ends up dominating thanks to short NAT
timeouts, etc, when a user comes back to the browser after some period of
being idle. Also, assuming we do keep persisted SETTINGS, then the impact
of opening up too many streams becomes even more limited as it happens far
more rarely.

-=R
Received on Friday, 22 February 2013 16:27:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 February 2013 16:27:29 GMT