On 9 Sep 2018, at 07:29, Moritz Bartl moritz@torservers.net wrote:
On 08.09.2018 22:19, Paul wrote: i am glad that somebody else got notice and i agree, suspecting something nasty (or highly unusual) is going on. There was a discussion about that in Berlin in July already https://trac.torproject.org/projects/tor/wiki/org/meetings/BerlinRelayOperat... but no public follow-up since then.
It's weird because nobody asked us, whereas the IP assignments clearly point to us (and the meeting even happened in a space I am responsible for)...
As far as I know, nobody asked any of the questions from the wiki on tor-relays@ (or #tor-relays). So I'll try to answer them here:
A large-scale operator (with more than 20 exit relays) was wondering about the effects of the newer tor versions and the MyFamilyconfiguration option.
After setting up the MyFamily saw a 50% drop on the number connections and the usage of the relay bandwidth;
MyFamily tells Tor clients that relays are run by the same entity. Clients avoid using more than one relay from a family in a circuit. This means that relay operators can't do end-to-end traffic correlation. (Which makes it easier for operators to refuse legal requests.)
See https://www.torproject.org/docs/tor-manual.html.en
Circuits are chosen at random. Exits are only used in the Exit position (and as HSDirs). So the it's unlikely that the bandwidth drop was caused by MyFamily. (The operator would also need to have 50% of the Guards and Middles in the Tor network, excluding any Exits.)
If the operator would like help diagnosing the issue, we'll need more information: * the identities of the relays * the dates of the drop * did the consensus weight drop as well?
This person would like to push more bandwidth and would like to find out how to better achieve this scenario;
It depends on why the bandwidth is limited.
Here are some common reasons:
Are your exits using 50% or more of their bandwidth? Good! You are providing fast, low-latency Internet access. Ideal networks have about 10% utilisation. 100% utilisation causes delays and dropped connections. Tor Exits are at about 50% : https://metrics.torproject.org/bandwidth-flags.html
Are some CPU cores maxed out? Run more Tor instances (but only 2 per IPv4).
Are the relays a long way away from the bandwidth authorities (US/DE/SV)? Get relays that are closer.
Did the bandwidth drop move the relays into a lower measurement partition? We're working on a partitionless bandwidth measurement system, sbws. We're not sure when it will be deployed, but we're hoping in 2019.
Here are some more details: https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow
The current feature for DDoS protection is really optional, or does it need to be manually enabled? (regarding the traffic drop on the relays mentioned before)
The DDoS protection is turned on in the consensus: https://consensus-health.torproject.org/#consensusparams (It is also on by default, with slightly different settings.)
There is no need to manually enable the feature. And you shouldn't turn it off, because accepting DDoS connections makes other relays slow.
There seems to be a private person who is holding this family https://metrics.torproject.org/rs.html#search/family:1084200B44021D308EA4253... and ran between 10-15% exit probability in the last six months - which i personally judge as far too high for a single person, or even an entity.
Agreed. I had a longer discussion with nifty around diversity some time ago, but ultimately it is up to individual operators. I have no reason to doubt the legimitate interest of nifty to simply support the Tor network. There used to be times when single operators were in control of 80% of the exit capacity, and we worked hard to get it more diversified. There is a lot of room for improvement, and other networks like OVH see even more Tor traffic...
I have similar conversations with nifty. I think they simply want to improve the Tor network.
I don't think asking operators to limit themselves is a good idea. Instead, we need to encourage people to run more exits. If you have time and skills, give that time to organisations that run exit relays (or run some yourself). If you have money, do the same.
Otherwise, promote their work, and make it easy for them to help the network.
T