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