[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



> 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

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


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_




Attachment: signature.asc
Description: OpenPGP digital signature

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