mirrors/arti.git/crates/tor-proto/src/congestion, branch arti-v1.4.5mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.52025-06-27T14:16:16Zproto: Make RttEstimator::{ewma,min}_rtt_usec() return `Option`.2025-06-27T14:16:16ZGabriela Moldovangabi@torproject.org2025-06-25T18:58:50Zurn:sha1:1e4a9161e78b78aadbe777cd5e4991a2582c8918
A `None` value signals to the conflux code to know to fall back on the
initial RTT of the circuit.
Without this change, the conflux switching logic is broken as we end up
staying on the leg with the best initial RTT forever (the other leg is
never picked, because its `ewma_rtt()` is stuck on `u32::MAX`, and never
updated as we never send on it).
proto: Rewrite can_crosscheck_with_current_estimate for clarity.2025-06-25T16:21:46ZGabriela Moldovangabi@torproject.org2025-06-25T16:04:32Zurn:sha1:65d565ccfe7880ab0e3b6ba70c1f822ace224246
The expanded expression makes it easier to see that
`can_crosscheck_with_current_estimate()` can never return `true` if
`self.ewma_rtt` is `None`, and that the `expect()` from
`is_clock_stalled()` cannot panic.
proto: Make RTT estimates default to None (fmt).2025-06-25T16:21:46ZGabriela Moldovangabi@torproject.org2025-06-25T16:03:59Zurn:sha1:2c061d5589858a73539a1a078f993071103574a5proto: Make RTT estimates default to None.2025-06-25T16:21:46ZGabriela Moldovangabi@torproject.org2025-06-25T15:43:45Zurn:sha1:1a901b349a53b3a625b76af923324da90a39a82b
The `RttEstimator` now uses `None` to represent not-yet-measured RTTs.
Previously, all the measured RTTs defaulted to 0, in contradiction with
the `RttEstimator::{min,ewma}_rtt_usec()` docs, which state that both
functions are supposed to return `u32::MAX` if there is no estimate.
Closes #2049
tor-proto: Add an accessor for the cc algorithm.2025-06-11T18:02:47ZGabriela Moldovangabi@torproject.org2025-03-21T18:27:39Zurn:sha1:3637434be521fd83849fa836e781a198419f8bb6
Conflux is only supported when prop324 congestion control is enabled, so
we need an accessor for the cc algorithm of a given circuit hop in order
for the conflux code to be able to check *which* cc algorithm is in use.
tor-proto: Remove no-longer needed clone()s.2025-06-11T17:48:35ZGabriela Moldovangabi@torproject.org2025-03-21T18:17:24Zurn:sha1:2f332ad090fef8d333e179be33deadaeb39f4c13
This doesn't really change anything, but removing the `.clone()` makes
it a bit more obvious that copying the `*Params` is a lightweight
operation.
tor-proto: Derive Copy for FixedWindowParams.2025-06-11T17:40:46ZGabriela Moldovangabi@torproject.org2025-03-21T18:26:50Zurn:sha1:d9adad6d45b1ed7e965a01e83a6c6c751c7c32c8tor-proto: Derive Copy for VegasParams.2025-06-11T17:15:00ZGabriela Moldovangabi@torproject.org2025-03-21T18:16:30Zurn:sha1:601f3a65f2cdb11f2b3313f03c671cdb6b789716proto: Refactor cc fallback.2025-06-10T15:52:28ZNick Mathewsonnickm@torproject.org2025-06-05T16:38:03Zurn:sha1:fef3034648dede7cc5fb2d698f2825e44144fe24
The fallback CC algorithm is _always_ fixed-window, and we should only
use it when the selected CC algorithm is not supported.
Move responsibility for choosing extensions into tor-proto2025-06-10T15:52:28ZNick Mathewsonnickm@torproject.org2025-06-05T16:23:51Zurn:sha1:11fe4bb4d74e4f936bc360f6b5c5cf539e94b99c
Now tor-circmgr no longer needs to check which Protover capabilities
are enabled, or construct a separate CircParameters for each hop.
Instead, tor-proto decides whether to use the fallback CC mode,
based on whether the target supports FLOWCTRL_CC.
Closes #1967.