mozilla/neqo - CodSpeed

neqo

Blog Docs Changelog

Performance History

Latest Results

Add Connection::set_remote_max_streams to raise the incoming stream limit Lets a caller raise the connection's own MAX_STREAMS advertisement above the transport-parameter-configured default, for cases like WebTransport's anticipated-streams API where an application knows ahead of time that it wants more concurrency than the default allows. Monotonic: lowering the value later has no effect, since QUIC stream limits can only increase. zero_rtt_rejected's assertion that the limit matches the configured transport parameter no longer holds once a caller can raise it before the handshake confirms, which is exactly when the anticipated-streams API supplies it; relax it to allow anything at or above the default.

users/jesup/add_remote_max_streams

1 day ago

WebTransport: add anticipatedConcurrentIncomingUni/BidirectionalStreams support The spec lets an application supply, at session construction, how many incoming streams of each type it expects the peer to open concurrently, so the transport can grant that much headroom up front rather than only after the peer bumps into the default limit and waits a round trip for MAX_STREAMS. webtransport_set_anticipated_incoming_{uni,bidi}_streams stores the per-session value and recomputes the connection-wide total across every not-yet-closed WebTransport session, clamped to MAX_ANTICIPATED_INCOMING_STREAMS so an application cannot ratchet the advertised limit arbitrarily high (it is monotonic and never comes back down as sessions close). The unidirectional total also adds HTTP3_UNI_CONTROL_STREAMS, since HTTP/3's own control and QPACK streams draw from the same limit. Closed sessions are excluded from the sum; sessions still negotiating are included, since that is exactly when the API supplies this value. Client-only: the anticipated-streams attributes are on the WebTransport interface, which has no server-side equivalent.

users/jesup/anticipated_incoming_streams

1 day ago

WebTransport: report the fate of outgoing datagrams via aggregate stats Adds SessionStats::datagrams_sent_outgoing/datagrams_dropped_outgoing, backed by the per-session sent count from the previous commit, so that once a session's queue is empty, every datagram a caller handed in has been counted as sent, expired or dropped exactly once. Dropped covers byte-budget evictions, datagrams refused at enqueue as the lowest priority, datagrams dropped at packet-build time as too big for the path MTU, and datagrams still queued when the session closes. The Capsule fallback counts as sent on write. close_session flushes the sent count and drops what is still queued before snapshotting the stats it returns, so the final values include the datagrams that call discards; a close or reset from the peer drops and counts the queue too. Both close paths expire stale datagrams first, so those count as expired rather than dropped. The per-tick sweep only visits the sessions the transport reports as having work.

users/jesup/report_datagrams

1 day ago

WebTransport: expose outgoing datagram queue capacity per session Add a production-facing Http3Client::webtransport_datagram_queue_capacity, so a caller (e.g. a content-process credit grant) can read a session's outgoing-datagram queue state without going through the test-only path. The underlying transport-level DatagramQueueCapacity snapshot and per-session accessor already existed but were only reachable from #[cfg(test)] code; drop that gate now that there's a real caller.

users/jesup/expose_queue_capacity

1 day ago

WebTransport: report the fate of outgoing datagrams via aggregate stats Adds SessionStats::datagrams_sent_outgoing/datagrams_dropped_outgoing, backed by the per-session sent count from the previous commit, so that once a session's queue is empty, every datagram a caller handed in has been counted as sent, expired or dropped exactly once. Dropped covers byte-budget evictions, datagrams refused at enqueue as the lowest priority, datagrams dropped at packet-build time as too big for the path MTU, and datagrams still queued when the session closes. The Capsule fallback counts as sent on write. close_session flushes the sent count and drops what is still queued before snapshotting the stats it returns, so the final values include the datagrams that call discards; a close from the peer drops the queue too. Both close paths expire stale datagrams first, so those count as expired rather than dropped. The per-tick sweep only visits the sessions the transport reports as having work.

users/jesup/report_datagrams

1 day ago

WebTransport: drop a closed session's queued datagrams on teardown A session reset by the peer leaves the stream maps via remove_extended_connect, which is the only teardown path that has both the session and the Connection the queue lives on. Drop the queue there so every path counts what was still queued as dropped and removes the per-session entry, including one re-created by a max-buffered or max-age change after the session had already closed.

users/jesup/drop_datagrams_on_teardown

1 day ago

WebTransport: add anticipatedConcurrentIncomingUni/BidirectionalStreams support The spec lets an application supply, at session construction, how many incoming streams of each type it expects the peer to open concurrently, so the transport can grant that much headroom up front rather than only after the peer bumps into the default limit and waits a round trip for MAX_STREAMS. webtransport_set_anticipated_incoming_{uni,bidi}_streams stores the per-session value and recomputes the connection-wide total across every not-yet-closed WebTransport session, clamped to MAX_ANTICIPATED_INCOMING_STREAMS so an application cannot ratchet the advertised limit arbitrarily high (it is monotonic and never comes back down as sessions close). The unidirectional total also adds HTTP3_UNI_CONTROL_STREAMS, since HTTP/3's own control and QPACK streams draw from the same limit. Closed sessions are excluded from the sum; sessions still negotiating are included, since that is exactly when the API supplies this value. Client-only: the anticipated-streams attributes are on the WebTransport interface, which has no server-side equivalent.

users/jesup/anticipated_incoming_streams

1 day ago

WebTransport: expose outgoing datagram queue capacity per session Add a production-facing Http3Client::webtransport_datagram_queue_capacity, so a caller (e.g. a content-process credit grant) can read a session's outgoing-datagram queue state without going through the test-only path. The underlying transport-level DatagramQueueCapacity snapshot and per-session accessor already existed but were only reachable from #[cfg(test)] code; drop that gate now that there's a real caller.

users/jesup/expose_queue_capacity

1 day ago

Latest Branches

-2%

Add Connection::set_remote_max_streams to raise the incoming stream limit#4010

29 days ago

3c305f6

users/jesup/add_remote_max_streams

-2%

WebTransport: add anticipatedConcurrentIncomingUni/BidirectionalStreams support#4011

29 days ago

263e7c6

users/jesup/anticipated_incoming_streams

-5%

WebTransport: report the fate of outgoing datagrams via aggregate stats#3991

23 days ago

0989fca

users/jesup/report_datagrams

© 2026 CodSpeed Technology

Home Terms Privacy Docs