Stats: Which ones are appropriate for Http3Transport?

[aboba]

ISSUE 2 says (referring to Stats):

"some of those are safe to expose for HTTP/2 and HTTP/3 connections (like min-RTT), while most would either result in information disclosure or are impossible to define for pooled connections."

One question this raises is whether we should remove some stats entirely for Http3Transport, or whether some stats are only returned for Http3Transport connections where pooling is not allowed.

[wilaw]

Current stats for reference

The dictionary SHALL have the following attributes:

timestamp, of type DOMHighResTimeStamp
The timestamp for when the stats are gathered, relative to the UNIX epoch (Jan 1, 1970, UTC).

bytesSent, of type unsigned long long
The number of bytes sent on the QUIC connection, including retransmissions. Does not include UDP or any other outer framing.

packetsSent, of type unsigned long long
The number of packets sent on the QUIC connection, including retransmissions.

numOutgoingStreamsCreated, of type unsigned long
The number of outgoing QUIC streams created on the QUIC connection.

numIncomingStreamsCreated, of type unsigned long
The number of incoming QUIC streams created on the QUIC connection.

bytesReceived, of type unsigned long long
The number of total bytes received on the QUIC connection, including duplicate data for streams. Does not include UDP or any other outer framing.

packetsReceived, of type unsigned long long
The number of total packets received on the QUIC connection, including packets that were not processable.

minRtt, of type DOMHighResTimeStamp
The minimum RTT observed on the entire connection.

numReceivedDatagramsDropped, of type unsigned long
The number of datagrams that were dropped, due to too many datagrams buffered between calls to datagrams' readable.

[jan-ivar]

Meeting:

May depend in allowPooling.
All definitions may need to be rewritten, e.g. should bytes sent/received include resends?
May be a security issue to expose too much data when pooling is in effect.
H2 vs H3 is going to be different.

WebSockets don't have stats, but people want them.
Stats may be more needed on dedicated connections used for e.g. media.
Useful stat ask: Max throughput achieved #21

[jan-ivar]

Meeting:

• Per-stream stats? Pros: Would be easier to expose even in pooled mode. Cons: might be super-easy to polyfill (a transform stream that counts), but if this is the only JS in an pipe solely of browser objects, a natice API might be preferable for performance.

[jan-ivar]

Meeting:

• A feeling that a PR (of any quality) might promote progress on this issue.

[jan-ivar]

Meeting:

• Count stream resets
• Focus on stats the JS could polyfill anyway.
• Maybe per-stream or per-WebTransport instance?
• Maybe return measured throughput (that could be deduced from counting anyway)
• @aboba to write up an outline of potential API

[aboba]

From RTP over QUIC Section 4.1:

"Additionally, a QUIC implementation MUST expose the recorded RTT
statistics as described in Section 5 of [RFC9002] to the application.
These statistics include the minium observed RTT over a period of
time ("min_rtt"), exponentially-weighted moving average
("smoothed_rtt") and the mean deviation ("rtt_var"). These values
are necessary to perform congestion control as explained in
Section 4.2."

[jan-ivar]

With #386 and #395 I think we can close this issue. Please reopen if you disagree.