Use consensus parameters from network data descriptors

[sporksmith]

@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]

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]

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: https://github.com/shadow/tornettools/blob/90c0679ada7283af7f9d385ba419c1b963c8dc8b/tornettools/generate_tor.py#L220-L256

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]

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]

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]

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]

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]

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]

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