Expose Recovery Metrics

[Haven-King]

I would like to utilize the rtt and pto metrics for a given connection in my application code.

Ideally, I would be able to simply call .rtt() or .recovery_metrics() on a Connection, similar to what Quinn exposes.

The best solution I could currently find involves implementing ExportEvent and QLog and attaching it to the listeners with with_qlog, as seen in the below minimal reproducible example:

struct MetricsLogger;

impl gm_quic::qevent::telemetry::ExportEvent for MetricsLogger {
    fn emit(&self, event: gm_quic::qevent::Event) {
        if let Ok(value) = serde_json::to_value(&event) {
            if let Some(name) = value.get("name").and_then(|v| v.as_str()) {
                if name == "quic:recovery_metrics_updated" {
                    if let Some(metrics) = value.get("data") {
                        debug!("QUIC metrics updated: {}", metrics);
                    }
                }
            }
        }
    }
}

impl gm_quic::qevent::telemetry::QLog for MetricsLogger {
    fn new_trace(&self, _vp: gm_quic::qevent::VantagePointType, _group_id: gm_quic::qevent::GroupID) -> gm_quic::qevent::telemetry::Span {
        gm_quic::qevent::telemetry::macro_support::new_span(
            Arc::new(MetricsLogger),
            HashMap::new(),
        )
    }
}

This is not ideal for several reasons, one of which being that the data field of gm_quic::qevent::Event and the qevent::quic::recovery::RecoveryMetricsUpdated fields are all private, meaning even with this somewhat indirect route of listening to events, a serialization to JSON is necessary to actually access the data.

Another alternative might be implementing my own application-level rtt calculation, but that's not ideal either since gm-quic is already measuring it.

[huster-zhangpeng]

Thanks for the suggestion! There's a key difference to consider: gm-quic supports multipath QUIC, so a connection can have multiple active paths at once, each maintaining its own RTT. This makes a single .rtt() method ambiguous—which path's metric should it return? We'd need to think through the API design here (e.g., path selection vs. aggregate metrics).

Also, I'd caution against relying on qlog for this in production. The serialization overhead can significantly impact connection performance.