Subject: [quicwg/base-drafts] Are Separate Uni and Bidi Stream Limits Meaningful? (#2358)

From: martinduke <[email-masked]>
Date: Tue, 22 Jan 2019 10:50:52 -0800

I believe there's loophole in these limits.

If the peer has given me uni credit but not bidi credit, I can open a uni send stream and send data. Are we counting on all applications to handle this correctly? (e.g. HTTP/3 will prohibit a request on a uni stream)

Similarly, if I have bidi credit but not uni credit, I can open a bidi stream with a STOP_SENDING.

Are we comfortable that the abuse cases are benign? Now that there is no "max-stream-id" parameter, it is more straightforward for stream limits to be global, should we decide that's better.

-- 
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/2358

---

From: ianswett <[email-masked]>
Date: Tue, 22 Jan 2019 19:11:46 +0000 (UTC)

I think this is a good question, and I believe we decided on separate limits because people thought they were useful for HTTP, particularly in the context of server push where you may want to limit the number of pushes?  But now we have MAX_PUSH_ID at the HTTP layer, so that particular use case isn't a good motivation.

If we believe a single limit is better, I think we would end up wanting to revisit a variety of design details, so I suspect the WG is not excited about that.

-- 
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/2358#issuecomment-456525050

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 22 Jan 2019 19:52:41 +0000 (UTC)

H2 had a bit of a blind spot about controlling the servers over committal of push.

For H3, MAX_PUSH_ID alone doesn't provide enough control but with addition of the current separate ID spaces, the client has some ability to influence how available stream IDs are consumed by the server. This is because it can restrict the available unidirectional streams. With a global counter, a greedy server can gobble up newly freed up stream IDs that the client may want to create for itself.

-- 
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/2358#issuecomment-456539190

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 21:48:53 +0000 (UTC)

Though functionally a bidirectional stream with accompanying STOP_SENDING looks like a unidirectional stream, it is unlikely that an application protocol will treat it as being unidirectional, because the type of stream is input to processing - bidirectional streams have different semantics.  So I think that we *can* rely on application protocols dealing with this case properly.

But the split has utility.  At least in h3, this avoids the problem @LPardue describes.  Firefox treats responses to requests and pushes very differently from a flow control perspective and the split there makes things considerably more efficient for us.  MAX_PUSH_ID is insufficient - we want that to be much higher than the number of concurrent unidirectional streams so that we can learn about potential pushes.  The actual limit needs to be lower, particular since the utility of push is... questionable.

I can only speculate about other protocols, but I think that we have enough justification here to keep the design as-is.

-- 
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/2358#issuecomment-456576462

---

From: Christian Huitema <[email-masked]>
Date: Sun, 27 Jan 2019 18:20:49 -0800

I would rather leave them separate, and leave it to apps to provide guidance.

-- 
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/2358#issuecomment-457979824

---

From: martinduke <[email-masked]>
Date: Tue, 29 Jan 2019 16:48:03 -0800

Closed #2358.

-- 
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/2358#event-2105245527

---

From: martinduke <[email-masked]>
Date: Tue, 29 Jan 2019 16:48:03 -0800

I find the feedback here convincing. Closing.

-- 
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/2358#issuecomment-458767039