[tor-bugs] #13976 [Tor]: Simplify adjustment of consensus speed in testing tor networks
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Dec 16 22:15:04 UTC 2014
#13976: Simplify adjustment of consensus speed in testing tor networks
------------------------+------------------------------
Reporter: teor | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor | Version: Tor: unspecified
Resolution: | Keywords: lorax chutney
Actual Points: | Parent ID: #13718
Points: |
------------------------+------------------------------
Old description:
> In order to adjust the consensus speed in a tor network, we need to
> configure at least 8 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)|| 300|| 3600|| Linear
> Scaling Between Minimum and Default based on
> TestingOverallConsensusInterval/Default || Must be strictly more than
> twice (V3AuthVoteDelay + V3AuthDistDelay) ||
> || TestingV3AuthInitialVotingInterval || 5 (after #13718)|| 150 (after
> #13718)|| 1800|| V3AuthVotingInterval/2 || Must be strictly more than
> (TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after
> #13718, 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'' ||
> || TestingServerDownloadSchedule || 0|| 0, 0, 0, 5, 10, 15, 20, 30, 60||
> 0, 0, 0, 60, 60, 120, 300, 900, 2147483647||
> TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay,
> TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 || ''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|| 0, 0,
> TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 || ''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||
>
> 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
> }}}
New description:
In order to adjust the consensus speed in a tor network, we need to
configure at least 8 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)|| 300|| 3600|| Linear Scaling
Between Minimum and Default based on
TestingOverallConsensusInterval/Default || Must be strictly more than
twice (V3AuthVoteDelay + V3AuthDistDelay) ||
|| TestingV3AuthInitialVotingInterval || 5 (after #13718)|| 150 (after
#13718)|| 1800|| V3AuthVotingInterval/2 || Must be strictly more than
(TestingV3AuthInitialVoteDelay + TestingV3AuthInitialDistDelay) (after
#13718, 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'' ||
|| TestingServerDownloadSchedule || 0|| 0, 0, 0, 5, 10, 15, 20, 30, 60||
0, 0, 0, 60, 60, 120, 300, 900, 2147483647||
TestingV3AuthInitialVotingInterval, 1, 1, TestingV3AuthInitialVoteDelay,
TestingV3AuthInitialDistDelay, V3AuthVotingInterval/2 || ''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|| 0, 0,
TestingV3AuthInitialVotingInterval, V3AuthVotingInterval/2 || ''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||
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
}}}
--
Comment (by teor):
Fix table header formatting
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13976#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list