Subject: minimum value for SETTINGS_MAX_CONCURRENT_STREAMS

From: Daniel Sommermann <[email-masked]>
Date: Thu, 2 Jan 2014 16:11:40 -0800

The HTTP/2.0 spec allows clients to advertise 
SETTINGS_MAX_CONCURRENT_STREAMS of 0 to indicate they do not support 
server push. However, it is not specified whether a server may advertise 
a value of zero for this setting. It seems odd for a server to advertise 
such a value, and it is not clear to me what a client implementation 
should do in such a case (close the connection and try again, wait for 
another SETTINGS frame, etc).

Should servers be limited to sending values greater than zero for 
SETTINGS_MAX_CONCURRENT_STREAMS? This question also applies to SPDY.

---

From: Daniel Sommermann <[email-masked]>
Date: Fri, 3 Jan 2014 10:13:47 -0800

This may be a non-concern. If a server advertises such a value, that 
server would only be exposing itself to a DOS attack. Still, the client 
has a few choices how to respond to such a situation. Perhaps it's not 
right prescribe set behavior for this case, but it might be worth 
mentioning calling out the corner case in the doc. Perhaps we could add 
the following language to 6.5.2:

"A server MAY advertise a value of 0 for 
SETTINGS_MAX_CONCURRENT_STREAMS. However, a client receiving this 
setting MAY issue a connection error (Section 5.4.1) of type 
PROTOCOL_ERROR."

On 01/02/2014 04:11 PM, Daniel Sommermann wrote:
> server push. However, it is not specified whether a server may 
> advertise a value of zero for this setting. It seems odd for a server 
> to advertise such a value, and it is not clear to me what a client 
> implementation should do in such a case (close the connection and try 
> again, wait for another SETTINGS frame, etc).
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Jan 2014 10:16:59 -0800

> 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 :)

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 Jan 2014 10:53:01 -0800

>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.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 5 Jan 2014 11:05:11 -0800

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

---

From: Roberto Peon <[email-masked]>
Date: Sun, 5 Jan 2014 13:10:00 -0800

0 is little different from k when you need n and n >> k.

A setting of 0 will be useful in dos-like scenarios where one may wish to
slow down the rate of connection attempts or new requests.

In non http use cases it may be perfectly reasonable that the "server"
declare that it only makes requests, and the "client" only answers them.

-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 5 Jan 2014 14:06:54 -0800

Your arguments are reasonable. The only question is whether or not
supporting those use cases is more important than the simplicity that
I noted on the client end. It may very well be more important, I'm
open to that. I agree with Martin that we can probably quickly arrive
to a decision in Zurich.