Thus spake Johannes Renner (hannesrenner@xxxxxx): > 1. - Search in descriptors for supporting routers (X-tra info) --> > n routers - Choose one of them randomly (to use as middle node in a > circuit) - Get its bandwidth-document via Tor - Use the chosen node > as middle node and select 2 'high-bandwidth-available' links from > its list, which then define entry and exit (one endpoint must > support exit). This selection can be done randomly considering a > subset of the links from the list, having available > x bytes/sec. > > 2. - Get bandwidth documents from all n supporting routers via Tor > - Save and merge all of the received information - Find 3 adjacent > links with available bandwidths in the same class - Put them > together to a circuit > > 3. - Just consider (global) MAX and AVG to gain information about > the current load on the queried router > > 4. - Any suggestions/ideas? > > Further, if we had an alternate directory, it could gather and merge > bw-information from every supporting router while trying to prove > for correctness and even functionality to report lyers could be > integrated. Another possibility to detect lyers would be to use a > newly created circuit, measure bandwidth and see if the expected > results are reached. As I pointed out in my previous posts, http://archives.seul.org/or/dev/Apr-2007/msg00031.html http://archives.seul.org/or/dev/Apr-2007/msg00041.html I really think you're introducing a lot of problems for liar detection here. All liars will say that they have super fast connection to their colluding peers, and slow connections to everyone else, to influence path selection towards their peers when they are chosen. This can be very hard to detect if they add arbitrary noise to it. And who's to say their ISPs don't just have peering agreements with their colluding peers to begin with? In addition (and even more importantly), you are leaking a large deal of information about node activity. Say I'm the adversary, and someone transfers a whole truckload full of data I don't want out there to some site I become aware of. I note the time this happened at via that website's http headers for the data, then go through the logs of the bandwidth capacities of all the nodes that report this information. Those nodes will display a spike in traffic during the transmission of this data to the peers they transfered it to, for about the duration the data transfer would take. This is very bad, and there's not much you can do about it once you are reporting data this accurately. I think you are much better served measuring total capacity of nodes via a trusted third party and publishing those results. My speedracer.pl script does this already in conjunction with the metatroller's statistics engine. Essentially, the script measures the stream bandwidth throughput through nodes, takes this average, and then divides the node's current reported bandwidth by this stream bandwidth. Nodes with a high resulting number have an excessively large number of connections passing through them, and are either overloaded or lying about their bandwidth. This is probably the main cause of slowness on the network (though it is possible transcontenental voyages and poor peering are another). If you really want peerwise data, you can extend the information this 3rd party scanner gathers by creating these statistics for node to node links, but again, be mindful of the fact that there are O(N^2) of these links on the network: currently 1 million edges to measure and transfer to clients. That is a lot of data. And the network is growing... -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpUEP2vA2dg3.pgp
Description: PGP signature