How about capping single operators to max. 10% exit capacity of the network?
Hi, since a single operator now controls more than 10% of the tor network's exit capacity I wanted to bring this up here (again [1]). What do you think about capping single operators (family) to 10% exit capacity and 5% for guard operators? regards, nusenu [1] https://lists.torproject.org/pipermail/tor-dev/2016-March/010653.html -- https://mastodon.social/@nusenu twitter: @nusenu_
On 11 Dec 2017, at 06:33, nusenu <nusenu-lists@riseup.net> wrote:
Hi,
since a single operator now controls more than 10% of the tor network's exit capacity
Or rather, do they control more than 10% of the Tor Network's consensus weight? Consensus weight is measured from 5 bandwidth scanners in North America (3) and the Western EU (2), to 5 bandwidth servers in North America (2), the Western EU (2), South America (0.5), and Asia (0.5). Bandwidth server locations primarily affect how exits are weighted. One thing we could to do resolve this weighting issue is to reconfigure a majority of bandwidth scanners to use a CDN with points of presence around the world as a bandwidth server. They could keep their existing bandwidth servers as well. This would also be a more accurate measurement of actual client experience, as clients are fairly likely to be accessing a CDN for most websites. (The majority of Tor traffic is web traffic, and most of it goes to reasonably popular domains.) Here's how we think that would affect measured bandwidth, in detail: https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurem... The next step towards making this change is to finish the current parallel bandwidth authority tests, and start testing the Fastly CDN as one of the set of bandwidth servers: https://trac.torproject.org/projects/tor/ticket/24506 I also think Micah experimented with fastly when longclaw was a bandwidth authority. So any bandwidth authority operator could just add a CDN, and see how it goes. That would be faster, and minimal risk, because the existing bandwidth server would still be used as well.
I wanted to bring this up here (again [1]).
For those not clicking links, this email refers to a suggested scheme where we automatically limit operators, ASs, and single relays to a bandwidth cap. How do you define an "operator"? How many operators would this affect over the past few years? Using a particular situation to make a change like this, typically makes for poor design and poor policy. Because people inevitably ask: Which operator? And then their opinions about the particular operator get confused with their opinions about the general idea of limiting operators. I thought we generally asked operators to keep it to 5%? Then we ask large operators to support other organisations once they reach 5%, so everyone can gradually move beyond their current capacity. I'm not yet convinced we need a hard limit. I think social means are sufficient for now. And I think we should focus our efforts on expanding the pool of exits, and improving bandwidth measurement, rather than limiting operators who are helping the network. (New automatic limits will likely be seen as a rejection of someone's contribution, so they should be handled very carefully.) If we must do this, let's do it manually, after contacting the operator.
What do you think about capping single operators (family) to 10% exit capacity and 5% for guard operators?
How many operators would this affect over the past few years? Here be dragons - see above.
[1] https://lists.torproject.org/pipermail/tor-dev/2016-March/010653.html
T
since a single operator now controls more than 10% of the tor network's exit capacity
Or rather, do they control more than 10% of the Tor Network's consensus weight?
I'm referring to exit probability.
How do you define an "operator"?
Lets use "family" that is be more clear.
How many operators would this affect over the past few years?
From the top of my head I know about two but I didn't parse historic data to be able to give a more precise answer.
I thought we generally asked operators to keep it to 5%?
Yes I'm aware of the discussion on tor-relays@ where Roger said:
I think 5% exit share is fine, and 10% is probably a bit too high.
That means as you grow past 5%, you should work with the other big exit relay operator groups
but operators have no effective means in controlling their own share, if for example another big operator disappears.
And I think we should focus our efforts on expanding the pool of exits, and improving bandwidth measurement, rather than limiting operators who are helping the network. (New automatic limits will likely be seen as a rejection of someone's contribution, so they should be handled very carefully.)
I see your point. Also note that there are operators that would actually appreciate such a limit because they do not want to run more than X% (see tor-relays@). thanks for your reply, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_
On 11 Dec 2017, at 09:25, nusenu <nusenu-lists@riseup.net> wrote:
And I think we should focus our efforts on expanding the pool of exits, and improving bandwidth measurement, rather than limiting operators who are helping the network. (New automatic limits will likely be seen as a rejection of someone's contribution, so they should be handled very carefully.)
I see your point. Also note that there are operators that would actually appreciate such a limit because they do not want to run more than X% (see tor-relays@).
Automatic limits are also a denial of service risk for the entire network. If we implement them poorly, they could cause a cascade effect that pushes clients onto overloaded relays until they go down. For that reason alone, I'm not convinced this is a good idea. (I think we need a better design that separates load-balancing and security parameters. This is an area that needs further research.) T
Hi, teor wrote:
On 11 Dec 2017, at 09:25, nusenu <nusenu-lists@riseup.net> wrote:
And I think we should focus our efforts on expanding the pool of exits, and improving bandwidth measurement, rather than limiting operators who are helping the network. (New automatic limits will likely be seen as a rejection of someone's contribution, so they should be handled very carefully.)
I see your point. Also note that there are operators that would actually appreciate such a limit because they do not want to run more than X% (see tor-relays@).
Automatic limits are also a denial of service risk for the entire network.
If we implement them poorly, they could cause a cascade effect that pushes clients onto overloaded relays until they go down.
For that reason alone, I'm not convinced this is a good idea.
(I think we need a better design that separates load-balancing and security parameters. This is an area that needs further research.)
I fully agree with teor here -- this is indeed something not to play with. Besides teor's perfect valid technical reason, there's also a game reason that such an implementation will only work on operators or organizations that correctly configure MyFamily, which are assumed to be honest until proven guilty, since they configure MyFamily and advertise all their relays in the first place. Hostile operators or organizations of course do not and will not configure MyFamily correctly if this would be implemented to avoid the threshold. I do understand that some operators are particularly concerned about how much % they operate, but this can be lowered if too high for example by setting RelayBandwidthRate, option which is ready and working and doesn't add extra complications and side effects.
On 11 Dec 2017, at 10:56, s7r <s7r@sky-ip.org> wrote:
I do understand that some operators are particularly concerned about how much % they operate, but this can be lowered if too high for example by setting RelayBandwidthRate, option which is ready and working and doesn't add extra complications and side effects.
If the concern is seeing the traffic of too many clients, then use MaxAdvertisedBandwidth. That way, fewer clients will choose the relay in their paths, but the ones that do get the entire bandwidth of the relay. (And lower latency.) If the concern is seeing too much Tor network data, then use RelayBandwidthRate. (This is also an area that needs more research: is it the volume of network data that's bad, or the number of clients. I suspect it's the number of clients.) T -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
teor:
Automatic limits are also a denial of service risk for the entire network.
If we implement them poorly, they could cause a cascade effect that pushes clients onto overloaded relays until they go down.
For that reason alone, I'm not convinced this is a good idea.
That is indeed a good point. I agree that relative caps would be dangerous in that regard. Absolute single relay cw caps do not have that problem and would prevent insane cw values like >800000. I'll setup automatic notifications if certain thresholds are reached. thanks for your feedback, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_
On 12 Dec 2017, at 07:29, nusenu <nusenu-lists@riseup.net> wrote:
Absolute single relay cw caps do not have that problem and would prevent insane cw values like >800000.
I'll setup automatic notifications if certain thresholds are reached.
If we can come up with a threshold that would apply for the next 5-10 years, we could add a consensus weight limit to tor authority votes, or to the bwauth code. T
participants (3)
-
nusenu -
s7r -
teor