Support WebTransport anticipatedStreams

[jesup]

No description provided.

[Copilot]

Pull request overview

This PR adds a WebTransport-facing API to declare anticipated incoming stream concurrency per session and plumbs that through to QUIC MAX_STREAMS updates so the peer can open more streams than the handshake baseline.

Changes:

• Add transport-layer setters to update advertised remote stream limits (uni/bidi) via MAX_STREAMS.
• Track per-session anticipated uni/bidi incoming counts and sum them across sessions to drive connection-level stream limits.
• Add WebTransport tests validating when MAX_STREAMS frames are (and are not) sent.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
neqo-transport/src/streams.rs	Adds setters to update remote stream limits for uni/bidi streams.
neqo-transport/src/fc.rs	Documents intended set_max_active behavior related to monotonic limit updates.
neqo-transport/src/connection/params.rs	Updates docs for baseline stream limits and how they can be increased post-handshake.
neqo-transport/src/connection/mod.rs	Exposes connection-level setters for remote max streams (uni/bidi).
neqo-http3/src/features/extended_connect/tests/webtransport/mod.rs	Wires in the new anticipated-streams test module.
neqo-http3/src/features/extended_connect/tests/webtransport/anticipated_streams.rs	New tests for anticipated stream APIs and MAX_STREAMS transmission behavior.
neqo-http3/src/features/extended_connect/session.rs	Stores per-session anticipated incoming uni/bidi counts with accessors.
neqo-http3/src/connection_client.rs	Adds public Http3Client API methods to set anticipated incoming stream counts.
neqo-http3/src/connection.rs	Implements the handlers that store anticipated values and sum across sessions to update transport limits.

[mxinden]

I am missing context. What is the goal of this feature? What does it enable applications to do?

Note that, in case we ever run multiple sessions and HTTP/3 requests on the same connection, a single session could choose the global limit, by setting its session limit, which propagates to a global limit.

[mxinden]

I don't think we use these heading styles anywhere else in the codebase. Not opposed, but would like to be consistent.

[martinthomson]

This change is not what I would have expected from this one. The goal of this is to ensure that the flow control allocation for streams is generous enough that the server can make streams without getting blocked. To that end, this should route the message through to the max_active value on the relevant ReceiverFlowControl instance.

There is also the potential for this input to be fed to ConnectionParameters::max_streams() if the connection has not been created yet. That is a matter for the neqo glue code in Firefox.

In terms of spelling, this can use a better name than the one in the WT spec. set_active_streams or increase_max_active_streams...

[jesup]

This PR is part of a stack of 13 bookmarks:

1. trunk()
2. users/jesup/exportkey
3. users/jesup/draining
4. users/jesup/sub_protocol
5. users/jesup/sendGroup
6. users/jesup/stats
7. users/jesup/highwatermarks
8. users/jesup/sendgroup_sendorder_tracking
9. users/jesup/stats_overhead
10. users/jesup/avoid_PMTUD
11. users/jesup/anticipated_streams ← this PR
12. users/jesup/waitUntilAvailable
13. users/jesup/atomicWrite
14. users/jesup/WT_DRAIN_SESSION

---

Created with jj-stack

[jesup]

Perhaps this is closer to what you expected

[github-actions]

Failed Interop Tests

None ❓

All results

Succeeded Interop Tests

QUIC Interop Runner, client vs. server

neqo-pr as client

None ❓

neqo-pr as server

None ❓

Unsupported Interop Tests

QUIC Interop Runner, client vs. server

neqo-pr as client

None ❓

neqo-pr as server

None ❓