Statistics aggregation over irtt-client events: loss/duplicate/late accounting, RTT and one-way-delay timing, and inter-packet delay variation (IPDV), as cumulative and rolling snapshots.

Relationship to irtt-client

This crate does not open sessions or drive sockets. Feed it the ClientEvent stream produced by an irtt-client Client, AsyncClient, or managed session via StatsCollector::process, and read back a Snapshot.

Generic timing accumulation and count-window storage come from measurement-stats. TimeStats remains available from irtt_stats as a re-export. Event interpretation, IPDV pairing, loss, and snapshot reconstruction remain here.

A StatsCollector has one sequence/IPDV namespace and one packet count, both scoped to a single target. A managed session covering multiple targets needs one collector per target — as the irtt-rs CLI does — since a target's sequence numbers start over at zero and feeding two targets into one collector would pair up unrelated probes.

Retention modes

StatsConfig::finite() retains exact timing samples for its cumulative snapshot, so every metric with samples reports an exact median there — retention grows with the probe count. StatsConfig::continuous() keeps bounded running statistics instead (no exact median) plus a bounded 4096-entry adjacent-sequence IPDV store per target, for long-running or unbounded sessions. Rolling-window snapshots are always running-only and report no medians, whichever StatsConfig produced them.

An enabled time-based rolling window has no event-count cap, including in continuous mode. It expires only on new events, anchored at the maximum observed normalized timestamp, with events exactly at the cutoff retained. Retained events are replayed in arrival order; backdated events cannot move the window backwards. Reading a snapshot does not advance time. Use count-based rolling storage for a hard bound on retained events. The memory estimate excludes time-window storage.

Rolling directional loss uses the increase in the highest observed server receive count across the retained packet events in arrival order. Upstream loss is window sends minus that increase; downstream loss is the increase minus all window replies, including duplicates and untracked late replies, as in cumulative accounting. The baseline is the highest count observed before the first retained packet event, or zero if no earlier packet events existed. Each retained event keeps this prior position, so eviction cannot erase a known baseline. Reordered counts do not move the observation backwards; only matched unique replies supply counter observations, regardless of the late-reply timing policy.

Both directional packet estimates are None if the baseline or endpoint is unknown, or if time filtering excludes a packet event between retained packet events. Their percentage fields use the existing unavailable value of 0.0. Loss/warning events do not affect this interval. A boundary between a send and its reply can still produce signed estimates, and outstanding sends retain the existing provisional-loss interpretation. These are changes in observed accounting, not exact network transit loss for probes sent in a wall-clock period. Raw server_packets_received, ordinary packet counts, and cumulative loss retain their existing meanings.

Exact snapshots sort a temporary copy of each metric's retained samples, adding O(n) scratch memory and O(n log n) computation for that metric. The retention estimate is not peak snapshot or allocator accounting.

See examples/ in the repository for a runnable comparison of both modes.

Documentation

Full API documentation is on docs.rs/irtt-stats.

Project

Part of irtt-rs, an independent Rust implementation of an IRTT-compatible protocol stack.