[tor-dev] How about capping single operators to max. 10% exit capacity of the network?

[nusenu]

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

[teor]

Post by nusenu
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/BandwidthAuthorityMeasurements#DoesBandwidthAuthorityLocationMatter

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.

Post by nusenu
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.

Post by nusenu
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.

Post by nusenu
[1] https://lists.torproject.org/pipermail/tor-dev/2016-March/010653.html

T

[nusenu]

Post by teor

Post by nusenu
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.

Post by teor
How do you define an "operator"?

Lets use "family" that is be more clear.

Post by teor
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.

Post by teor
I thought we generally asked operators to keep it to 5%?
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.

Post by teor
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

[teor]

Post by nusenu

Post by teor
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

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

[s7r]

Hi,

Post by teor

Post by nusenu

Post by teor
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

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.

[teor]

Post by s7r
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
------------------------------------------------------------------------

[nusenu]

Post by 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

[teor]

Post by nusenu
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