Hello everyone,
we, the Tor Metrics Team, are currently drafting a roadmap for the work we'd like to do on in the upcoming 12 months until September 2018.
If you believe that you're affected by these plans and want your ideas to be included in this roadmap, please read our current draft and send your feedback either to this list, to the metrics-team@ mailing list, or to iwakeh or irl and/or me directly.
https://people.torproject.org/~karsten/volatile/metrics-team-roadmap-2017-10...
In particular, we're interested in:
- tasks we're missing or that we're listing as long-term goals (Q4/2018 or later) that you think should have higher priority over the tasks we picked for the time until Q3/2018,
- tasks that we picked that you think we put in for you or users with similar interests and that you think we could de-prioritize, and
- tasks that you'd want to contribute to in any way, in which case we might reach out to you when we start working on them.
Thanks for helping to make this roadmap document reflect what really needs to be done to make Tor Metrics better.
All the best, Karsten
On 6 October 2017 at 04:48, Karsten Loesing karsten@torproject.org wrote:
- tasks we're missing or that we're listing as long-term goals (Q4/2018
or later) that you think should have higher priority over the tasks we picked for the time until Q3/2018,
bwauth related things, such as:
- How much do bwauths agree? - How much does geography affect the bwauth's measurements? - How can we tell if a change, or new bwauth code, is producing good data? - What is 'good data'?
- tasks that you'd want to contribute to in any way, in which case we
might reach out to you when we start working on them.
I've begun, slowly, to try and answer some of those questions, but my methodology is not as rigorous as yours would be.
And obviously I'll help out with any consensus-health stuff as you need me/I'm able.
-tom
On 6 Oct 2017, at 09:11, Tom Ritter tom@ritter.vg wrote:
On 6 October 2017 at 04:48, Karsten Loesing karsten@torproject.org wrote:
- tasks we're missing or that we're listing as long-term goals (Q4/2018
or later) that you think should have higher priority over the tasks we picked for the time until Q3/2018,
bwauth related things, such as:
- How much do bwauths agree?
- How much does geography affect the bwauth's measurements?
- How can we tell if a change, or new bwauth code, is producing good data?
- What is 'good data'?
+1
Also, can we please have some graphs of IPv6 support on relays? https://trac.torproject.org/projects/tor/ticket/23761
We may also want to know how many entry and exit connections are IPv6 (there's no ticket yet). Exits would be useful now, entry IPv6 would be useful before we turn it on by default.
We'll have a better idea after next week, because we want to create an IPv6 feature matrix with priorities in one of the IPv6 sessions.
T
we, the Tor Metrics Team, are currently drafting a roadmap for the work we'd like to do on in the upcoming 12 months until September 2018.
If you believe that you're affected by these plans and want your ideas to be included in this roadmap, please read our current draft and send your feedback either to this list, to the metrics-team@ mailing list, or to iwakeh or irl and/or me directly.
https://people.torproject.org/~karsten/volatile/metrics-team-roadmap-2017-10...
Thanks you for shareing your roadmap - appreciated.
Here are some ideas:
1) metrics.tpo is focused on number of relays. I think it should be more (additionally) about cw fraction /exit/guard prob. and shares https://trac.torproject.org/projects/tor/ticket/4943 https://trac.torproject.org/projects/tor/ticket/6856
This is especially useful where a relatively low number of relays make up a relevant CW fraction (i.e. BSD relays, alpha version relays, ...). Currently the progress in OS diversity is basically invisible on metrics platform graphs because it is based on relay count.
2) tor network wide resilience graphs at family / AS / country level
- Is the tor network becoming more or less resilient / more or less distributed / more or less centralized? Is the number of _operators_ (Family) and ASes running n-percent of exit/guard probability going up or down?
These graphs would show us if fewer operators run more (bad) of the tor network or vice versa (better).
(I know using family data as an aggregation criteria is non-trivial but a non-perfect solution could work as well - example: https://nusenu.github.io/OrNetStats/maincwfamilies)
3) for operators at relay level I consider bwauth vote graphs very important / useful:
Atlas graphs about the bwauth measurements on relays level. Depends on onionoo providing the data, which I filed here: https://trac.torproject.org/projects/tor/ticket/16843
4) generic aggregate graphs instead of specific family based graphs:
I've been thinking again about the recently added atlas ticket:
Implement family-level pages showing aggregated graphs https://trac.torproject.org/projects/tor/ticket/23509
and realized that it would be much more powerful to graph whatever the the user found with an arbitrary search term. The problem with that is probably scalability as searches might result in many hundret results.
regards, nusenu
-
Karsten Loesing -
nusenu -
teor -
Tom Ritter