[tor-project] Roadmap for hypothetical network health team
george at queair.net
Mon Dec 31 05:56:00 UTC 2018
> Here is an area list for a hypothetical future "network health" team. I
> say hypothetical because we have no near-term plans to form such a
> team -- but imo the task areas make sense together. Some of them are
> being handled by other teams right now, but some of them aren't getting
> as much attention as they need.
> (1) track community standards about what makes a good relay
> - publish up-to-date expectations for relay operators
> - set best practices for how to set relay families
> - detect and resolve bad relays
> - exitmap, sybil detection, hsdir traps
> (2) anomaly analysis / network health engineer [with network team]
> - establish baselines of expected network behavior
> - look for and resolve denial of service issues
> - track connectivity issues between relays
> - look for relays hitting resource limits
This area, in particular, could use a lot of attention.
irl@ and myself have some relevant tickets, which I can dig up if
On the whole, exploring how 'exception reports' would apply to the node
network (not to mention other parts such as bw authorities, etc) is a
very worthy cause.
We have to get beyond the rear-view mirror assessments and start
determining baselines within standard deviations, and start correlating
significant changes as they happen.
> (3) make sure usage/growth stats are collected and accurate
> - track network performance, relay diversity by various metrics
> - count users [with network team and metrics team]
> - monitor bridge growth and usage [with censorship team]
> (4) relay advocacy [with community team]
> - maintain docs for setting up and running relays and bridges
> - grow a cohesive community of relay operators so they have peers
> - keep relays on the right tor versions
> - relaunch a gamification / badge system for lauding good relay progress
> - strengthen relationships with non-profit orgs that run relays
> - help companies that want to offset their tor network load
> (5) maintain the components of the network
> - maintain directory authority relationships
> - keep bandwidth authorities working (including setting the right
> balance between speed and location diversity)
> - have enough tor browser default bridges, and keep them running
> smoothly [with censorship team]
> - update the fallbackdirs list
And related to (1) and (5), it might be useful to expand on 'best
practices' and documentation for critical services (bw auths, etc).
Certainly OONI's work and wide-angle view could be incorporated in
several facets of the above.
The ability to run internet-facing infrastructure isn't innate, and even
for those who do have the experience, there's no finish line.
Good stuff Roger.
34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682
More information about the tor-project