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

[William Chan (陈智昌) <[e-mail]>]

Thank you for continuing to raise this issue. I definitely think this is
worth discussing. I've reflected a bit on what you and others have said. If
I understand you correctly, you are primarily concerned with the races
before limits can be negotiated, and would like to see them fixed. I've
pointed out that the races existed in HTTP/1.X and still exist with things
like GOAWAY. It sounds like you'd like to fix them. I'm OK with fixing them
as long as they do not impose performance costs due to extra roundtrips to
reach appropriate parallelism. I think we disagree on acceptable code
complexity. We've already implemented this logic in Chromium and believe it
not to be burdensome.

So, on that point, I think we may agree to disagree and see how the rest of
the working group feels.

But, can we fix the race without imposing performance costs? Let's examine
the cases:
(1) Upgrade, where, assuming successful negotiation, the server begins
HTTP/2 in response to the HTTP/1.1 request with the Upgrade header.
(2) HTTPS negotiation via TLS-NPN style mechanism. Client speaks HTTP/2
first.
(3) Out of band discovery like DNS, and the client starts speaking HTTP/2

In (1), the server speaks first and can send SETTINGS immediately. So
respecting server limits is not a concern. Respecting client limits is a
concern. I think this falls into your "handshake advertise" scenario. We
could add a HTTP header for the relevant SETTINGS during the Upgrade. This
way, the server can respect the client limits.

In (2), the client speaks first, and will only respect server default
limits, not server specified limits since the server hasn't had a chance to
send them yet. It's conceivable we could add settings into the NPN
handshake. I'm a bit concerned about stashing so much into that handshake,
since we've also previously discussed expressing capabilities in the
handshake (e.g: supporting WebSockets over HTTP/2). If we wanted to do
something like this, we probably would need to convey such a requirement to
the TLS WG. I'm hesitant.

In (3), since there is no negotiation, only discovery via DNS mechanisms,
we'd have to stash the settings in DNS as discussed previously, and
probably sign it too.

I'm open to discussing conveying SETTINGS via the negotiation/discovery
mechanisms we have available, in order to attempt to reduce complexity. If
we can reasonably prevent races via conveying SETTINGS sooner, then great.
But I still believe the defaults should be chosen so they do not impose
performance costs due to roundtrips to raise the limits from a low default.
As Patrick says, 8 is far too small. The default should be on the order of
100. It's very common to do large domain sharding to a CDN, and we should
make sure we can handle that case with a single connection, rather than
incentivizing web devs to continue to do domain sharding to achieve desired
parallelism.


On Tue, Feb 26, 2013 at 12:34 AM, Osama Mazahir <[e-mail]>wrote:

