Consider increasing stream limits defaults for HTTP/3

[ManickaP]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I already opened this idea with @JamesNK.
We should also consider whether this change might have negative impact on contention and whether it might have security implication.
I tested some of the externally available H/3 servers (the numbers are give or take):

Server	Bidi	Unidi
https://quic.nginx.org/	128	3
https://cloudflare-quic.com/	256	3
https://www.litespeedtech.com/	100	3
https://quic.tech:8443/	100	100
https://quic.aiortc.org:443/	128, 256, 512	128, 256, 512
https://h2o.examp1e.net/	100	10
https://msquic.net	100	3

This idea comes mainly from @nibanks suggestion to use a single connection and many streams for the best perf results.

cc: @CarnaViire @wfurt @rzikm

Describe the solution you'd like

I'm opening this to start a discussion. This might also just lead to only a docs change recommending increasing stream limits for high perf scenarios.

Additional context

HttpClient supports only single H/3 connection at the moment. Issue to support more has been already filed: dotnet/runtime#51775

[wfurt]

what is our current default?

[ManickaP]

what is our current default?

bi=100 uni=10
https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Transport.Quic/src/QuicTransportOptions.cs

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.