Opened 5 years ago

Last modified 2 years ago

#13976 new defect

Simplify adjustment of consensus speed in testing tor networks

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: lorax, chutney, testing, tor-relay, robustness
Cc: rl1987, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by teor)

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) 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
TestingClientMaxIntervalWithoutRequest 1 5 600 Quadratic Scaling Between Minimum and Default based on (TestingOverallConsensusInterval2)/(Default2) 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

Child Tickets

TicketStatusOwnerSummaryComponent
#14034newMake TestingDirAuthVoteGuard/Exit/HSDir and AssumeReachable less essential in test networksCore Tor/Tor

Change History (19)

comment:1 Changed 5 years ago by teor

Description: modified (diff)

Fix table header formatting

comment:2 Changed 5 years ago by teor

Description: modified (diff)

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

comment:3 Changed 5 years ago by teor

This would be a great contribution to fixing #13823 in a single option.

The changes in #13929 and #13963 means we don't need to configure anything special for authority reachability testing and client/relay consensus caching, respectively.

comment:4 Changed 5 years ago by teor

Description: modified (diff)

Simplify TestingServerDownloadSchedule and TestingServerConsensusDownloadSchedule.
0, V3AuthVotingInterval/2 seems to work fine, so why overcomplicate things?

Version 0, edited 5 years ago by teor (next)

comment:5 Changed 5 years ago by teor

Parent ID: #13718#14034

This is not required for #13718, but it might be nice eventually, if we can decide on a canonical set of options that need to change to adjust the consensus speed.

But we should complete #14034 first, as it may impact the final set of options.

comment:6 Changed 5 years ago by teor

Description: modified (diff)

Add TestingClientMaxIntervalWithoutRequest per #14067 as a quadratically scaled value
Reduce Testing*DownloadSchedule to V3AuthVotingInterval/4 per #14067

comment:7 Changed 5 years ago by teor

Description: modified (diff)

It's actually 12 parameters now

comment:8 Changed 5 years ago by teor

Parent ID: #14034

comment:9 Changed 5 years ago by teor

This relies on #14034 being completed, as the options seem to change each time I work on chutney bootstrapping.

comment:10 Changed 5 years ago by nickm

Milestone: Tor: 0.2.???

comment:11 Changed 4 years ago by teor

See #16386 for additional options around bandwidth reporting.

comment:12 Changed 4 years ago by teor

Keywords: SponsorS added

comment:13 Changed 4 years ago by nickm

Keywords: SponsorS removed
Sponsor: SponsorS

Bulk-replace SponsorS keyword with SponsorS sponsor field in Tor component.

comment:14 Changed 4 years ago by isabela

Severity: Normal
Sponsor: SponsorSSponsorS-can

comment:15 Changed 3 years ago by nickm

Keywords: SponsorS-deferred added
Sponsor: SponsorS-can

Remove the SponsorS status from these items, which we already decided to defer from 0.2.9. add the SponsorS-deferred tag instead in case we ever want to remember which ones these were.

comment:16 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:17 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:18 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:19 Changed 2 years ago by nickm

Keywords: testing tor-relay robustness added; SponsorS-deferred removed
Note: See TracTickets for help on using tickets.