
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 11 Dec 2017, at 06:33, nusenu <<a href="mailto:nusenu-lists@riseup.net">nusenu-lists@riseup.net</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hi,</span><br><span></span><br><span>since a single operator now controls more than 10% of the tor network's</span><br><span>exit capacity</span></div></blockquote><div><br></div>Or rather, do they control more than 10% of the Tor Network's consensus<div>weight?<div><br><div>Consensus weight is measured from 5 bandwidth scanners in North</div><div>America (3) and the Western EU (2), to 5 bandwidth servers in North</div><div>America (2), the Western EU (2), South America (0.5), and Asia (0.5).</div><div><div><br></div><div>Bandwidth server locations primarily affect how exits are weighted.</div><div><br></div><div>One thing we could to do resolve this weighting issue is to reconfigure</div><div>a majority of bandwidth scanners to use a CDN with points of presence</div><div>around the world as a bandwidth server. They could keep their existing</div><div>bandwidth servers as well.</div><div><br></div><div>This would also be a more accurate measurement of actual client</div><div>experience, as clients are fairly likely to be accessing a CDN for most</div><div>websites. (The majority of Tor traffic is web traffic, and most of it goes to</div><div>reasonably popular domains.)</div><div><br></div><div>Here's how we think that would affect measured bandwidth, in detail:</div><div><a href="https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements#DoesBandwidthAuthorityLocationMatter">https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements#DoesBandwidthAuthorityLocationMatter</a></div><div><br></div><div>The next step towards making this change is to finish the current parallel</div><div>bandwidth authority tests, and start testing the Fastly CDN as one of the</div><div>set of bandwidth servers:</div><div><br></div><div><a href="https://trac.torproject.org/projects/tor/ticket/24506">https://trac.torproject.org/projects/tor/ticket/24506</a></div><div><br></div><div>I also think Micah experimented with fastly when longclaw was a</div><div>bandwidth authority.</div><div><br></div><div>So any bandwidth authority operator could just add a CDN, and see how</div><div>it goes. That would be faster, and minimal risk, because the existing</div><div>bandwidth server would still be used as well.</div><div><div><br></div><blockquote type="cite"><div><span>I wanted to bring this up here (again [1]).</span><br></div></blockquote><div><br></div>For those not clicking links, this email refers to a suggested scheme where<div>we automatically limit operators, ASs, and single relays to a bandwidth cap.</div><div><div><br></div><span style="background-color: rgba(255, 255, 255, 0);">How do you define an "operator"?</span><div><span style="background-color: rgba(255, 255, 255, 0);">How many operators would this affect over the past few years?</span><br><div><br></div><div>Using a particular situation to make a change like this, typically makes for</div><div>poor design and poor policy. Because people inevitably ask:</div><div>Which operator?</div><div>And then their opinions about the particular operator get confused with</div><div>their opinions about the general idea of limiting operators.</div><div><br></div><div>I thought we generally asked operators to keep it to 5%?</div><div>Then we ask large operators to support other organisations once they</div><div>reach 5%, so everyone can gradually move beyond their current capacity.</div><div><br></div><div>I'm not yet convinced we need a hard limit.</div><div>I think social means are sufficient for now.</div><div><br></div><div>And I think we should focus our efforts on expanding the pool of exits,</div><div>and improving bandwidth measurement, rather than limiting operators</div><div>who are helping the network. (New automatic limits will likely be seen</div><div>as a rejection of someone's contribution, so they should be handled very</div><div>carefully.)</div><div><br></div><div>If we must do this, let's do it manually, after contacting the operator.</div><br><blockquote type="cite"><div><span>What do you think about capping single operators (family) to 10% exit</span><br><span>capacity and 5% for guard operators?</span><br></div></blockquote><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">How many operators would this affect over the past few years?</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>Here be dragons - see above.</div><div><br></div><blockquote type="cite"><div><span>[1] <a href="https://lists.torproject.org/pipermail/tor-dev/2016-March/010653.html">https://lists.torproject.org/pipermail/tor-dev/2016-March/010653.html</a></span><br></div></blockquote><br></div></div></div></div></div></div><div>T</div></body></html>