[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth



On 2015-07-02 08:12, Karsten Loesing wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moving this discussion here from another list with Virgil's permission.

On 02/07/15 08:42, Virgil Griffith wrote:
Big issues right now are: * Bugs (?) in Onionoo --- Onionoo doesn't
sanitize its data.  For example, there's a lack of bidirectionality
between relays of many families.
https://drive.google.com/file/d/0Bwjagz1RgJOnSkx0YTlhMHdfMFU/view?usp=sharing

 There are currently about 665 pairs of family relays without
bidirectionality. This is caused by the .torrc of some relays not
pointing to its family members.

Do many of these relays have ContactInfo? Are there similarities between the configurations or are these 'Family' members pretending in order to look like honest relays? Interesting find!

I am considering doing a service on top of Onionoo that sanitizes
the raw Tor consensus to ensure things like bidirectional families.
It's unclear how much other data needs sanitization.

I'd rather want to fix/change Onionoo than have you write another
service that processes Tor descriptors.  There's even a ticket for
this, we're just somewhat stuck by arguing about the best fix.  Maybe
I should just fix it somehow and, if necessary, fix it more later.

https://trac.torproject.org/projects/tor/ticket/16276

Would that solve your problem?

What other problems would there be with Onionoo's data?  Can you make
a wish list?

* A semi-reliable measure for the magnitude of traffic a relay has
routed.  We have confirmed instances of relays forging their
observed bandwidth, ergo we can't use that.  And thus far
Consensus Weight is the best we've found, but it's unclear whether
we can use that as a proxy of magnitude of relayed traffic. ---
https://docs.google.com/document/d/1v1rutylD6RkBei9rEmSvsgmvQXhrIHXOr85NL3I9_q8/edit?usp=sharing

 Right now the lack of a reliable measure of how much bandwidth is
relayed is the largest sticking point.

Actually, consensus weight (fraction) is a fine measure, and I like
how you're calling it "bandwidth points" in your prototype which
doesn't imply a bits per second or related unit.  I'd say assign
10,000 bandwidth points to all relays per day, depending on what
fraction of total consensus weight a relay had.  To me, it's fine that
this doesn't translate to bits or bytes.

I'd suggest binning relays by fraction of consensus - e.g. top 10% of relay tier, and so on - thougths?


How does that sound?

All the best,
Karsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJVlPKJAAoJEJD5dJfVqbCrZWQH/0lHSdgy4PF7nQ8RMZryKpnf
o3Fvw8VkcIwZgJgp0MOLIVu0fZhcD8hhvSWd9yYTSpQwGwBayUJuPE0ao4MbfZYf
mwz5hkngzq1Z7654K65m/fYLu7EIbXI86vT4/Cwwh8cnGl/ezaliFVvVMOmKTyOb
UtV7T+Lgk5IgsGJOxQbpNHCTxyAokbAygqZ9Eq/6ZWqjZFBZb1P2XjV+IaziGyJl
yuxrD66cJe4ZmcpPe9g7mTa9JyQ5kmUOWogXhKTFWDFCcPslc0M49iiYohDmiNxC
5RGKp1dMuYkL6th9b3Uuc3W4TdCMaDHV96BDUD3qdlqCWBU0fD617f31+Hsb6Bg=
=0KdX
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev