mozilla / neqo

Neqo, the Mozilla Firefox implementation of QUIC in Rust
https://firefox-source-docs.mozilla.org/networking/http/http3.html
Apache License 2.0
1.85k stars 124 forks source link

expose ECN counts in connection `Stats` #2068

Closed mxinden closed 2 months ago

mxinden commented 2 months ago

I suggest we add ECN counts to the Connection's Stats struct.

https://github.com/mozilla/neqo/blob/13237c3f5a4740b81ff98094fbdf663253122c3a/neqo-transport/src/stats.rs#L113-L115

We can then expose these as Firefox Telemetry metrics through neqo_glue Http3Stats:

https://searchfox.org/mozilla-central/rev/e942f7bc56cd103bba86b396ddeba5b1ab04f1a4/netwerk/socket/neqo_glue/src/lib.rs#1548-1550

I was thinking of simply adding:

/// Whether the path is known to be ECN capable.
ecn_capable: bool,
/// Count derived from QUIC ACKs.
ecn_tx: EcnCount,
/// Count derived from IP's TOS.
ecn_rx: EcnCount,

Would you prefer exposing other metrics or alternative representations? Can you think of better names?

On the Firefox side we can then track metrics like ECT-0 / ECN-CE ratio in a Histogram on connection closing.

Before I tackle this, was it deliberately not done in https://github.com/mozilla/neqo/pull/1678 @larseggert? Any objections?

Would allow us to measure https://bugzilla.mozilla.org/show_bug.cgi?id=1902065.

larseggert commented 2 months ago

We can, but wouldn't we (maybe in addition) like to add telemetry about whether ECN was validated (or not) for the paths used during the lifetime of a connection? Aggregated mark counts over all paths are unlikely to let us derive this based on the telemetry.

Before I tackle this, was it deliberately not done in #1678 @larseggert? Any objections?

I didn't think about what kind of telemetry we wanted when I did the original PR, so no, the omission wasn't deliberate.