On Thu, May 25, 2017 at 08:20:16PM -0700, Arisbe wrote:
I just made an interesting observation that I thought I would share. Yesterday I started a VPS exit relay at a well known hosting company in Moldova [0]. Within 24 hours I saw the consensus weight exceed 10000. The relay is bandwidth limited to 10 MiB/s. Not that I'm complaining!
Thanks for running an exit relay!
(Using data files from https://collector.torproject.org/recent/relay-descriptors/consensuses/)
$ grep -A4 "^r TorExitMoldova" 2017-05*|grep "w " 2017-05-24-20-00-00-consensus-w Bandwidth=0 Unmeasured=1 2017-05-24-21-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-24-22-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-24-23-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-00-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-01-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-02-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-03-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-04-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-05-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-06-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-07-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-08-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-09-00-00-consensus-w Bandwidth=20 Unmeasured=1 2017-05-25-10-00-00-consensus-w Bandwidth=8460 2017-05-25-11-00-00-consensus-w Bandwidth=8460 2017-05-25-12-00-00-consensus-w Bandwidth=8180 2017-05-25-13-00-00-consensus-w Bandwidth=8180 2017-05-25-14-00-00-consensus-w Bandwidth=8180 2017-05-25-15-00-00-consensus-w Bandwidth=8180 2017-05-25-16-00-00-consensus-w Bandwidth=8180 2017-05-25-17-00-00-consensus-w Bandwidth=8180 2017-05-25-18-00-00-consensus-w Bandwidth=8180 2017-05-25-19-00-00-consensus-w Bandwidth=9670 2017-05-25-20-00-00-consensus-w Bandwidth=9670 2017-05-25-21-00-00-consensus-w Bandwidth=9670 2017-05-25-22-00-00-consensus-w Bandwidth=9670 2017-05-25-23-00-00-consensus-w Bandwidth=9670 2017-05-26-00-00-00-consensus-w Bandwidth=9670 2017-05-26-01-00-00-consensus-w Bandwidth=9670 2017-05-26-02-00-00-consensus-w Bandwidth=9670 2017-05-26-03-00-00-consensus-w Bandwidth=9670
Here's what I think happened:
A) You started up your exit relay the evening of May 24 UTC, and it published a descriptor with a tiny amount of bandwidth in it (from self-testing).
B) Somehow, it attracted a traffic flow that was very high volume. Its consensus weight was tiny, but there are millions of Tor clients, so maybe one of them chose it anyway. Or maybe the bandwidth authorities themselves added this load. I'm not sure how step 'B' happened, but however it did, your relay handled a lot of traffic, so it learned that it *could* handle a lot of traffic, so it published new relay descriptors saying that it's quite fast.
It has published three descriptors so far. The third number on the bandwidth line is its self-reported capacity:
published 2017-05-24 19:50:38 bandwidth 10485760 12582912 145408
published 2017-05-24 23:34:24 bandwidth 10485760 12582912 6487186
published 2017-05-25 15:39:43 bandwidth 10485760 12582912 11526593
C) By the time the bandwidth authorities got around to measuring it, it was already proudly self-reporting a big capacity. The way the bandwidth authorities work is that they decide a modification to the self-reported number, depending on how you perform compared to your peers who self-report a similar number. You perform about average compared to your peers, so they gave you a consensus weight that is around the number you were self-reporting.
So it begs the question: Is there not enough exit relays on the Tor network?
Well, exit relays attract traffic in a very different pattern than guard relays. The blog post that we always point people to: https://blog.torproject.org/blog/lifecycle-of-a-new-relay has to do with how a fast non-exit relay will grow over time.
So it is much more normal for your consensus weight to grow quickly for an exit relay. (Well, expected. It's hard to say what is normal with the weird broken design that is the bandwidth authority subsystem these days. :)
As for whether there are not enough exit relays... always! :) We actually have about a third of the capacity of the network in Exits right now, so from a load balancing perspective, it's not a disaster, since clients avoid using the exit relays for any other positions in their circuits, and it works out ok. But from the perspective of resistance against correlation attacks, which is largely a function of diversity of entry points and exit points, then having only 1/3 of the network as a possible exit point means things aren't as good as they could be.
Hope that helps, --Roger