openscreenprotocol
openscreenprotocol copied to clipboard
w3c
Add a NOTE about MAX_STREAMS for QUIC connections
Addresses #334.
MAX_STREAMS limits the number of QUIC streams that can be opened per connection. Recommend a high value so that agents won't run into this limit in practice.
@DavidSchinazi am I interpreting the QUIC RFC correctly here? Appreciate it if you could take a look.
MAX_STREAMS frames exist for flow control purposes. This isn't something that is set once per connection; an endpoint will repeatedly send MAX_FRAMES with increasing values to its peer in order to keep the data flowing.
Here's an example: let's say I have limited memory and only want to allow 100 simultaneous streams. I'll start off by sending you MAX_STREAMS with 100, you'll open up some streams, and let's say when you have closed your first 10 streams, I'll send you another MAX_STREAMS, but this time with 110 - that way you always have 100 possible. Many other strategies are possible. You could for example start off with a small limit, and then increase if you deem the peer trustworthy.
But more fundamentally, this is not something application protocols should worry about. The statement "configure your QUIC stream limits such that it doesn't get in the way of your application performance" is true for all application protocols, there's no point in having every application protocol repeat it. Because once you go down that route, it's pretty much endless. You could also say "make sure your delayed ack strategy doesn't harm performance", and similar guidance for many other internal details of QUIC too.
What you do need to specify is whether you use unidirectional vs bidirectional streams, but looks like you covered that in 4581b3da4661b90636e9c5cec09f710a60f50182.
Thanks for the feedback @DavidSchinazi. I've updated the NOTE with simpler advice for implementations along the lines of what you suggested.
Per https://www.w3.org/2024/09/27-webscreens-minutes.html#t03:
RESOLUTION: Close issue #334 by merging PR #336