Get rid of the concurrent stream limit by advertising a maximum stream ID

[marten-seemann]

We've already had a lot of discussions about the concurrent streams limit, which all brought us back to the problem that at every given moment both peers have to agree about the number of open streams, which seems to require a non-trivial amount of bookkeeping (of ACKs received for all STREAM frames sent on a given stream).

I'd like to propose a different solution, which solves this problem, and has a couple of nice additional properties as well:

A receiver advertises the maximum Stream ID it is willing to accept. The sender is allowed to open all streams that have IDs not larger than this number. The receiver can advertise a higher maximum Stream ID whenever it likes to, by sending a STREAM_LIMIT_UPDATE frame. STREAM_LIMIT_UPDATE is a retransmittable frame that contains a single value, the maximum Stream ID.
Note that conceptually, this is similar to advertising a flow control offset (and the rules for STREAM_LIMIT_UPDATEs would be similar to those for WINDOW_UPDATEs).

An implementation is free to choose any algorithm to determine which maximum Stream ID it advertises. The number of open streams may be used, but I can think of a couple of other ways to limit the state a peer can create. It would even be possible to advertise different limits depending on the server load.

[lucas-clemente]

Note that GOAWAY (at least with its current semantics) could then just be a special case of this STREAM_LIMIT_UPDATE frame.

[RyanTheOptimist]

Interesting proposal! I wonder if we could also augment the RST_STREAM frame to include a new max_stream_id limit?

…

On Wed, Mar 29, 2017 at 1:40 AM, Lucas Clemente ***@***.***> wrote: Note that GOAWAY (at least with its current semantics) could then just be a special case of this STREAM_LIMIT_UPDATE frame. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#419 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASp6ynqwSAY1BLE4tLHdvLWsVm2HBQx6ks5rqhjrgaJpZM4MsXNB> .

[MikeBishop]

Sold. Working on a PR now. ;-)

[ianswett]

Nice suggestion.

I would expect it to be illegal to reduce the max stream id, but that's exactly what one might want to do with GOAWAY. Thoughts?

[MikeBishop]

There's still a place for an application-level signal -- you stop sending updates, but the other side needs to know whether they're just being throttled or asked to roll over to a new connection.

[mcmanus]

this is a clever way to look at the problem. thx.

…

On Wed, Mar 29, 2017 at 11:19 AM, Mike Bishop ***@***.***> wrote: There's still a place for an application-level signal -- you stop sending updates, but the other side needs to know whether they're just being throttled or asked to roll over to a new connection. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#419 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP5syMh6Hzfsi0ZHEghrIheCkFaBktQks5rqoR-gaJpZM4MsXNB> .

[siyengar]

I like this. This solves my issue here #432 as well. I raised the same issue on the list and this was my conclusion as well that we need a window_update like mechanism for stream limits.

[martinthomson]

Closed with #421.