Subject: [quicwg/base-drafts] Get rid of the concurrent stream limit by advertising a maximum stream ID (#419)

From: Marten Seemann <[email-masked]>
Date: Tue, 28 Mar 2017 17:37:32 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419

---

From: Lucas Clemente <[email-masked]>
Date: Wed, 29 Mar 2017 01:40:11 -0700

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 or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419#issuecomment-290023029

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 29 Mar 2017 07:23:39 -0700

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 <[email-masked]>
wrote:

> Note that GOAWAY (at least with its current semantics) could then just be
> a special case of this STREAM_LIMIT_UPDATE frame.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/419#issuecomment-290023029>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ynqwSAY1BLE4tLHdvLWsVm2HBQx6ks5rqhjrgaJpZM4MsXNB>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419#issuecomment-290105922

---

From: Mike Bishop <[email-masked]>
Date: Wed, 29 Mar 2017 09:04:26 -0700

Sold.  Working on a PR now.  ;-)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419#issuecomment-290138246

---

From: ianswett <[email-masked]>
Date: Wed, 29 Mar 2017 09:11:01 -0700

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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419#issuecomment-290140223

---

From: Mike Bishop <[email-masked]>
Date: Wed, 29 Mar 2017 09:19:11 -0700

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 or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419#issuecomment-290142627

---

From: Patrick McManus <[email-masked]>
Date: Wed, 29 Mar 2017 13:49:08 -0700

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

On Wed, Mar 29, 2017 at 11:19 AM, Mike Bishop <[email-masked]>
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.
>
> —
> <https://github.com/quicwg/base-drafts/issues/419#issuecomment-290142627>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5syMh6Hzfsi0ZHEghrIheCkFaBktQks5rqoR-gaJpZM4MsXNB>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/419#issuecomment-290221229