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

On Tue, Feb 26, 2013 at 3:01 PM, Yoav Nir <ynir@checkpoint.com> wrote:

>
>  On Feb 27, 2013, at 12:31 AM, Roberto Peon <grmocg@gmail.com>
>  wrote:
>
>  On Tue, Feb 26, 2013 at 2:15 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>
>> Hi
>>
>>  Thinking it over, even a minimal server that can only handle one
>> request at a time can be accommodated by the current document. Such a
>> server would send a SETTINGS frame ASAP, and would process incoming streams
>> one by one. Streams where we get frames before the FLAG_FIN of a previous
>> stream would get a RST. But GETs are more numerous than POSTs, so bodies
>> tend to be empty. Until its SETTINGS is processed by the client, the
>> requests will mostly be just SYN_STREAM frames with the FLAG_FIN set, and
>> they can be handled sequentially. Depending on how the MUSTs and SHOULDs
>> are phrased, this may or may not be compliant, but it would be
>> interoperable with any HTTP/2 client.
>>
>>  Back to the issue, I don't think any number makes sense other than 1.
>> So if we can't wait the round-trip, we might as well set no initial limit,
>> and leave it up to the application (client) to decide how many are prudent
>> initially.
>>
>
>  As a server owner, that (unlimited) makes me a bit afraid-- I want to
> set a high enough default that we don't cause additional latency most of
> the time, but also small enough that I can catch misbehaving or malicious
> parties in bad behavior as quickly as possible.
>
>
>  OK. But suppose we set the default to 100 and a client opens 101
> concurrent streams. What would a server do? It's very rare that a server
> can do anything interesting in real-time to enforce RFC requirements.
>

Then the client isn't respecting the protocol. I favor quick session
termination - GOAWAY.


>   We picked 100 originally as it was the nearest
> power-of-something-familiar where the limit was greater than the average
> number of resources on a page, and it is reasonable for a server to reject
> what it needs to.
> Sadly, we have experience with this already-- we have at least one domain
> where the maximum concurrency is limited to 10, and so we do already have
> experience in the scenario where the default is higher than we intend to
> run with. It causes no real problems.
>
>
>  A paragraph that ends with "causes no real problems" should not begin
> with "Sadly" :-)
>
>
>
>> But instead the spec should make it clear that having a stream reset with REFUSED_STREAM
>> or some such is not a fatal error, and the client should try again with a
>> new stream. Servers should be advised to send the SETTINGS frame before
>> sending any RST, so that the client doesn't retry when too many (in the
>> server's opinion) streams are open.
>>
>
>  Agreed-- if the spec isn't already clear about it must be fixed!
>
>
>  The spec is currently silent about why a server might want to close a
> stream with REFUSED_STREAM, or what a client should take that to mean.
> All it says is this:
>
>    Upon receipt of a SYN_STREAM, the recipient can reject the stream by
>    sending a stream error (Section 3.4.2 <http://tools.ietf.org/html/draft-ietf-httpbis-http2-01#section-3.4.2>) with the error code
>    REFUSED_STREAM.  Note, however, that the creating endpoint may have
>    already sent additional frames for that stream which cannot be
>    immediately stopped
>
>
>  So the server "can reject", but it's not clear why it would or what this
> means to the client.
>

That's another place where we did not spec it out in SPDY as well as we
should have. In Chromium, we retry on REFUSED_STREAM, because we think it
happened due to a race or something (GOAWAY or SETTINGS race):
https://code.google.com/p/chromium/codesearch#chromium/src/net/http/http_network_transaction.cc&q=REFUSED_STREAM&sq=package:chromium&type=cs&l=1307.
For races, I think it's reasonable for the peer to send a RST_STREAM with
REFUSED_STREAM. For complete failures to respect the protocol, e.g. default
streams limit, I think the receiver should terminate the connection with a
GOAWAY with PROTOCOL_ERROR.


>  Yoav
>
>
>