Subject: [Webpush] h2 max streams and subscriptions

From: Benjamin Bangert <[email-masked]>
Date: Sat, 8 Aug 2015 10:41:05 -0700

How does the HTTP 2.0 SETTINGS_MAX_CONCURRENT_STREAMS setting adversely
affect the UA under WebPush?

For example, in a non-aggregated use-case, each GET for a subscription is
given a stream ID, and will count against the max concurrent streams (since
the main GET stream is never completed).

A common setting in some existing h2 servers is 100 for max streams. Which
means if you had 100 subscriptions, you would be unable to get any
notifications, as each notification for a PUSH frame is a new stream, and
they've all been exhausted.

If the max streams case is hit, what should the UA do when new
subscriptions are requested? Start unsubscribing from less used ones per a
LRU? Return an error that a subscription couldn't be created?

Aggregating would alleviate this greatly, since the subscription is a
single stream in that case, and the remainder of the concurrent stream
allowance is saved for additional commands/notifications. If it's possible
for a non-aggregate case though, this seems like it wouldn't be that
improbable to run up against the max streams.

- Ben

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Aug 2015 18:53:55 -0700

> they've all been exhausted.

The stream limit only applies to streams that you initiate, so the
client's setting determines how many concurrent pushes the server can
send.  The server's setting - exhausted or not - has no effect on
that.

Obviously, a server that has a low concurrent stream limit can't be
used with indepedent (i.e., not aggregated) subscriptions that exceed
that number.  That might be all the incentive you need to encourage
use of aggregation (in the other thread).  And I would not recommend
opening a second connection to overcome this limit.

---

From: Benjamin Bangert <[email-masked]>
Date: Sun, 9 Aug 2015 10:03:26 -0700

> send.  The server's setting - exhausted or not - has no effect on

Ah, right. Forgot that the client has  its own independent concurrent
stream limit.

> opening a second connection to overcome this limit.

So in such a case, what is expected behavior when the concurrent stream
limit is exceeded and a client wishes to make more subscriptions? The
current WebPush spec has no language in it indicating what should occur,
what action a client should take, etc. when it hits the max stream limit
using independent subscriptions.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Aug 2015 13:39:58 -0700

> using independent subscriptions.

My suggestion would be to document the limit. If a server wants to
limit the concurrent streams in order to limit the number of
concurrent, independent subscriptions, then that seems like a valid
thing to do. I would hope that clients respect this limit and
therefore have to treat any additional subscriptions as failed (or at
least temporarily inaccessible).

See https://github.com/webpush-wg/webpush-protocol/issues/43

---

From: Benjamin Bangert <[email-masked]>
Date: Sun, 9 Aug 2015 14:34:16 -0700

> See https://github.com/webpush-wg/webpush-protocol/issues/43

I've added an additional note to this issue, indicating that using a
setting of 2 for max streams might be one way for a server to ensure
aggregate subscriptions are used.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Aug 2015 14:39:57 -0700

On 9 August 2015 at 14:34, Benjamin Bangert <[email-masked]> wrote:
> I've added an additional note to this issue, indicating that using a setting
> of 2 for max streams might be one way for a server to ensure aggregate
> subscriptions are used.

Right.  Note that it also has the side-effect of serlializing requests
for new subscriptions; which you might consider to be good or bad
depending on your perspective.