Scalability and Perf Board issueshttps://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues2020-02-07T18:42:29Zhttps://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/29Adaptive Stream Timeout2020-02-07T18:42:29ZMike PerryAdaptive Stream TimeoutSimilar to DNS tests, we could deploy an adaptive stream timeout using CBT style math.Similar to DNS tests, we could deploy an adaptive stream timeout using CBT style math.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/40Adblocker vs not2020-02-07T18:03:57ZMike PerryAdblocker vs notUnsurprisingly using an adblocker is faster than not using one..
How many sites already throw up a paywall for this?Unsurprisingly using an adblocker is faster than not using one..
How many sites already throw up a paywall for this?https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/10Add relay descriptor field to indicate shared link2020-02-07T18:16:56ZMike PerryAdd relay descriptor field to indicate shared linkWhen Rob did his flashflow experiment, relays that shared a machine or link with other relays got overloaded.
If we could encourage relay operators to set a flag for their multi-instance deployments, or better, auto-detect/guess and the...When Rob did his flashflow experiment, relays that shared a machine or link with other relays got overloaded.
If we could encourage relay operators to set a flag for their multi-instance deployments, or better, auto-detect/guess and then ask for confirmation, we could avoid overloading shared-link relays via either flashflow or sbws.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/6Anon creds for rate limiting and exit bridges2020-02-07T18:44:05ZMike PerryAnon creds for rate limiting and exit bridgeshttps://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/22Bootstrap improvements2020-02-07T17:27:53ZMike PerryBootstrap improvementsTor startup time is a key usability barrier. Improving cold and warm startup times will make users happier and more likely to use Tor.Tor startup time is a key usability barrier. Improving cold and warm startup times will make users happier and more likely to use Tor.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/32Circuit Build Timeout tuning2020-02-07T17:49:11ZMike PerryCircuit Build Timeout tuningIf we have onionperf instances that support guards, we can experiment with different CBT cutoffs.If we have onionperf instances that support guards, we can experiment with different CBT cutoffs.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/2Circuit migration (confux + reliability)2020-02-07T18:07:31ZMike PerryCircuit migration (confux + reliability)https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/41Conflux (unreliable version)2022-01-24T16:51:22ZMike PerryConflux (unreliable version)Conflux without a reconnection window will reduce network reliability, but improve throughput.
It may increase latency due to circuit setup, if circuits can't be pre-built.
It may also provide traffic analysis resistance benefits.Conflux without a reconnection window will reduce network reliability, but improve throughput.
It may increase latency due to circuit setup, if circuits can't be pre-built.
It may also provide traffic analysis resistance benefits.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/1Congestion Control2020-07-09T20:14:22ZMike PerryCongestion Controlhttps://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/17Consensus param for Fast cutoff2020-07-09T20:14:26ZMike PerryConsensus param for Fast cutoffThe Fast cutoff is currently hard-coded. If we made a consensus param for this value, we could reduce consensus size and also improve long-tail performance by eliminating slow relays.The Fast cutoff is currently hard-coded. If we made a consensus param for this value, we could reduce consensus size and also improve long-tail performance by eliminating slow relays.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/16Consensus param for Guard cutoff2020-02-07T18:20:53ZMike PerryConsensus param for Guard cutoffIf we made the Guard cutoff into a consensus parameter, we could tune the number of guards to better load balance the network and eliminate bottleneck guards.If we made the Guard cutoff into a consensus parameter, we could tune the number of guards to better load balance the network and eliminate bottleneck guards.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/18Consensus params for flow control window2020-02-07T18:21:31ZMike PerryConsensus params for flow control windowIf we made consensus params for our SENDME refill amount and initial window sizes, we could see if various defaults have better latency and throughput characteristics.If we made consensus params for our SENDME refill amount and initial window sizes, we could see if various defaults have better latency and throughput characteristics.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/20Deploy GuardFraction Balancing2020-02-07T18:30:17ZMike PerryDeploy GuardFraction BalancingGuardfraction compensates for our guard rotation period by adjusting load balancing weights based on how long a relay has been a guard.
However, the statekeeping required for this is done in external scripts that are hard to use/deploy/...Guardfraction compensates for our guard rotation period by adjusting load balancing weights based on how long a relay has been a guard.
However, the statekeeping required for this is done in external scripts that are hard to use/deploy/maintain.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/11DNS test predicted circuits2020-02-07T18:15:35ZMike PerryDNS test predicted circuitsArthur and Dennis have detected that some long tail of exits/relays are really bad for unknown reasons. Sometimes this is just DNS config, but there are other things beyond that.
We could DNS test our circuits and toss out the slowest 5...Arthur and Dennis have detected that some long tail of exits/relays are really bad for unknown reasons. Sometimes this is just DNS config, but there are other things beyond that.
We could DNS test our circuits and toss out the slowest 5%, via a mechanism similar to CBT math. We don't really need to toss out a lot of circuits via this mechanism, as something like 1% or less of circuits have this problem. But the ones that do have it delay page load by 6 seconds or more.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/33Evaluate shadow models2020-02-07T18:36:07ZMike PerryEvaluate shadow modelsWhat is the smallest, lowest-resource shadow model that can reproduce various experimental results from the literature and the live network?What is the smallest, lowest-resource shadow model that can reproduce various experimental results from the literature and the live network?https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/39EWMA Tuning2020-02-10T22:06:26ZMike PerryEWMA Tuninghttps://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/34Exit scanning for misconfig failures2020-02-07T17:53:21ZMike PerryExit scanning for misconfig failuresSome exits fail because of poor config. We can scan for them and reach out to operators to improve things.Some exits fail because of poor config. We can scan for them and reach out to operators to improve things.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/30Filter out various relays from onionperf results2020-02-07T18:37:32ZMike PerryFilter out various relays from onionperf resultsIf we filter out all onionperf paths that contain 0.2.9 relays (pre-KIST), or change the Fast cutoff, or change the Guard cutoff by filtering paths, what happens to the results?
In this way we can evaluate the impact of these changes on...If we filter out all onionperf paths that contain 0.2.9 relays (pre-KIST), or change the Fast cutoff, or change the Guard cutoff by filtering paths, what happens to the results?
In this way we can evaluate the impact of these changes on the network perf before rolling out any actual changes.https://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/42FlashFlow2020-05-20T05:50:14ZMike PerryFlashFlowhttps://gitlab.torproject.org/mikeperry/scalability-and-perf-board/-/issues/36Flashflow 20 second flood test2020-02-07T18:38:47ZMike PerryFlashflow 20 second flood test