Simplify adjustment of consensus speed in testing tor networks
In order to adjust the consensus speed in a tor network, we need to configure at least 12 torrc options across authorities, relays, and clients. These options have complex timing interrelationships.
rl1987 suggested that we add a single "make it faster by X times" parameter that modifies all of these at once.
If I were using chutney, I would prefer a parameter that changes the length of the consensus cycle to a specified number of seconds. (What does 0.1x mean? And reaching the minimums would require fractions like 0.0028.) But the basic idea is still the same.
I believe the options we would need to modify are:
= Option = | = Minimum = | = Testing = | = Default = | = Suggested = | = Constraints = |
---|---|---|---|---|---|
V3AuthVotingInterval | 10 (after #13718 (moved)) | 300 | 3600 | Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default | Must be strictly more than twice (V3AuthVoteDelay + V3AuthDistDelay) |
TestingV3AuthInitialVotingInterval | 5 (after #13718 (moved)) | 150 (after #13718 (moved)) | 1800 | V3AuthVotingInterval/2 | Must be strictly more than (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after #13718 (moved), otherwise twice that) |
V3AuthVoteDelay | 2 | 20 | 300 | Linear Scaling Between Minimum and Default based on TestingOverallConsensusInterval/Default V3AuthVotingInterval | See Above |
TestingV3AuthInitialVoteDelay | 2 | 20 | 300 | V3AuthVoteDelay | See Above |
V3AuthDistDelay | 2 | 20 | 300 | V3AuthVoteDelay | See Above |
TestingV3AuthInitialDistDelay | 2 | 20 | 300 | V3AuthDistDelay | See Above |
TestingClientMaxIntervalWithoutRequest | 1 | 5 | 600 | Quadratic Scaling Between Minimum and Default based on (TestingOverallConsensusInterval^2)/(Default^2) | None |
TestingServerDownloadSchedule | 0 | 0, 0, 0, 5, 10, 15, 20, 30, 60 | 0, 0, 0, 60, 60, 120, 300, 900, 2147483647 | 0, V3AuthVotingInterval/4 | None |
TestingClientDownloadSchedule | 0 | 0, 0, 5, 10, 15, 20, 30, 60 | 0, 0, 60, 300, 600, 2147483647 | TestingServerDownloadSchedule | None |
TestingBridgeDownloadSchedule | 0 | 60, 30, 30, 60 | 3600, 900, 900, 3600 | TestingServerDownloadSchedule | None |
TestingServerConsensusDownloadSchedule | 0 | 0, 0, 5, 10, 15, 20, 30, 60 | 0, 0, 60, 300, 600, 1800, 1800, 1800, 1800, 1800, 3600, 7200 | TestingServerDownloadSchedule | None |
TestingClientConsensusDownloadSchedule | 0 | 0, 0, 5, 10, 15, 20, 30, 60 | 0, 0, 60, 300, 600, 1800, 3600, 3600, 3600, 10800, 21600, 43200 | TestingServerConsensusDownloadSchedule | None |
If we yield the default times when TestingOverallConsensusInterval 3600
, then some typical values would be:
= Option = | = Minimum = | = Testing = | = Turbo (2x) = | = Default = |
---|---|---|---|---|
TestingOverallConsensusInterval | 10 | 300 | 1800 | 3600 |
Scaled V3AuthVotingInterval | 10 | ((300-10) * (3600-10) / (3600-10)) + 10 = 300 | ((1800-10) * (3600-10) / (3600-10)) + 10 = 1800 | ((3600-10) * (3600-10) / (3600-10)) + 10 = 3600 |
Comparable V3AuthVotingInterval | 10 | 300 | N/A | 3600 |
Scaled V3AuthVoteDelay | 2 | ((300-2) * (300-10) / (3600-10)) + 2 = 26 | ((300-2) * (1800-10) / (3600-10)) + 2 = 150 | ((300-2) * (3600-10) / (3600-10)) + 2 = 300 |
Comparable V3AuthVoteDelay | 2 | 20 | N/A | 300 |
Scaled TestingClientMaxIntervalWithoutRequest | 1 | ((600-1) * (300-10)^2 / (3600-10)^2) + 1 = 5 | ((600-1) * (1800-10)^2 / (3600-10)^2) + 1 = 150 | ((600-1) * (3600-10)^2 / (3600-10)^2) + 1 = 600 |
Comparable TestingClientMaxIntervalWithoutRequest | 1 | 5 | N/A | 600 |
These look good, although we'd also need to make sure that any scaling didn't drop the values below the absolute minimums. This should probably be clipped automatically, so TestingOverallConsensusInterval 0
makes sense as "go as fast as you can".
<rl1987> my idea: what about having a configurable parameter that makes consensus happen faster by, say, 100 times?
<teor> rl1987: you mean, V3AuthVotingInterval, TestingV3AuthInitialVotingInterval, TestingV3AuthInitialVoteDelay, V3AuthVoteDelay, TestingV3AuthInitialDistDelay, V3AuthDistDelay, TestingServerDownloadSchedule
<teor> Unfortunately, the behaviour is a little too complex to just say, "make it very very fast"
<teor> I've basically reduced those parameters to their minimums, and patched tor when that didn't work as I thought it should
<rl1987> I meant "make it faster by X times"
<rl1987> if the entire lifecycle takes 6 hours, maybe we can have a parameter that forces it to take 6 hours / X
<rl1987> not sure how feasible is that.
<teor> Hmm, I think we'd be dividing too many things by that number
<rl1987> would it cause any trouble, if they were getting proportionally smaller?
<teor> Hmm, there's some things that have minimum times, and I've already set them to that to get it to work in under a minute
<teor> Perhaps we could scale up between that and the default hour-long interval
<teor> i.e. the minimum consensus time is 10 seconds, the default is 3600 seconds, let's have a parameter that scales up proportionally
<teor> or, the minimum voting and distribution delays are 2 seconds, the defaults are 300 seconds, ...
<teor> I'm not sure how to handle TestingServerDownloadSchedule and TestingClientDownloadSchedule
<teor> They look like: TestingServerDownloadSchedule 10, 2, 2, 5
<teor> Perhaps we define that as: <consensus interval>, <vote interval>, <dist interval>, <consensus interval>/2
<teor> Sure. I will log a lorax on your last suggestion
<rl1987> nice.
<rl1987> not sure if the idea is very useful, though.
<rl1987> but I would like it to be considered.
<teor> Sure is a lot nicer than having to set 6-8 separate parameters