Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use consensus parameters from network data descriptors #51

Open
sporksmith opened this issue Dec 10, 2021 · 8 comments
Open

Use consensus parameters from network data descriptors #51

sporksmith opened this issue Dec 10, 2021 · 8 comments

Comments

@sporksmith
Copy link
Contributor

@mikeperry points out that the parameters set via consensus can have a significant performance impact (particularly KISTSchedRunInterval=2).

Currently experimenting with hard coding parameters from a specific consensus, but it'd be nice if tornettools helped here. e.g. it should be straightforward to reconstruct from the consensuses we have in the staging step. Using these values in the generate step should probably be optional, and maybe off by default, since it could otherwise be surprising.

@sporksmith
Copy link
Contributor Author

sporksmith commented Dec 10, 2021

FTR here's our ad-hoc way of applying the params from the recent consensus:

for param in CircuitPriorityHalflifeMsec=30000 DoSCircuitCreationEnabled=1 DoSConnectionEnabled=1 DoSConnectionMaxConcurrentCount=50 DoSRefuseSingleHopClientRendezvous=1 ExtendByEd25519ID=1 KISTSchedRunInterval=2 NumDirectoryGuards=3 NumEntryGuards=1 NumNTorsPerTAP=100 UseOptimisticData=1 bwauthpid=1 cbttestfreq=10 hs_service_max_rdv_failures=1 hsdir_spread_store=4 pb_disablepct=0 sendme_emit_min_version=1 usecreatefast=0
do
  echo ConsensusParams $param >> $SIMDIR/conf/tor.relay.authority.torrc
done

@robgjansen
Copy link
Member

You're going to want to check that some of these options are not already listed in our existing torrc files (e.g., tor.common.torrc), because options in the torrc files will override options values listed in the consensus. For example:

torrc_file.write('TestingTorNetwork 1\n')
# Gets enabled by default when we enable TestingTorNetwork.
# We don't need it, and it uses a lot of memory.
torrc_file.write('TestingEnableCellStatsEvent 0\n')
torrc_file.write('DataDirectory .\n')
torrc_file.write('ServerDNSResolvConfFile ../../../{}/{}\n'.format(CONFIG_DIRNAME, RESOLV_FILENAME))
torrc_file.write('ServerDNSTestAddresses {}\n'.format(','.join(auth_names)))
torrc_file.write('ServerDNSAllowBrokenConfig 1\n')
torrc_file.write('ServerDNSDetectHijacking 0\n')
torrc_file.write('AssumeReachable 1\n')
torrc_file.write('NumCPUs 1\n')
torrc_file.write('Log notice stdout\n')
torrc_file.write('SafeLogging 0\n')
torrc_file.write('LogTimeGranularity 1\n')
torrc_file.write('HeartbeatPeriod 1\n')
torrc_file.write('ContactInfo https://github.com/shadow/shadow-plugin-tor/issues\n')
torrc_file.write('DisableDebuggerAttachment 0\n')
torrc_file.write('CellStatistics 0\n')
torrc_file.write('PaddingStatistics 0\n')
torrc_file.write('DirReqStatistics 0\n')
torrc_file.write('EntryStatistics 0\n')
torrc_file.write('ExitPortStatistics 0\n')
torrc_file.write('ConnDirectionStatistics 0\n')
torrc_file.write('HiddenServiceStatistics 0\n')
torrc_file.write('ExtraInfoStatistics 0\n')
torrc_file.write('CircuitPriorityHalflife 30\n')
torrc_file.write('PathBiasUseThreshold 10000\n')
torrc_file.write('PathBiasCircThreshold 10000\n')
torrc_file.write('DoSCircuitCreationEnabled 0\n')
torrc_file.write('DoSConnectionEnabled 0\n')
torrc_file.write('DoSRefuseSingleHopClientRendezvous 0\n')
torrc_file.write('ControlPort {}\n'.format(TOR_CONTROL_PORT))
torrc_file.write('GeoIPFile {}\n'.format(geoip_path or ''))
# Never load the geoipv6 file, since we don't support ipv6.
torrc_file.write('GeoIPV6File\n')

Also, I'm not sure that it makes sense to just blindly apply these in simulated networks. For example, we don't care about DoS prevention in simulated networks, and I wouldn't want our tgen clients (who model many users at once) to trigger the DoS defenses.

@sporksmith
Copy link
Contributor Author

You're going to want to check that some of these options are not already listed in our existing torrc files (e.g., tor.common.torrc), because options in the torrc files will override options values listed in the consensus.

Oh good point.

Also, I'm not sure that it makes sense to just blindly apply these in simulated networks. For example, we don't care about DoS prevention in simulated networks, and I wouldn't want our tgen clients (who model many users at once) to trigger the DoS defenses.

Also a good point, especially about potential surprising behavior with DoS prevention.

FWIW our test run with this setup looks plausible. In these graphs the "experiment" is the current run, and the "baseline" is a previous baseline run. In addition to overriding these consensus parameters, this run also switches to using network data from a flood period, so it's hard to know which to attribute the differences to. Probably worth a more careful comparison, especially before adding this as a feature in tornettools... https://gitlab.torproject.org/jnewsome/sponsor-61-sims/-/jobs/69283/artifacts/file/public/tornet.plot.pages.pdf

@sporksmith
Copy link
Contributor Author

I took a closer look at these parameters from the recent consensus.

3 of them are overridden by a torrc setting of the same name:

tor.common.torrc:DoSCircuitCreationEnabled 0
tor.common.torrc:DoSConnectionEnabled 0
tor.common.torrc:DoSRefuseSingleHopClientRendezvous 0

That's probably desirable given the point above not wanting to enable DoS mitigations. We are also setting DoSConnectionMaxConcurrentCount=50 in the conensus params above though, and that's not currently overridden by a torrc setting. According to the man page this is "The maximum threshold of concurrent connection from a client IP address", so definitely something that could interact badly with the client scaling.

Btw the man page says that if DoSConnectionMaxConcurrentCount isn't set explicitly, the default is 100. I wonder if we ought to be explicitly setting this to something like 100 * 1/process_scale. (Or maybe scale the consensus value of 50 instead of the default of 100)

@stevenengler
Copy link
Contributor

That's probably desirable given the point above not wanting to enable DoS mitigations. We are also setting DoSConnectionMaxConcurrentCount=50 in the conensus params above though, and that's not currently overridden by a torrc setting. According to the man page this is "The maximum threshold of concurrent connection from a client IP address", so definitely something that could interact badly with the client scaling.

The value of DoSConnectionMaxConcurrentCount should have no effect (that part of the code is skipped) if DoSConnectionEnabled is set to 0.

@sporksmith
Copy link
Contributor Author

The value of DoSConnectionMaxConcurrentCount should have no effect (that part of the code is skipped) if DoSConnectionEnabled is set to 0.

Ah, makes sense. Thanks!

@sporksmith
Copy link
Contributor Author

Rob points out that the torrc's do override CircuitPriorityHalflife, which overrides the consensus parameter CircuitPriorityHalflifeMsec. In this case it doesn't matter since they're getting the same value (30s vs 30000 ms), but something to keep in mind if we automate this.

@sporksmith
Copy link
Contributor Author

We should really take a look at this. In particular we need to set cc_alg=2 to enable congestion control

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants