W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: minimum value for SETTINGS_MAX_CONCURRENT_STREAMS

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sun, 5 Jan 2014 11:05:11 -0800
Message-ID: <CABkgnnX7zSY_cKz_zwJ-zek3-Mo7J9kGD45w3YkRpp-qYXQCgQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>
Let's track this.  I hope that it can be easy to resolve in Zurich
with everyone in the room.

https://github.com/http2/http2-spec/issues/335

On 3 January 2014 10:53, William Chan (陈智昌) <willchan@chromium.org> wrote:
> 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 Sunday, 5 January 2014 19:05:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC