Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
I think that is a bad idea. You don't know enough about a relay to have a clue about what the underlying hardware looks like from any of that metrics. Simple example: You have a 8 core 16 threads cpu, run 4 instances, each node pinned to 2 threads and a 10 gig pipe, you will run each tor relay at max speed without effecting any of the other relays on the same server. But with your choosen metrics you would slow all of them down just in case. I don't even think that there are metrics from which you could guess that, the relay operator would have to set limits to do this effective, or if Tor would have proper multithread support you would just have to run one instance per server and you would be good to go with just the measurement you done from external. On 08.08.2019 14:34, teor wrote: Hi Rob, On 8 Aug 2019, at 22:15, Rob Jansen wrote: On Aug 6, 2019, at 5:48 PM, Roger Dingledine wrote: On Tue, Aug 06, 2019 at 05:31:39PM -0400, Rob Jansen wrote: Today, I started running the speedtest on all relays in the network. So far, I have finished about 100 relays (and counting). I expect that the advertised bandwidths reported by metrics will increase over the next few days. For this to happen, the bandwidth histories observed by a relay during my speedtest are first committed to the bandwidth history table (within 24 hours), and then reported in the server descriptors (within 18-36 hours, depending on when the bandwidth history commit happens). Great. There will be another confusing (confounding) factor, which is that the weights in the consensus are chosen by the bandwidth authorities, so even if the relay's self-reported bandwidth goes up (because it now sees that it can handle more traffic), that doesn't mean that the consensus weight will necessarily go up. In theory it ought to, but with a day or so delay, as the bwauths catch on to the larger value in the descriptor; but in practice, I am not willing to make bets on whether it will behave as intended. :) So, call it another thing to keep an eye out for during the experiment. Another wrinkle to keep in mind is that my script measures one relay at a time. If there are multiple relays running on the same NIC, after my measurement each of them will think they have the full capacity of the NIC. So if we just add up all of the advertised bandwidths after my measurement without considering that some of them share a NIC, that will result in an over-estimate of the available capacity of the network. To avoid over-estimating network capacity, we could use IP-based heuristics to guess which relays share a machine (e.g., if they share an IP address, or have a nearby IP address). In the long term, it would be nice if Tor would collect and report some sort of machine ID the same way it reports the platform. More precisely, we're trying to answer the question: "Which small sets of machines are limited by a common network link or shared CPU?" A machine ID is an incomplete answer to this question: it doesn't deal with VMs, or multiple machines that share a router. Here are some other potential heuristics: * clock skew / precise time: machine/VM? * nearby IP addresses and common ASN: machine?/VM?/router? * platform: machine * tor version: operator? (a proxy for machine/VM/router) Is there a cross-platform API for machine IDs? Or similar APIs for our most common relay platforms? (Linux, BSDs, Windows) T ___ tor-relays mailing list 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
Re: [tor-relays] DoS attack on Tor exit relay
On 06.08.2019 12:57, ger...@bulger.co.uk wrote: Thanks. I just could not see how Fail2ban would work on an ORport. What log would it look at? What criteria for the jail? The fai2ban on my non-tor VPS does not yet work with IPv6, which is partly the nature of IPV6 rather than a programming issue. I did not realise IPV6 was ignored until a weak email account was found. So I firewalled off most IPv6 ports instead. fail2ban supports IPv6 since version 0.10 -- Ciao Marco! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 10 Years Torservers.net: Death or Future?
It was nothing personal at all. My point was and is: You can’t substitute a German non profit with this organisation. Even if you could, torservers.net are supporting all the others smaller orgs, not the other way around. Thats a lot of work organising orgs and also avoiding unnecessary work in one of the reason most orgs have strict reduced exit policies at place nowadays. You get a few 100 abuse mails a day, you have to take care of the servers, talk to people, organise things, make sure everyone is happy. The yearly paperwork for a non profit doesn’t really matter in the grand pattern of things. Take care! > On 8. Aug 2019, at 06:08, Mitar wrote: > > Hi! > > So I initially just wanted to share a tool/service which I think > addresses some of the issues I noticed in projects, when people get > burned out because of all the paperwork involved. I replied further to > mostly address some, from my perspective, misunderstandings about this > tool/service. By providing more information I thought people can > decide better if this tool/service is something which could be useful > here. > > I think we are going now in circles and I think that for anyone who > cares about this tool/service can read more information by themselves. > I do not see much interest in it, so I will not continue this thread. > If anyone has more questions about it and would like my ideas how it > could be applied to this project, feel free to write to me directly. > > On Wed, Aug 7, 2019 at 4:45 PM niftybunny > wrote: >> First off, nice to see you are fighting for the good in the world, while >> having a company in Delaware. Paying 0% taxes. > > Not sure if this relates to me personally, but I am not involved with > the company. And you are right that we should be mindful about how > companies are incorporated, when deciding to deal with them. Not sure > if this is the critical factor though, but it is for sure a factor. > Thank you for bringing this to my attention. > > And you are right that closer your non-profit host is to the project, > easier it is to donate to your project. But I thought tor servers > project is a global project, not a German project, so having fiscal > sponsors all around the globe in fact, by your own argument, makes it > easier to donate for more people. US people can donate to US based > non-profit hosts, EU people can donate to EU based non-profit hosts, > if there was a German host, then it would address your concern about > German donations as well. > > You can of course have a network of partners, like tor servers project > has now to address the same need. But there is still paperwork will > all this. > > Anyway, this is all from my side. I hope all this energy I have > observed just now could be redirected to further push tor servers > project into the future. It is always easier to argue against than > working towards. > > > Mitar > > -- > http://mitar.tnode.com/ > https://twitter.com/mitar_m > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi Rob, > On 8 Aug 2019, at 22:15, Rob Jansen wrote: > >> On Aug 6, 2019, at 5:48 PM, Roger Dingledine wrote: >> >> On Tue, Aug 06, 2019 at 05:31:39PM -0400, Rob Jansen wrote: >>> Today, I started running the speedtest on all relays in the network. So >>> far, I have finished about 100 relays (and counting). I expect that the >>> advertised bandwidths reported by metrics will increase over the next few >>> days. For this to happen, the bandwidth histories observed by a relay >>> during my speedtest are first committed to the bandwidth history table >>> (within 24 hours), and then reported in the server descriptors (within >>> 18-36 hours, depending on when the bandwidth history commit happens). >> >> Great. >> >> There will be another confusing (confounding) factor, which is that the >> weights in the consensus are chosen by the bandwidth authorities, so >> even if the relay's self-reported bandwidth goes up (because it now sees >> that it can handle more traffic), that doesn't mean that the consensus >> weight will necessarily go up. In theory it ought to, but with a day or >> so delay, as the bwauths catch on to the larger value in the descriptor; >> but in practice, I am not willing to make bets on whether it will behave >> as intended. :) So, call it another thing to keep an eye out for during >> the experiment. > > Another wrinkle to keep in mind is that my script measures one relay at a > time. If there are multiple relays running on the same NIC, after my > measurement each of them will think they have the full capacity of the NIC. > So if we just add up all of the advertised bandwidths after my measurement > without considering that some of them share a NIC, that will result in an > over-estimate of the available capacity of the network. > > To avoid over-estimating network capacity, we could use IP-based heuristics > to guess which relays share a machine (e.g., if they share an IP address, or > have a nearby IP address). In the long term, it would be nice if Tor would > collect and report some sort of machine ID the same way it reports the > platform. More precisely, we're trying to answer the question: "Which small sets of machines are limited by a common network link or shared CPU?" A machine ID is an incomplete answer to this question: it doesn't deal with VMs, or multiple machines that share a router. Here are some other potential heuristics: * clock skew / precise time: machine/VM? * nearby IP addresses and common ASN: machine?/VM?/router? * platform: machine * tor version: operator? (a proxy for machine/VM/router) Is there a cross-platform API for machine IDs? Or similar APIs for our most common relay platforms? (Linux, BSDs, Windows) T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 10 Years Torservers.net: Death or Future?
Hi! So I initially just wanted to share a tool/service which I think addresses some of the issues I noticed in projects, when people get burned out because of all the paperwork involved. I replied further to mostly address some, from my perspective, misunderstandings about this tool/service. By providing more information I thought people can decide better if this tool/service is something which could be useful here. I think we are going now in circles and I think that for anyone who cares about this tool/service can read more information by themselves. I do not see much interest in it, so I will not continue this thread. If anyone has more questions about it and would like my ideas how it could be applied to this project, feel free to write to me directly. On Wed, Aug 7, 2019 at 4:45 PM niftybunny wrote: > First off, nice to see you are fighting for the good in the world, while > having a company in Delaware. Paying 0% taxes. Not sure if this relates to me personally, but I am not involved with the company. And you are right that we should be mindful about how companies are incorporated, when deciding to deal with them. Not sure if this is the critical factor though, but it is for sure a factor. Thank you for bringing this to my attention. And you are right that closer your non-profit host is to the project, easier it is to donate to your project. But I thought tor servers project is a global project, not a German project, so having fiscal sponsors all around the globe in fact, by your own argument, makes it easier to donate for more people. US people can donate to US based non-profit hosts, EU people can donate to EU based non-profit hosts, if there was a German host, then it would address your concern about German donations as well. You can of course have a network of partners, like tor servers project has now to address the same need. But there is still paperwork will all this. Anyway, this is all from my side. I hope all this energy I have observed just now could be redirected to further push tor servers project into the future. It is always easier to argue against than working towards. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
> On Aug 6, 2019, at 5:48 PM, Roger Dingledine wrote: > > On Tue, Aug 06, 2019 at 05:31:39PM -0400, Rob Jansen wrote: >> Today, I started running the speedtest on all relays in the network. So far, >> I have finished about 100 relays (and counting). I expect that the >> advertised bandwidths reported by metrics will increase over the next few >> days. For this to happen, the bandwidth histories observed by a relay during >> my speedtest are first committed to the bandwidth history table (within 24 >> hours), and then reported in the server descriptors (within 18-36 hours, >> depending on when the bandwidth history commit happens). > > Great. > > There will be another confusing (confounding) factor, which is that the > weights in the consensus are chosen by the bandwidth authorities, so > even if the relay's self-reported bandwidth goes up (because it now sees > that it can handle more traffic), that doesn't mean that the consensus > weight will necessarily go up. In theory it ought to, but with a day or > so delay, as the bwauths catch on to the larger value in the descriptor; > but in practice, I am not willing to make bets on whether it will behave > as intended. :) So, call it another thing to keep an eye out for during > the experiment. Another wrinkle to keep in mind is that my script measures one relay at a time. If there are multiple relays running on the same NIC, after my measurement each of them will think they have the full capacity of the NIC. So if we just add up all of the advertised bandwidths after my measurement without considering that some of them share a NIC, that will result in an over-estimate of the available capacity of the network. To avoid over-estimating network capacity, we could use IP-based heuristics to guess which relays share a machine (e.g., if they share an IP address, or have a nearby IP address). In the long term, it would be nice if Tor would collect and report some sort of machine ID the same way it reports the platform. Whe! Rob ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
