Subject: http/2 initial limits - i see flow control initial limits specified, but not stream limits

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 May 2013 14:37:06 -0300

Did the stream limits disappear by accident?

---

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 10:47:52 -0700

Which limits specifically? SETTINGS_MAX_CONCURRENT_STREAMS is still
there. Are there others you're concerned about?

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 May 2013 14:52:25 -0300

The setting is there, but I don't see the initial limit, which I believe
was 100.

---

From: James M Snell <[email-masked]>
Date: Fri, 3 May 2013 11:04:47 -0700

Currently in the trunk:

    indicates the maximum number of concurrent streams that the sender
will allow.
    This limit is directional: it applies to the number
    of streams that the sender permits the receiver to create. By
default there is no
    limit.  It is recommended that this value be no smaller than 100,
    so as to not unnecessarily limit parallelism.

On Fri, May 3, 2013 at 10:52 AM, William Chan (陈智昌)
<[email-masked]> wrote:
> The setting is there, but I don't see the initial limit, which I believe was
> 100.
>
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 14:22:07 -0700

This does differ from SPDY, but (still) seems reasonable given the number
of streams created in the initial RTT shouldn't be unbounded anyway.
Assuming we have persisted settings (which is in doubt, I guess), this
would only be a problem for the first RTT in a session where we didn't have
the persisted setting.

On Fri, May 3, 2013 at 11:04 AM, James M Snell <[email-masked]> wrote:

> was

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 May 2013 15:46:45 -0700

On 3 May 2013 14:22, Roberto Peon <[email-masked]> wrote:
> This does differ from SPDY,

This doesn't differ from the SPDY we were given.

> but (still) seems reasonable given the number of
> streams created in the initial RTT shouldn't be unbounded anyway.
> Assuming we have persisted settings (which is in doubt, I guess), this would
> only be a problem for the first RTT in a session where we didn't have the
> persisted setting.

I think that this default is under contention still:
https://github.com/http2/http2-spec/issues/40

We may ultimately determine that some value between 0 (what #40
proposes) and infinity (status quo) is more appropriate.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 May 2013 18:55:21 -0700

Yup, the language in the specs is the same as what is currently in the
HTTP/2 spec, but people have been interpreting them differently (or at
least I assume so).

   - 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the
   remote endpoint the maximum number of concurrent streams which it will
   allow. By default there is no limit. For implementors it is recommended
   that this value be no smaller than 100.

is the thing in question, and most implementations that I know of default
to 100, which makes sense given that "no limit" and "unlimited" are not
always the same.
-=R

On Fri, May 3, 2013 at 3:46 PM, Martin Thomson <[email-masked]>wrote:

> would

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 3 May 2013 23:04:11 -0300

It sounds like I misremembered the spec. Sorry folks :) Sounds like any
change here is blocked on issue #40.