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/BerlinRelayOperatorsMeetupJul18
but no public follow-up since then.
It's weird because nobody asked us, whereas the IP assignments clearlypoint to us (and the meeting even happened in a space I am responsiblefor)...
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.)
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% :
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:
- 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:
(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:1084200B44021D308EA4253F256794671B1D099A
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 timeago, but ultimately it is up to individual operators. I have no reasonto doubt the legimitate interest of nifty to simply support the Tornetwork. There used to be times when single operators were in control of80% 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 seeeven 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