Re: minimum value for SETTINGS_MAX_CONCURRENT_STREAMS

>From a descriptive standpoint, Chromium doesn't have special code
here. If it sees concurrency go down to 0, it'll just queue all
pending HTTP requests for that HTTP/2 connection. No timeout or
anything (we have very few timeouts in our HTTP stack, relying instead
*mostly* on OS level timeouts).

As for whether or not it makes sense for us to do this heuristic
detection of server issues, we'd rather not go down that path if
possible. It makes our lives easier and improves interop (fewer
heuristics == good). But I guess we'd have to consider what options
the server has then. The server already has HTTP 5XX status codes, and
the 420 HTTP status code (lol jpinner), not to mention the HTTP/2
error code ENHANCE_YOUR_CALM (probably used by a RST_STREAM here,
unless you actually wanted to tear down the entire connection).

So, my *preference* would be to disallow a value of 0, purely from a
selfish make my life easier perspective. But I'm open to
server/intermediary folks saying they need to be able to set this
setting to 0.

On Fri, Jan 3, 2014 at 10:16 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 2 January 2014 16:11, Daniel Sommermann <dcsommer@fb.com> wrote:
>> Should servers be limited to sending values greater than zero for
>> SETTINGS_MAX_CONCURRENT_STREAMS? This question also applies to SPDY.
>
> In the world I used to come from, such mechanisms were used to request
> that clients temporarily hold off on sending more request.  This would
> be similar in many respects to Retry-After, but on a connection-wide
> scale, rather than scoped to a single resource.
>
> These sorts of facilities tend to be hugely useful in some limited scenarios.
>
> I would expect that a client that encounters a zero value treats it no
> differently to any other value.  If the client needs to send a
> request, and can't because there are too many streams open, it can
> either fail the request immediately, or it can enqueue the request for
> some limited amount of time.
>
> If a stream limit causes continuing problems, it is probably advisable
> for the connection to be torn down.  This can happen with a zero
> limit, or with a higher limit if a server fails to send END_STREAM
> properly.  How clients detect this situation is probably going to be
> implementation dependent, but clear indicators are: excessive numbers
> of enqueued requests, enqueued requests timing out before even being
> sent, etc...
>
> I'll note that the same sort of problem can happen for pushed
> resources at the server, though the obvious remedy there is
> RST_STREAM.
>
> I can't speak for SPDY, but I imagine that principle to be portable :)
>

Received on Friday, 3 January 2014 18:53:34 UTC