bw-informer

[Johannes Renner <hannesrenner@xxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I just initially commited the second part of my project, which is a controller for ORs
that is listening to bw and orconn-bw events (needs orconn-bw.patch). While doing this
it counts and adds up all the bytes read and written for each single TLS-connection, as
well as for the complete node. From these an average throughput value for each link and
the whole node gets computed every n seconds (my currently used value is 30 sec).
Additionally a maximum reached value gets stored that can be used to compute an 'estimated
available bandwidth' for each link as well as for the whole node. As a first step this will
be done simply by computing the difference of max and the avg of the last interval:

  available = max-avg

Clients (op-addon.py) can connect to a specified port and request a bandwidth document.
This document should better be served by Tor itself via http on some URL as soon as I
know exactly how to do this technically. The current format of the document is:

AVAILABLE MAX AVG
- --------------------
x available max avg
y available max avg
z available max avg
...

The values in the first line (AVAILABLE, MAX, AVG) are total node's stats computed
from bw-events. After that there is a separator and then a list of stats about the
single TLS-connections is following: In each line the x/y/z is the nickname or idhex
of the endpoint while the values are those computed from orconn-bw events. This list
is sorted by 'available' and it also could be cut off to include only links with at
least n measured bytes/sec available (configurable). A client (op-addon.py), while
searching for links to build up high bandwidth circuits, can read this list and then
compute 'currently estimated available bandwidths' for each link with

  available_x = min(MAX-AVG, max_x-avg_x)

Note that the available-value actually is computed using the other two values, so
clients could also get delivered max and avg only to compute the difference on their
own. But since I plan to use mainly (max_x-avg_x) and (MAX-AVG) I rather think about
_only_ delivering AVAILABLE plus an available for each link.

Clients (op-addon.py) could do route selection based on this in at least three ways:

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.

What do you think?

Greetings,
Johannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGS0Rm1TFW0/n+aNgRAu4iAKCUVYX8zIZGTMqSls8X6pN4L0kKQQCfVCi4
2kOf8ZkZJ7kZreym8GPfNxA=
=Yw95
-----END PGP SIGNATURE-----