-----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 <noc@schokomil.ch mailto:noc@schokomil.ch>:
Matt,
135 Kb/s measured, I'm currently pushing data at 40Mbit in/out (limit is 80 Mbit with burst to 120 Mbit).
On 21.05.2015 11:14 PM, Speak Freely wrote:
Hey NOC, Nah I had the same experience with *1* relay. Following the same pattern, none of the other relays have left 20. I'm now at 16200 and averaging ~30mb/s. 4 still in limbo. What's also interesting is I setup a non-exit and it also will not get past 20. What does arm say your measured speed is? Mine was 45Kb/s for the longest time, but very recently went to 126.5Kb/s, but that's silly. Matt Speak Freely _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list tor-relays@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list tor-relays@lists.torproject.org mailto:tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays