
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><div>Hi all,</div><div><br></div></div><div dir="ltr">On 2 Jun 2019, at 05:22, Roger Dingledine <<a href="mailto:arma@torproject.org">arma@torproject.org</a>> wrote:<br></div><blockquote type="cite"><div dir="ltr"><span></span><br><span>I've been talking to a longtime exit relay operator, who is in the</span><br><span>odd position of having a good 1gbit network connection, but only one</span><br><span>IP address.</span><br><span></span><br><span>He used to push an average of 500mbit on his exit relay, but then the</span><br><span>HSDir DoS flatlined his relay for a while (!), and now, perhaps due to</span><br><span>the bwauth variability, his exit relay only recovered to maybe 200mbit.</span><br><span>He is running a second exit relay on that IP address, but also perhaps</span><br><span>due to the bwauth variability, it hasn't attracted much attention either.</span><br></div></blockquote><div><br></div><div>I'd like to confirm the problem before we make major network changes.</div><div>(And I'd like to know how widespread it is.)</div><div><br></div><div>Which bandwidth authorities are limiting the consensus weight of these</div><div>relays? Where are they located?</div><div><br></div><div>Are the relays' observed bandwidths limiting their consensus weight?</div><div><br></div><div>Here's how the operator can find out:</div><div><a href="https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow#TorNetworkLimits">https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow#TorNetworkLimits</a></div><div><br></div><div>If the relays are being measured by longclaw's sbws instance, we should</div><div>also look at their detailed measurement diagnostics.</div><div><br></div><div>longclaw's bandwidth file is available at:</div><div><a href="http://199.58.81.140/tor/status-vote/next/bandwidth">http://199.58.81.140/tor/status-vote/next/bandwidth</a></div><br><blockquote type="cite"><div dir="ltr"><span>The real answer is to fix the bandwidth measurement infrastructure.</span></div></blockquote><div><br></div><div>Do we have funding to continue to improve the bandwidth measurement</div><div>infrastructure? Or to maintain it?</div><div><br></div><div>If we don't have any grants in the pipeline, now would be a good time to</div><div>start some.</div><br><blockquote type="cite"><div dir="ltr">But</div></blockquote><blockquote type="cite"><div dir="ltr"><span>while we're patiently waiting for progress there, I've been thinking</span><br><span>to raise moria1's AuthDirMaxServersPerAddr to 4, i.e. to allow 4 relays</span><br><span>per IP address onto the network.</span></div></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><div dir="ltr"><span>I don't think it would significantly increase our risk due to Sybil</span><br><span>attacks, whereas there is a clear benefit in terms of some more 100's</span><br><span>of mbits of good exit relay capacity.</span><br><span></span><br><span>I will propose this change to the dir-auth list in a bit, but here is</span><br><span>your chance to point out surprising impacts that I haven't thought of.</span><br></div></blockquote><br><div>Splitting bandwidth between multiple relays has privacy implications,</div><div>because traffic is easier to track between instances.</div><div><br></div><div>It also increases the size of the consensus.</div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">So we should choose a value for AuthDirMaxServersPerAddr that is</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">a compromise between these competing goals.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Why is 4 better than 3 or 5?</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">T</span></div></body></html>