Skip to content

Configurable pacing rate modes via TransportConfig#2543

Open
stablebits wants to merge 1 commit intoquinn-rs:mainfrom
stablebits:pacing-rate-mode
Open

Configurable pacing rate modes via TransportConfig#2543
stablebits wants to merge 1 commit intoquinn-rs:mainfrom
stablebits:pacing-rate-mode

Conversation

@stablebits
Copy link

Add PacingRateMode enum to control rate calculation:

  • RttDependent: rate = cwnd × 1.25 / RTT (default, standard QUIC)
  • Fixed: constant bytes/sec rate, ignoring RTT and cwnd
  • RttDependentWithFloor: max(floor, cwnd × 1.25 / RTT)

Fixed and RttDependentWithFloor are useful for latency-sensitive high-RTT connections.

With default Quinn's RTT-dependent pacing, cwnd bytes worth of traffic are spread over 80% of the RTT window. This approach doesn't impact overall throughput for large downloads, but it does impact latency. For example, given two connections with RTT of 10ms and 100ms sending 128K of data, and assuming both congestion and flow control allow this in 1 RTT, it will take 13ms (5ms one-way + 8ms pacing) and 130ms (50ms one-way + 80ms pacing) respectively until the last byte is delivered to the server. High-RTT clients are penalized twice: once by RTT, and again by the slower pacing rate.

With fixed-rate pacing (Fixed(rate)), both connections use the same pacing rate, so the delivery spread is independent of RTT.

Add PacingRateMode enum to control rate calculation:
- RttDependent: rate = cwnd × 1.25 / RTT (default, standard QUIC)
- Fixed: constant bytes/sec rate, ignoring RTT and cwnd
- RttDependentWithFloor: max(floor, cwnd × 1.25 / RTT)

Fixed and RttDependentWithFloor are useful for latency-sensitive
high-RTT connections. With default Quinn's RTT-dependent pacing,
cwnd bytes worth of traffic are spread over 80% of the RTT window.
This approach doesn't impact overall throughput for large downloads,
but it does impact latency. For example, given two connections
with RTT of 10ms and 100ms sending 128 transactions, and assuming both
congestion and flow control allow this in 1 RTT, it will take 13ms and
130ms (50ms one-way plus 80ms pacing) respectively for these clients
to deliver the same data.  High-RTT clients are penalized twice:
once by RTT, and again by the slower pacing rate.
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.

1 participant