[network-health] Large ASes and Operators

Georg Koppen gk at torproject.org
Wed Feb 19 12:25:29 UTC 2020


teor:
> Hi Network Health team,
> 
> A relay operator recently raised some concerns about a large exit
> operator on the tor-relays list:
> https://lists.torproject.org/pipermail/tor-relays/2020-February/018151.html
> 
> I did some analysis of the largest ASes:
>  * 23% of guards and 22% of middles (Hetzner)
>  * 16% of guards and 12% of middles (OVH)
>  * 10% if guards (Online)
>  * 20% of exits  (Joshua Peter McQuistan)
>  https://metrics.torproject.org/rs.html#aggregate/as
> 
> I think the "Joshua Peter McQuistan" AS is all one operator.
> 
> I've opened this ticket to check for bandwidth authority configuration
> or location issues:
> 
> Are bandwidth authorities concentrating too much bandwidth in one area?
> https://trac.torproject.org/projects/tor/ticket/33351
> 
> I've also opened this ticket to check for sbws bugs:
> 
> Is sbws weighting some relays too high?
> https://trac.torproject.org/projects/tor/ticket/33350

Thanks for opening those tickets. Yes, I'd be happy if we could get some
data shading light on those questions. This could be step 0 before even
thinking about imposing some limits on bandwidth contributions by a
single relay operator.

> Ultimately, I think the answer is "Let's help people run more exits."

Yes, agreed. Or more relays in general if we are worried about Guard
concentration as well.

> (After we finish Sponsor 55, maybe our next step should be IPv6-only
> bridges and exits.)
> 
> I'm not sure if you want to impose some kind of limits on ASes or
> operators in the meantime. I suggest that 20% of Guards, Middles, or
> Exits is a useful limit.

Hrm. I am not convinced yet we should do that. I fear, for one, that
this is a deep rabbit hole which is kind of hard to analyze, in
particular regarding collateral damage.

Then there is the potential "We need more relays ... but not from you!"
message[1] we'd need to avoid which seems already hard to accomplish.

What's even more troublesome, though, is that a cap adds the additional
uncertainty for the operator whether their contributions are really
valuable throughout the whole duration they spend time, energy, and
money helping us: you might be running 19% at some point in time but due
to changes in the network that are out of your control you are suddenly
above the 20% mark the other day.

So, all in all I'd be more interested in seeing some progress on the
tickets you opened (and similar ones) than spending time and energy
thinking about the right limits. We *might* be in the situation that we
need to think about that at some point in the future (but I hope we
don't), but I'd say it's not now. :)

Georg

[1]
https://lists.torproject.org/pipermail/tor-relays/2020-February/018157.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/network-health/attachments/20200219/aff65c45/attachment.sig>


More information about the network-health mailing list