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

[s7r]

Hi,

teor wrote:
> 
> On 11 Dec 2017, at 09:25, nusenu <nusenu-lists at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171211/95274441/attachment-0001.sig>