Bi-directional families in Onionoo and consensus weight as measure of relayed bandwidth
-----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=sharin...
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.
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...
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. 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-----
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=sharin...
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...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
The major problem with ticket 16276 is that it isn't a fix (as you seek here). It just moves the current implementation into the details document rather than being done in the node index. I don't think you *can* fix it as you seek. Bi-directionality isn't an enforceable property. The spec makes no guarantee. The internet makes no guarantee. You might as well remove the family property entirely than try to do what you suggest. What you propose isn't possible by the properties of tor's network. The best you can do is take a measurement and hope it applies to all views of the network. I made some comments alluding to this in 16276. I would happily work on the ticket if it actually presented a solution. Comments appreciated. --leeroy
One proposal I've liked is to socially discourage asymmetrical families by giving them with bad badges on Roster. If A says B is part of their family but B doesn't reciprocate, A gets a penalty to their bandwidth points. I think right now the proposals are to either: (1) move forward using Observed Bandwidth for everything. And when it gets spoofed we must accept it and can talk about ways of improving it. (2) use consensus weight as a proxy for "real observed bandwidth". Question: What is the downside (if any), of using Consensus Weight as the sole measure of bandwidth points? -V On Thursday, July 2, 2015, l.m <ter.one.leeboi@hush.com> wrote:
The major problem with ticket 16276 is that it isn't a fix (as you seek here). It just moves the current implementation into the details document rather than being done in the node index. I don't think you *can* fix it as you seek. Bi-directionality isn't an enforceable property. The spec makes no guarantee. The internet makes no guarantee. You might as well remove the family property entirely than try to do what you suggest.
What you propose isn't possible by the properties of tor's network. The best you can do is take a measurement and hope it applies to all views of the network. I made some comments alluding to this in 16276. I would happily work on the ticket if it actually presented a solution.
Comments appreciated. --leeroy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi leeroy and Virgil, I'm replying inline. On 02/07/15 14:06, Virgil Griffith wrote:
One proposal I've liked is to socially discourage asymmetrical families by giving them with bad badges on Roster. If A says B is part of their family but B doesn't reciprocate, A gets a penalty to their bandwidth points.
Maybe don't go as far as penalizing relay operators for attempting to configure a relay family and not succeeding at it. Keeping family configurations updated is not exactly trivial. And if the effect is that relay operators stop configuring families at all, that's not what we wanted, either. It would be good to point out configuration problems with family settings and help operators debug them easily.
I think right now the proposals are to either:
(1) move forward using Observed Bandwidth for everything. And when it gets spoofed we must accept it and can talk about ways of improving it.
(2) use consensus weight as a proxy for "real observed bandwidth".
Question: What is the downside (if any), of using Consensus Weight as the sole measure of bandwidth points?
I still think it's a good idea, but I'm curious what others think.
-V
On Thursday, July 2, 2015, l.m <ter.one.leeboi@hush.com> wrote:
The major problem with ticket 16276 is that it isn't a fix (as you seek here). It just moves the current implementation into the details document rather than being done in the node index. I don't think you *can* fix it as you seek. Bi-directionality isn't an enforceable property. The spec makes no guarantee. The internet makes no guarantee. You might as well remove the family property entirely than try to do what you suggest.
What you propose isn't possible by the properties of tor's network. The best you can do is take a measurement and hope it applies to all views of the network. I made some comments alluding to this in 16276. I would happily work on the ticket if it actually presented a solution.
I started implementing something here and will report back on the ticket as soon as I'm more convinced that it works. Thanks, everyone! All the best, Karsten
Comments appreciated. --leeroy
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVlS7lAAoJEJD5dJfVqbCrwp0H/itg2dLrD+SEMKerI5B5g9Ai LFgLJ5HDGsiByiQJi0tDvl2uNv7UA4veZMlumxdHb2BM4DY+FXufVURQaUuPyllr hXv0gtof6ca3zHdPXNvgU+D6aZezOlxKmxZuyJXRb9nV3MeDvv+i+ZT/a3LfbecN ypWRMO0eCznS5LfulWLwFfhPOQC+Ng014WezKf/L6h0Sf6Yt+mWWKWrEgd/TGv4l P6mrOrv0Qt5YdmeaQjsjQ3XEl3eU8cNnhlo+URYnUKGgwo108OEm+dMF1duScQJh YUUsRUu1yJUsBtq/jxkFXh3qqWGUAbNAvKVvFojnFh/nNJqhzuGkzkjjf8qr030= =JwjG -----END PGP SIGNATURE-----
One proposal I've liked is to socially discourage asymmetrical families by giving them with bad badges on Roster. If A says B is part of their family but B doesn't reciprocate, A gets a penalty to their bandwidth points.
Maybe don't go as far as penalizing relay operators for attempting to configure a relay family and not succeeding at it. Keeping family configurations updated is not exactly trivial. And if the effect is that relay operators stop configuring families at all, that's not what we wanted, either.
It would be good to point out configuration problems with family settings and help operators debug them easily.
If my understanding of this is correct, doesn't this also have problems with proof-of-operator? That is, exactly as the current case, there's no inherently reliable way to prove that if A declares B and B doesn't declare A, that there *should* be a bi-directional relation. Other properties of a node/relay only go so far in proof-of-relation. The existence of a bi-directional relation is only taken as a hint for path selection. Given X and Y are chosen and have a bi-directional relation, discard one based on the first chosen.
I started implementing something here and will report back on the ticket as soon as I'm more convinced that it works.
No hints? Regards --leeroy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/07/15 15:07, l.m wrote:
One proposal I've liked is to socially discourage asymmetrical families by giving them with bad badges on Roster. If A says B is part of their family but B doesn't reciprocate, A gets a penalty to their bandwidth points.
Maybe don't go as far as penalizing relay operators for attempting to configure a relay family and not succeeding at it. Keeping family configurations updated is not exactly trivial. And if the effect is that relay operators stop configuring families at all, that's not what we wanted, either.
It would be good to point out configuration problems with family settings and help operators debug them easily.
If my understanding of this is correct, doesn't this also have problems with proof-of-operator? That is, exactly as the current case, there's no inherently reliable way to prove that if A declares B and B doesn't declare A, that there *should* be a bi-directional relation.
Good point. I guess you shouldn't penalize B at all here, because anyone could set up a family and declare unidirectional family relations with all or many other relays to have them penalized. The only actor you could penalize would be A, because either she's lying about being in a family with other relays, or she forgot to also configure the family settings on B correctly. All in all, doesn't sound too useful to rank down relays because of that. Having a notification of some kind would be nice though.
Other properties of a node/relay only go so far in proof-of-relation. The existence of a bi-directional relation is only taken as a hint for path selection. Given X and Y are chosen and have a bi-directional relation, discard one based on the first chosen.
I started implementing something here and will report back on the ticket as soon as I'm more convinced that it works.
No hints?
I'm coding the "effective_family" field discussed on that ticket. I'll post a branch once it runs successfully locally (the first attempt had a bug or two, which is not surprising). But that doesn't mean that this code will be merged as is, it's just supposed to be a better basis for further discussions. More on the ticket once I have more to say. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVlWwfAAoJEJD5dJfVqbCryhAIAIVVDsze8vovtA6PPwnuzjNE sYHjQhyS5G+rV6zRf2gSQSCVzno5aUqh+WTAOWiPyJwmeii43ZZT8IrJ9e+zauxV 6p40slKfKzP/qJjYy+8JCir6ew/3nnjvnKu7cSbVpLBtK1MY/AiX3W+XHMj/eWoR 5Z1yiqN/Wax+stwhUoryThqD1iBWc5HwC7lmwOcwbRof/OGtQhVhgzzAIx88LKof KvmFCWIn1yvruwTyOmibBreUbzGebxTbnEqzidZ6eM2DQIB6xEoup5lQdZcfVp7K VFeGf57CzTMj/+nBp37Eux2ZOsVd+5/GyYuekfUqdkh40fGb2sQjf3NNEt/xfN8= =ayLq -----END PGP SIGNATURE-----
So I guess I should go back to the original issue posted in this thread. It hasn't been addressed if the (bi-directional family) concern is actually data from Onionoo or operators that just don't declare families. The view from Onionoo--based on consensus, taking into consideration caching and other network reliability factors affecting a view of tor. The view from tor--which is far more difficult to prove. Currently tor will automatically reject implied family relations based on ip block similarity. Regards --leeroy
participants (4)
-
Aaron Gibson -
Karsten Loesing -
l.m -
Virgil Griffith