>  Internet Explorer has similar gymnastics.  However, I don’t think that
> is just cause to reinvent the same problems again.****
>
> ** **
>
> In general, the problem we have is that one side initiates operations
> without knowing the peer’s limits.  MaxConcurrentStreams is one example and
> negative flow control bytecounts is another (i.e. where the receiver is
> trying to advertise that it has small buffers but we shove data down its
> throat and dictate that it “MUST be prepared to receive the entire amount”
> [1]).****
>
> ** **
>
> Possible solutions include:****
>
> **1.       **Handshake Advertise: Advertise limits as part of
> handshake/negotiation.  That way, upon session start each side knows the
> other’s limit and can guarantee that it won’t violate it.  That way, we can
> simplify all parts of the protocol that are dealing with limit-exceed cases.
> ****
>
> **2.       **Defaults and minimums: In the spec we pick some defaults and
> minimums so that each endpoint starts at a known initial state and each
> endpoint can thus guarantee that it won’t violate the peer’s limits.  The
> initial SETTINGS frame can grow those limits.  Thus, we can simplify/delete
> all the limit-exceed handling.****
>
> **3.       **Don’t fix: Not really a “solution”.  We write pages of
> protocol text describing the races, how to workaround limit-exceed cases,
> code and test it, and put that burden on all future implementers.****
>
> ** **
>
> In short, I ask the WG to not summarily dismiss this issue.  We should
> devote some energy to ensure that the protocol is robust by-design.****
>
> ** **
>
> [1] http://http2.github.com/http2-spec/#rfc.section.3.7.9.3****
>
> ** **
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *William
> Chan (???)
> *Sent:* Friday, February 22, 2013 3:57 PM
> *To:* Osama Mazahir
> *Cc:* Yoav Nir; Martin Thomson; Roberto Peon; [e-mail] Group
>
> *Subject:* Re: #38 - HTTP2 min value for server supported
> max_concurrent_streams****
>
> ** **
>
> On Fri, Feb 22, 2013 at 3:45 PM, Osama Mazahir <[e-mail]>
> wrote:****
>
>   ****
>
> As Martin said, 1 seems overly restrictive.  ****
>
>  ****
>
> My major concern is not the value of the number, but that we have a
> minimum value and the default be the same as the minimum.  Otherwise, we
> leave the race hole open then we are just increasing complexity.****
>
>  ** **
>
> Do you feel like the complexity is that bad? In my experience, from
> implementing SPDY, it is not.****
>
>  ****
>
>  1.       Client will have to track negative allowance (because it did
> not know how many requests it allowed to send)****
>
>  ** **
>
> Isn't this easy? The client always has to track how many outstanding
> streams it has in order to respect the limit.****
>
>  ****
>
>  2.       Server has to promise that RST_STREAM due to
> max_concurrent_stream overflow did not have any side effects****
>
> o   The server should verb agnostic (i.e. GET vs POST) and just look at
> some streamCount variable.****
>
> o   Otherwise, client will have to pend all non-idempotent requests until
> it gets the SETTINGS frame from the server****
>
>  ** **
>
> Since RST_STREAM has an error code, this is easy to define.****
>
>  ****
>
>  3.       Client will have to resubmit the request into its queue to be
> sent when the allowance opens up****
>
>  Clients already have to know how to do this due to the GOAWAY race. They
> also have to handle this in HTTP/1.X today. For example, if we get an error
> when reusing a persistent HTTP connection (e.g. TCP RST), we will resend
> the HTTP request over a new connection.****
>
>  4.       If the “blind” request(s) (i.e. sent before client received the
> SETTINGS frame) have entity-body then client****
>
> o   Must wait until the server’s SETTINGS frame before sending
> entity-body OR****
>
> o   Be able to regenerate the entity-body when the “blind” request is
> RST_STREAMed****
>
> §  This means the layer on top of client stack needs to be able to handle
> a “retry” error and resubmit the entity-body OR****
>
> §  The client stack buffers all the entity-body, as it converts it into
> DATA frames, until it knows that the request won’t get RST_STREAM due to
> max_concurrent_stream****
>
> o   Or just blow up and complain to the user****
>
>  ** **
>
> Again, clients already have to handle this.****
>
>  ****
>
>   ****
>
> In general, I would prefer if we made HTTP/2.0 to not have such races to
> begin with instead of piling on complexity to react to the races.****
>
>  ** **
>
> As someone with experience implementing a SPDY client, I do not believe
> this is a big burden. If you believe it is, I would like to hear why.****
>
>  ****
>
>   ****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *William
> Chan (???)
> *Sent:* Friday, February 22, 2013 2:36 PM
> *To:* Yoav Nir
> *Cc:* Martin Thomson; Roberto Peon; Osama Mazahir; [e-mail]
> *Subject:* Re: #38 - HTTP2 min value for server supported
> max_concurrent_streams****
>
>  ****
>
> We always have to examine what the choices end up being for which parties.
> If servers end up limiting parallelism, or requiring roundtrips to ramp up
> parallelism, then clients which want speed (browsers) will be incentivized
> to simply open up more connections to bypass the low parallelism limit or
> slow start.****
>
>  ****
>
> Overall, I think it's better to tolerate the minor suboptimality of having
> servers RST_STREAM streams if they don't want so much parallelism, rather
> than incentivize browsers to open more connections.****
>
>  ****
>
>  ****
>
>  ****
>
> On Fri, Feb 22, 2013 at 2:19 PM, Yoav Nir <[e-mail]> wrote:****
>
>
> On Feb 22, 2013, at 6:16 PM, Martin Thomson <[e-mail]>
> wrote:
>
> > On 22 February 2013 05:18, Roberto Peon <[e-mail]> wrote:
> >> Why 1?
> >
> > 1 seems a little restrictive, especially since 6 concurrent
> > connections is the current expectation in many browsers.****
>
> Defaulting to 1 allows for a simple server that never has to handle
> multiple concurrent streams, one that can be implemented with much fewer
> lines of code, but is still compliant. Great for serving software updates,
> large files, CRLs, etc. Not so great for web pages.
>
> Other servers will quickly raise the limit via a SETTINGS frame.
>
> Yoav****
>
>   ****
>
>  ** **
>