Skip to content

Conversation

@gregor-cf
Copy link
Contributor

These stats would be really helpful for debugging issues we're seeing in prod.

These stats would be really helpful for debugging issues we're seeing
in prod.
@gregor-cf gregor-cf requested a review from a team as a code owner November 7, 2025 16:54
@LPardue
Copy link
Contributor

LPardue commented Nov 7, 2025

This seems like it is conflating two different use cases, one for general monitoring/observability of however a connection was used, another for helping applications make runtime choices.

A good rule of thumb here might be that any number that only increases goes in stats, everything else can be a direct getter

@gregor-cf
Copy link
Contributor Author

This seems like it is conflating two different use cases, one for general monitoring/observability of however a connection was used, another for helping applications make runtime choices.

A good rule of thumb here might be that any number that only increases goes in stats, everything else can be a direct getter

Is your concern with just the flow control windows in quiche::Stats? Instead of putting the window in the stats, I could also use tx_data, max_tx_data, rx_data, max_rx_data separately, then we'd have monotonically increasing values again. Alternatively, I could also remove the flow control windows from quiche::Stats but leave them in tokio_quiche's QuicheConnectionStats / AsSocketStats.

(FWIW, we already have the congestion window in quiche::PathStats (and also in AsSocketStats).

I need these stats in AsSocketStats (in some form), since we have plumbing in oxy and friends to query these stats, but don't have any plumbing to directly query the quiche connection itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants