-
Notifications
You must be signed in to change notification settings - Fork 15
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
Comments
FTR here's our ad-hoc way of applying the params from the recent consensus:
|
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: tornettools/tornettools/generate_tor.py Lines 220 to 256 in 90c0679
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. |
Oh good point.
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 |
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:
That's probably desirable given the point above not wanting to enable DoS mitigations. We are also setting Btw the man page says that if |
The value of |
Ah, makes sense. Thanks! |
Rob points out that the torrc's do override |
We should really take a look at this. In particular we need to set |
@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.The text was updated successfully, but these errors were encountered: