Overview

Provide a reusable EWMA smoothing component to enable detection of significant bitrate changes. The EWMA implementation will be used by the existing BitrateChangeDetector and can be fed samples from QUIC ConnectionStats() or other transport stats.

Motivation & Benefits

• Smooth noisy bitrate samples while keeping reasonable responsiveness to changes.
• Provide a consistent smoothing primitive that detectors can reuse across server, client, and relay contexts.
• Avoid adding transport-specific logic to the detector itself; transport connectors supply samples and the detector consumes smoothed values.

Use Case

• A QUIC connector periodically reads ConnectionStats() and estimates bps.
• The connector feeds samples to BitrateChangeDetector, which uses EWMA-smoothed values to determine significant changes.
• Consumers (routing, telemetry, priority) subscribe to detector events and react to meaningful changes rather than transient noise.

Proposed Solution (include Next Steps)

• Implement a small, well-tested EWMA utility package in Go with configurable alpha and an API suitable for concurrent use by detectors.
• Keep EWMA transport-agnostic and independent from BitrateChangeDetector; detectors may accept raw samples or smoothed values as needed.
• Default to conservative alpha and thresholds, with config available for tuning.
• Ensure deterministic behavior and easy-to-test semantics (init state, update semantics).

Alternatives Considered

• Sliding window average or median: heavier memory requirements and complexity for variable-sized windows.
• CUSUM/change-point detection: more sensitive to abrupt changes but more complex to tune; may be a future enhancement.

Related issues

#18, #62

Checklist

• I have searched existing issues
• I have read relevant documentation
• I can contribute to this feature