[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #13976 [Tor]: Simplify adjustment of consensus speed in testing tor networks



#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):

 Well, that's hard to get right, as it doesn't look much different in the
 preview.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13976#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs