Opened 7 months ago

Last modified 7 months ago

#33649 new enhancement

Show progress towards flags on consensus health

Reported by: teor Owned by: tom
Priority: Medium Milestone:
Component: Metrics/Consensus Health Version:
Severity: Normal Keywords: network-health
Cc: gk, arma, metrics-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Relay operators often ask us why they don't have a particular flag. For example:
https://lists.torproject.org/pipermail/tor-relays/2020-March/018253.html

When a relay doesn't have a flag, we could show relay operators how close their relay is to getting that flag. Showing progress would also help us diagnose hard-to-find bugs in tor.

This could be a project that we do in stages.

Here's a sketch of the flag-thresholds and per-relay vote data we'd need:

Fast:

  • bandwidth
    • w Measured
      • (what happens for relays that aren't measured?)
    • fast-speed

Stable:

  • uptime
    • add an uptime line to votes in tor
    • stable-uptime
  • mtbf
    • add a mtbf line to votes in tor
    • stable-mtbf
  • show both uptime and mtbf fractions

Guard:

  • needs Fast
  • needs Stable
  • wfu - same as uptime?
    • add a wfu line to votes in tor
    • guard-wfu
  • tk - what is this?
    • add a tk line to votes in tor
    • guard-tk
  • is there a bandwidth or mtbf requirement for guards?
  • show wfu and tk fractions
  • show if it needs Fast and Stable - are these flags implied by wfu and tk?

Child Tickets

Change History (6)

comment:1 Changed 7 months ago by teor

As an alternative implementation, we could change tor so it:

  • calculates a progress fraction towards each flag, for each relay
  • puts the fractions for each flag in a line in its votes

comment:2 Changed 7 months ago by arma

I like this idea! I could imagine it as a "details" page for each relay that relay-search could serve too.

There are two pieces to the idea, as I understand it from above:

(A) Directory authorities would add another line to their votes about each relay, and include the input parameters that they used for making their decisions about the relay. There's no reason for a new consensus method, or for the consensus to change in any way. We'd basically just be exporting the internal directory authority state in a more useful and usable (and automatically archived) way.

(B) Visualize these things for relay operators somewhere, e.g. in relay-search or in consensus-health.

One important catch to consider, and that we'd want to communicate well in the visualization page, is that many of the thresholds are moving targets, e.g. your uptime could go up yet your percentage progress toward having enough uptime could go down. I think if we communicate it well, people could handle this concept though.

comment:3 Changed 7 months ago by teor

(B) Visualize these things for relay operators somewhere, e.g. in relay-search or in consensus-health.

I think there's a catch here: as far as I recall, relay search doesn't read votes, because Onionoo doesn't store votes.

So we'd be implementing this feature on consensus health.
(Which is used by more technical users.)

comment:4 in reply to:  1 Changed 7 months ago by arma

Replying to teor:

As an alternative implementation, we could change tor so it:

  • calculates a progress fraction towards each flag, for each relay
  • puts the fractions for each flag in a line in its votes

My slight preference would be toward publishing the raw input numbers in the votes, and doing the calculations externally.

The calculations get complex when we consider that we'll change the threshold algorithms in various versions of Tor, and some dir auths change their torrc to set their own custom thresholds (e.g. moria1 sets "MinUptimeHidServDirectoryV2 24 hours"). I guess the external script will need to keep a growing list of "for this Tor version, this is how you combine those raw numbers into the fraction" algorithms.

The thing that pushes me over the edge toward "do the calculations externally" is: what if we have bugs in the fraction calculations? If we only publish fraction calculations in votes, then when we discover bugs, we potentially invalidate all published numbers so far. Whereas if we do the calculations externally, we still have the raw numbers and we can rerun new scripts over old numbers and get new results.

Last edited 7 months ago by arma (previous) (diff)

comment:5 in reply to:  3 Changed 7 months ago by arma

Replying to teor:

as far as I recall, relay search doesn't read votes, because Onionoo doesn't store votes.

So we'd be implementing this feature on consensus health.

Awesome. We can get both: if consensus-health learns to display these numbers for a relay, with a per-relay url, then relay-search can have a "more details" link that sends people to it.

That said:
https://collector.torproject.org/archive/relay-descriptors/votes/
so they are definitely in there somewhere. :)

comment:6 Changed 7 months ago by karsten

CollecTor does store votes, but Onionoo doesn't fetch and process them yet. The reason is that even though Onionoo would probably handle them just fine when given one hour of votes per execution, it might run into trouble when recovering from a few hours or even days of downtime. This is a current limitation that we might remove in the future. Until that's the case, we can of course link to consensus health.

Note: See TracTickets for help on using tickets.