[tor-dev] Bandwidth Scanner

2018-03-19 Thread Aaron Gibson
Hi all,

per reading [1], I see that there was significant discussion at tor-dev
around the topic of bandwidth measurements. It was unclear to me what
direction has been agreed on, or if anyone is leading this effort, so I
wanted to add that:

I have been working with Donncha, Juga, Teor, and Linus to find and fix
issues in the BwScanner codebase. As George K. indicates, I am time
limited and interrupt driven so I've made little progress in resolving
the "last few bugs" [2]

I do want to continue resolving these issues, and any help testing,
reviewing pull requests or contributing patches would be awesome. I
think it would also be very helpful for TPI to support this project with
project management resources to keep things on track.

BwScanner is written in python using twisted, uses travis-ci for unit
tests and integration testing with chutney. Development has been using
the github tools to facilitate code reviews and testing, and has OK
testing coverage and documentation.

--Aaron

[1]
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/BandwidthAuthorityRequirements

[2] https://github.com/thetorproject/bwscanner/issues
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


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

2015-07-02 Thread Aaron Gibson

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


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


Re: [tor-dev] Next OONI weekly meetings

2014-11-19 Thread Aaron Gibson

On 2014-11-19 11:20, Arturo Filastò wrote:

Hello Oonitarians,

Sorry for not sending this email sooner, but this week has been a bit
hectic.

A couple of people have said that they cannot attend the weekly meeting
on thursday at 18:00, because it conflicts with another recurring
appointment they have.

For this reason I am going to suggest we reschedule the next OONI
meetings to a date that works for everybody.

Monday and Tuesdays seem to be the best option, so I am going to 
propose
we skip next weeks meeting and instead opt for holding next weeks one 
on

either a Monday or Tuesday at 18:00 UTC, 19:00 CET, 13:00 EST, 12:00
CST, 10:00:00 PST.

How does this sound for everybody?

I personally would prefer Monday over Tuesday, but if you would instead
prefer Tuesday please send a reply to the ooni-dev mailing list.

If nobody replies I am going to assume every Monday works for you all
and the next meeting will be on Monday 24th of November.


My preference is also Monday.

--Aaron


Have fun!

~ Arturo

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