Measuring current load on a Tor relay

Question

I was wondering if anyone could give me some advice on the usefulness of measuring the current load on a router. I have read the bandwidth authority specification, and I have a rough idea on how bandwidth authorities send a file and measure the current bandwidth experienced from the router. I was wondering would it be reasonable to utilize some sort of a packet pair technique to measure the available bandwidth on a Tor relay (or the current CPU utilization) ? Would it be less or more useful than what directory authorities already publish in the consensus? And if the relative usefulness is not known would this be an interesting thing to attempt? Does the way that current directory authorities measure has some limitations could be worked upon?

I have read some papers that do active probing or similar but those seem to be written before the bandwidth measurement by bwauths were introduced or else introduce a lot of traffic in the network. Are there any research papers anyone can point me towards that particularly talk about the limitations of the current measuring structure? Or give any opinions. Basically, my main question is whether it would be worth it to measure a router's load at any given point, and what sort of ways (if known) may be available. I do not intend to measure the entire set of Tor's router population but maybe just about a dozen (so that might not overwhelm the network). Any advice would be appreciated.

Answer 1

A Tor instance keeps track of the bytes written and read. This can be discovered by issuing the GETINFO traffic/written and GETINFO traffic/read requests over the control port (See: control-spec.txt).

Tools like arm already use this to periodically query the control port to measure the current inbound and outbound traffic of an instance of Tor.

The bwauth's do indeed need some work, there have been problems of relays not gaining measurements due to overloaded bw-auths, there is also a problem in that measurement of relays that are geographically distant from the bwauths will tend to end up with worse measurements than those closer to it. This causes problems for geographic diversity of the Tor network.

If you have ideas for improving the bw-auth process then you should submit them as a ticket at https://trac.torproject.org/ or the tor-dev mailing list at https://lists.torproject.org/ but you're probably going to need to come to the table with your own research.

As for prior art, these might be a good starting point:

"Performance Improvements on Tor"

"EAGER: Privacy-preserving measurements of the Tor network to improve performance and anonymity".

There is also the specification for the bw-auths which should outline how they currently operate and pre-existing tools as part of torflow.

Answer 2

Actually, as for my experience and opinion, there are three metrics of Tor router, that are of vital importance :

• the attached CPU core load. Yes, the main load is, sadly, is single-core binded =( The crypto is single-core, so the one core router utilizes most is the main point of throughput/perfomance analysis. I used a simple shellscript and RRDtool(in daemon mode) to graph it, seemed to be fine. Other cores - even if you have a 16-core AMD Opteron - are barely used nowdays.
• Network buffers+queues, measured by packets per second - properly tuned by sysctl, they can double your router's speed. Tune until you will have no further perfomance boost, and do not forget to restart Tor each time you've changed your sysctl tunables! It was graphed the same way as the previous one
• Geosplit, or the reachability of different countries from your IP. I used to make a periodical queries to Tor nodes database, attached IP geolocaion software, not just GeoIP, and grouped the IP's by countries. After that I checked the "bad connectivity" and made a node exclusion list. A tor control protocol goes next - and the bad nodes are banned. It seemed to improve connectivity and speed greatly sometimes, but never ruined speed.

Feel free to ask a further questions