bw-informer

[Mike Perry]

Thus spake Johannes Renner (hannesrenner at gmx.de):

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070522/bbd9b1f3/attachment.pgp>