Proposal 164: Reporting the status of server votes

[Roger Dingledine]

On Fri, May 22, 2009 at 03:00:42AM -0400, Nick Mathewson wrote:
>        - Look through your log for reports of what the authority said
>          when you tried to upload.
> 
>        - Look at the consensus; see if you're listed.
> 
>        - Wait a while, see if things get better.
> 
>        - Download the votes from all the authorities, and see how they
>          voted.  Try to figure out why.

Mere mortals can't do this step either. It involves fetching a secret
only-mentioned-in-the-spec URL ("/tor/status-vote/current/authority")
from a set of secret only-mentioned-in-the-code IP addresses.

>        - If you think they'll listen to you, ask some authority
>          operators to look you up in their mtbf files and logs to see
>          why they voted as they did.

In practice, it's sufficient to ask an authority operator to go look
through the "v3-status-votes" file in their datadir that gets written
every voting period, and see what the recent votes have said about
your relay.

>    This is far too hard.
> 
> Solution:
> 
>    We should add a new vote-like information-only document that
>    authorities serve on request.  Call it a "vote info".  It is
>    generated at the same time as a vote, but used only for
>    determining why a server voted as it did.  It is served from
>    /tor/status-vote-info/current/authority[.z]
> 
>    It differs from a vote in that:
> 
>    * Its vote-status field is 'vote-info'.
> 
>    * It includes routers that the authority would not include
>      in its vote.
> 
>      For these, it includes an "omitted" line with an English
>      message explaining why they were omitted.
> 
>    * For each router, it includes a line describing its WFU and
>      MTBF.  The format is:
> 
>        "stability <mtbf> up-since='date'"
>        "uptime <wfu> down-since='date'"
> 
>    * It describes the WFU and MTBF thresholds it requires to
>      vote for a given router in various roles in the header.
>      The format is:
> 
>        "flag-requirement <flag-name> <field> <op> <value>"
> 
>      e.g.
> 
>        "flag-requirement Guard uptime > 80"
> 
>    * It includes info on routers all of whose descriptors that
>      were uploaded but rejected over the past few hours.  The
>      "r" lines for these are the same as for regular routers.
>      The other lines are omitted for these routers, and are
>      replaced with a single "rejected" line, explaining (in
>      English) why the router was rejected.

How does the 'omitted' line differ from the 'rejected' line?

Also, this reminds me of a wishlist item that Robert Hogan had a while
back. He wants to know how many Tors are configured to be relays, but
fail their self-reachability checks, so don't even try to publish. If
it's hundreds or thousands, that means we should work harder to help
users learn that they're not helping out in the way they think they are.

>    A status site (like Torweather or Torstatus or another
>    tool) can poll these files when they are generated, collate
>    the data, and make it available to server operators.

Sounds like a fine plan. I agree that this would be a helpful feature
to have. But it's also not upgrade-path-critical in the way that a lot
of the other pending proposals are -- we could do it in 0.2.2 or 0.2.3
or later and nothing else would have to change to accommodate.

Also, it can be done pretty well by a) teaching users to read their logs,
which they're already not so bad at if they're the sort of users who know
how to realize that this vote-info stuff exists, and b) teaching sites
like torstatus to fetch the secret URLs from the secret IP addresses and
crunch the vote data that's already available. This proposal only really
adds help for folks who can't find their logs, and folks who want to
know why they're not marked Stable (answer: "you're not stable enough;
oh, and bug 969").

So: if you are itching to do it (or somebody else is), by all means go
for it. But if it seems like a big pile of hassle (and some of the ideas
above are pretty invasive and tricky to do efficiently), feel free to
put it off indefinitely.

Here's an alternative proposal: I set up a cron job on moria to copy
moria1's v3-status-votes file to someplace web-accessible, and then we
tell the torstatus folks that they can fetch it and parse it if they
want to?

(It's my understanding that torstatus isn't seeing much development these
days, which might be bad for all of these plans which end with "and then
those nice people will fetch it and make it user-understandable".)

--Roger