[tor-relays] amount of unmeasured relays continuously rising since 2 weeks

Sat May 23 20:17:03 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks for the eloquent response. Many good points made and apologies if
my comments came across as being critical of the Tor development
community. I have no plans to take down the relays I'm running any time
soon -- bwauth hiccups or not. Regardless of the current issues, I have
to say the network at large feels significantly faster and more
functional than it did a few years ago.

- ---
Julian Plamann

julian (at) amity.be
GPG: 0x96881D83

On 2015-05-23 10:56 am, s7r wrote:

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Julian

Thanks for your contribution to Tor!
Please keep them running, as much as you can. We already struggle to
(at least partially) solve the issue for the short term, by launching
more bandwidth authorities. On the long term, some research groups are
working on a better bandwidth measurement system. We are all anxiously
waiting for it, but unfortunately there is no ETA for it at this moment.

To answer your question, it's not exactly true that _current system is
clearly broken_, or totally broken. It works, but does not work 100%
(e.g. we are missing some bandwidth). It's better than going back to
self advertising bandwidth. By default (if not explicitly set a
MaxAdvertisedBandwidth in torrc), Tor will self advertise the port
speed which it sees on the server where running, which is very very
often (I could say almost) of a higher value than that server can
really handle. For example, take a VPS which has a network port of 1
gbps seen by the operating system, but it's running on a cluster with
100 another virtual machines and each is individually capped at
hypervisor lever to 10mbit. Going back to self advertised bandwidth
would assign unfair weights to some relays and cause Tor clients to
choose paths in a buggy way, we could overload the less capable relays
and cause circuit failure for clients, decreasing the Tor performance
/ user experience overall.

The bandwidth authorities are not so sensitive as directory
authorities, but a bandwidth authority is useless unless it talks to a
directory authority which is allowed to vote in the consensus. That is
why bandwidth authorities are run by the same trusted people who also
run directory authorities.

The analogy you are describing does not reflect the reality in this
situation. For the issue we are facing, no directory authority
operator has a solution, nor anyone. It's not like someone can do
something about it, but does not do it. Still, everyone is making
efforts to fix it, in the measure in which it is technically possible.
The system where we have a known number of directory authorities,
hardcoded and run by trusted people is very well researched and
studied, and it eliminates a lot of real and practicable attacks. I am
all for decentralized and distributed systems, but at this moment I
really think we are doing the best we can. Everyone would prefer Tor
to be decentralized and trustless, but this is not that simple and
cannot be done immediately. A lot of research is needed.

P.S. having the semi-centralized system we currently use (with few
Directory authorities run by trusted people) does not mean you are
100% depending on the directory authorities or that they can
compromise your anonymity. You are trusting them for consensus data
(info about all the relays in the Tor network) which your client uses
to build circuits. If something happens to the majority (50% + 1) of
the directory authorities, this would prevent the Tor network to
function at all, for anyone, but the previous activity within the Tor
network of an user won't be compromised. This is a fair trust limit I
could say, when you take in consideration the fact that total
decentralization will open the door to many other attacks, far worse
than this.

(fortunately) there is no way to 'force' a bandwidth authority or
directory authority to do anything.

Please bare little more and keep the relays running if you can. After
all, we are a community comprised in volunteers involved in research
and experiments, sometimes things like this happen. Just keep calm,
run relays and use Tor. It'll be fixed.

On 5/23/2015 8:58 AM, Julian Plamann wrote:
I have a non-exit relay that has been up and running with 100%
uptime on a 15mbps circuit for going on 20 days that is still
unmeasured.

I also have an exit node on a 100mbps un-metered link that I
brought online 7 days ago and purchased specifically to donate to
Tor that is still unmeasured by the bwauths.

Perhaps it's time to go back to self-advertised bandwidth since
this system is clearly broken?

Furthermore, I understand the necessity of having the bwauths run
by trusted/known members of the development community, but what is
the criteria for this trust? Does running a broken directory server
for going on three weeks without taking the steps to fix it still
fall within this "trust" definition?

- --- Julian Plamann

julian (at) amity.be GPG: 0x96881D83

On 2015-05-22 10:32 am, Marcus wrote:

Hey,

I still have the problem, that my relay (non-exit) is "not
measured". I tried to set up a new ID but this doesn't work. The
relay ist still not measured since one week.
(12FD624EE73CEF37137C90D38B2406A66F68FAA2) I don't know much
about the DA, but I checked that only two of nine have measured
my relay. Only gabelmoo and moria1 did measure the relay. An
other smaller relay I own
(FFB78E1F3E29091212C23A24A9779072800E1D96) is listed as
„measured" in the consensus with only three DA which measured the
bandwidth. (gabelmoo, moria1 and long claw)

Based on this information I have some questions: 1) Is three DA
which measured the bandwidth the „necessary" number to be not
„unmeasured"? 2) Is it only by chance that the DA are almost the
same, which measured my both relays?! 3) Is there any idea, how I
can maybe force a DA to measure the relay?!

I am a bit frustrated that I rented a Server to support TOR and
now the relay is useless... :(

Thanks and Best regards, Marcus

Am 22.05.2015 um 01:24 schrieb Network Operations Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150523/9225811e/attachment-0001.html>