[tor-dev] Your input on the Tor Metrics Roadmap 2017/18

[Karsten Loesing]

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-06.pdf

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

[Tom Ritter]

Post by Karsten Loesing
- 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'?

Post by Karsten Loesing
- 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

[teor]

Post by Tom Ritter

Post by Karsten Loesing
- 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,

- 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

[nusenu]

Post by Karsten Loesing
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
to iwakeh or irl and/or me directly.
https://people.torproject.org/~karsten/volatile/metrics-team-roadmap-2017-10-06.pdf

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