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

Aaron Gibson aagbsn at extc.org
Thu Jul 2 09:01:49 UTC 2015


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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev



More information about the tor-dev mailing list